Recorrentemente, existem dois momentos principais na receção de um briefing (e os briefings de UX não são exceção). O primeiro é o momento em que o briefing é entregue e analisado, o segundo é a desconstrução e reconstrução do briefing, em conjunto com o cliente, de modo a chegarmos àquele que é, verdadeiramente, o briefing final.
Considero que há mais margem para reconstrução com clientes com quem criámos alguma confiança e onde este debate e “evangelização” de boas práticas de UX (User Experience) têm também um maior ganho. Será, portanto, esse o foco deste artigo.
Analisar um “briefing” de UX
Coloco “briefing” entre aspas, pois imagino que, tal como eu, já tenham recebido as ideias ou necessidades do cliente de diversas formas.
Parece-me que, a partir de um determinado momento, a relação mais próxima com o cliente leva a que os pedidos sejam uma conversa ou um email mais ou menos vago, com diferentes anexos.
Será isso um problema?
Mesmo com um documento estruturado, é natural que surjam dúvidas. Portanto, a ausência desse documento, apesar de significar trabalho acrescido, é uma possibilidade de discussão de ideias.
Pessoalmente, e considerando a maturidade sobre a área de UX em Portugal, prefiro ter um briefing não estruturado do que ter um documento fechado que não se pode debater ou melhorar.
Recriar um briefing
Acredito, portanto, que, enquanto profissionais desta área, temos atualmente a oportunidade de discutir e trocar experiências sobre quais consideramos serem os pontos fundamentais a incluir num briefing de UX.
Deste modo, podemos ser nós a sugerir um modelo, ao invés de recebermos briefings baseados na experiência que os clientes possam ter com outras áreas e que não refletem as nossas necessidades.
É comum os briefings serem entregues com pouca informação: sem o devido contexto sobre o que deu origem àquela necessidade, a visão do negócio sobre o tema ou quais os constrangimentos existentes.
Será que o problema é realmente um problema para o utilizador? Será que nos estamos a focar na raiz da necessidade ou a tentar apenas minimizar as consequências de um problema de fundo?
No último caso, importa saber dividir a resolução do problema em partes que possam ser implementadas aos poucos, efetuando melhorias contínuas e defendendo os ganhos a longo prazo.
Por vezes, ocorre o inverso, e o briefing é apenas um pedido de execução, em vez de uma apresentação de uma necessidade, limitando assim a possível solução, pois considera-se o problema teoricamente resolvido.
Deixo abaixo aqueles pontos que, nos últimos anos, têm sido para mim os principais a serem revistos, passando ao lado dos mais óbvios (datas, orçamento, público-alvo, etc.).
1. Hey! Pergunta ao designer.
Análise técnica do briefing
É crucial que o briefing de UX seja analisado com a equipa técnica (e aqui não me refiro exclusivamente a designers), para que possam ser levantadas as questões necessárias à correta execução do mesmo.
Muitas vezes, ao trabalhar em empresas com account managers e project managers, o designer não tem a oportunidade de falar diretamente com o cliente. Os pedidos são recebidos e ficam a aguardar a disponibilidade de alguém da equipa de design que, quando o for analisar, já irá estar em cima do prazo de entrega. Isto dificulta o trabalho, que será feito com base em pressupostos errados, ou atrasado desnecessariamente.
Enquanto UX designer e project manager, felizmente consigo questionar e ajudar o cliente a reanalisar o seu pedido de forma mais imediata. No caso de ausência desse conhecimento técnico, envolvam alguém que possa gerar dúvidas e antecipar possíveis problemas.
Contudo, é preciso ter em mente que irão sempre existir detalhes que, só quando o designer estiver focado a executar o projeto, é que irão ser compreendidos e questionados. O facto de haver algumas perguntas mais à frente é inevitável, mas quanto mais cedo este trabalho for feito, melhor.
2. Tenho uma ideia!
Avaliação das necessidades
Há pouco tempo li um artigo que argumentava que:
“Design does not oppose business. It transforms it into a viable form”
(O Design não se opõe ao negócio. Ajuda a torná-lo viável).
Não podia estar mais de acordo. Nesse sentido, a origem do pedido é fundamental para a sua compreensão, para termos a visão do negócio e para conseguirmos apurar a real severidade do problema para o utilizador.
Para podermos guiar melhor o cliente e propor uma estratégia de trabalho adequada, precisamos saber de onde partiram.
Foi uma análise dos dados disponíveis sobre um projeto existente (ex.: analytics)?
Feedback de diversos utilizadores?
Decisão estratégica de negócio?
É necessário mais pesquisa? Melhor compreensão do negócio junto de stakeholders? Definir melhor os objetivos junto de quem fez o pedido original?
Provavelmente, irá sempre haver pedidos para avançar com o trabalho sem mais detalhes ou bases factuais… mas não desesperemos! É importante reforçar os riscos associados, quer para o utilizador, quer para a viabilidade do próprio projeto (com impacto no negócio).
Só ao realçar e registar os riscos é possível, posteriormente, ter uma conversa sobre como os atenuar e avaliar quais foram os impactos dos mesmos.
3. Não vamos poder fazer isso.
Identificação dos constrangimentos
Dependendo da multidisciplinaridade da equipa em que trabalhamos, do cliente e do projeto em si, existem diferentes tipos de constrangimentos. Estes devem ser identificados o mais cedo possível, de modo a não desperdiçar tempo com pontos que não serão possíveis de executar no momento.
Este tópico ajuda também a identificar possíveis melhorias, ou a negociar antecipadamente porque é que algo não pode ser feito, e se há alguma forma de solucionar o constrangimento.
Muitas vezes, ao debater elementos de uma interface com a equipa de desenvolvimento, algo que não poderia ser feito da maneira A é possível ser feito da maneira B, com quase ou totalmente os mesmos resultados.
O mesmo se aplica a constrangimentos de negócio. Mas sem os conhecermos e endereçarmos, estamos a avançar às cegas.
Realço alguns pontos que têm sido cruciais para mim:
- Já existem os serviços de backend necessários à criação deste produto, elemento, etc.? Se sim, é preciso compreender as limitações.
- Quanto tempo tem a equipa técnica para desenvolver este pedido? É necessário compreender se, quando propomos uma solução mais complexa, será dado o devido tempo à equipa de desenvolvimento, ou se é possível repartir em diferentes fases/sprints.
- A vossa empresa já construiu alguma vez um produto/elemento semelhante a este? Qual foi a vossa experiência? Há algum caminho que já saibam que não querem tomar?
- Têm algum tipo de dados que possa ajudar na análise do problema e que exclua algumas possíveis soluções? (Exemplo: analytics, estudos de mercado, personas, informação de projetos passados e decisões relevantes que possam ajudar a perceber a perspetiva do negócio face a determinados tópicos relevantes, etc.).
Agora sim, o briefing
Só após esta revisão é que temos um briefing de UX fechado, a partir do qual podemos executar o trabalho com mais confiança, diminuindo o risco do projeto e melhorando os resultados do mesmo.
É verdade que este processo requer tempo mas, pela minha experiência, esse tempo ganha-se precisamente ao questionar e identificar possíveis problemas.
O cliente, ao ser confrontado com os mesmos, irá precisar de os analisar, e esse processo dá início a um ciclo de refinamento e iteração, em que, para cada resposta, poderá haver ou não mais dúvidas que levam eventualmente ao briefing final… mas não só!
Este processo permite também gerar ideias à medida que se debate a informação que é recolhida e se define, de forma mais ou menos orgânica, qual será a estratégia de trabalho para o projeto.
Além disso, os designers têm o problema crónico de serem vistos como meros executantes. Ao questionarmos a informação que nos é apresentada, criamos uma oportunidade para demonstrar que o nosso trabalho também é estratégico e baseado em dados.
Existe muito mais que poderia ser dito sobre cada um dos tópicos que aqui abordei e deixo o desafio de partilhem as vossas histórias, dores e estratégias connosco, para lançarmos o debate!
Também estamos disponíveis para vos ajudar a sensibilizar as empresas para uma boa gestão em UX e, para isso, podem espreitar a Certificação UX-PM.