Como praticar UX em equipes ágeis
É possível encontrar o equilíbrio entre o design centrado no usuário e prazos rápidos.
Termos como agile, scrum, lean e MVP se tornaram comuns no mundo dos negócios desde os anos 2000. Por outro lado, muito de nós, UXers, em algum momento já abrimos mão de etapas fundamentais no processo de design para conseguirmos ganhar agilidade e caminhar no ritmo das equipes de desenvolvimento.
Pela nossa natureza criativa, tendemos a pensar na interface antes mesmo de terminar de ouvir o briefing. Mas, se ao invés de pensarmos em pixels, passássemos a tentar entender melhor nossos usuários?
Atualmente, temos uma bibliografia extensa de metodologias, que buscam colocar o usuário como foco do processo de design, entretanto, dependendo do contexto de cada empresa algumas delas podem se mostrar pouco viáveis, seja por falta de tempo disponível da equipe ou por nossa falta de compreensão de como torná-las viáveis.
O Gartner já propôs um formatos para conseguimos conciliar as metodologias como Design Thinking, Lean Startup e Agile.
Entretanto, sabemos que dependendo do estágio de maturidade de UX em cada empresa, propor um processo pode estar muito distante da realidade.
Diz aí.. quanto tempo você gasta para desenhar uma interface?
Um dia? Uma semana? Menos que isso?
Em algum momento nós já precisamos responder pelo menos uma destas perguntas e qualquer resposta pode se tornar um grande precipício que às vezes nós mesmos nos colocamos.
Se você trabalha com equipes ágeis, proponho que leve esta discussão a outro nível: ao invés de discutir sobre o tempo, tente abordar as suas entregas tendo como base os quatro princípio do Manifesto Agile:
- Indivíduos e interações mais que processos e ferramentas.
- Software em funcionamento mais que documentação abrangente.
- Colaboração com o cliente mais que negociação de contratos.
- Responder a mudanças mais que seguir um plano.
Percebeu, que não é citada a palavra "tempo"ou algum sinônimo? Pois bem, o foco do agile não é entregar rápido, mas priorizar a colaboração com a equipe e usuários durante o desenvolvimento.
Fortalecendo o discurso de UX alinhado aos princípios agile, aumentamos as chances de conseguir espaço para, aos poucos, inserir pesquisa com usuário e testes de usabilidade como natureza do processo de desenvolvimento.
Consegui o apoio da equipe, mas por onde começar?
Particularmente, acredito que as metodologias não são feitas para serem seguidas à risca, mas surgem como guias para aumentarmos o nosso “cinto-de-utilidades”. Para que isto seja possível, temos que desapegar da ansiedade de aplicar metodologias hype e passarmos a compreendê-las melhor.
“Se você tem uma boa compreensão dos princípios UX e Lean/Agile, sempre poderá encontrar o equilíbrio certo entre o design centrado no usuário e prazos rápidos.” — Alex Gamble
Algumas pessoas dirão que a metodologia x é melhor do que y, porém muitas vezes os processos de design mais eficientes não surge de uma única metodologia, mas sim da adaptação das melhores peças para tornar viável as práticas de UX dentro do contexto da sua empresa.
Deixo aqui alguma dicas que me ajudaram a iniciar sprints de design:
- Crie um mindset de design dentro da equipe.
- Escolha as ferramentas certas para cada contexto.
- Envolva o máximo de pessoas nas discussões sobre design.
- Chame os devs para discutir sobre os usuários.
- Nem toda funcionalidade merece uma sprint.
Nos próximos tópicos contarei um pouco sobre o processo de design no BLiP.
Como estamos fazendo…
Estudamos várias metodologias e encontramos muita informação teórica sobre design centrado no usuário, mas o não tanto para executar um passo a passo em ambiente ágil. Por isto, partimos para a montagem de um processo que se adaptasse ao nosso ambiente de desenvolvimento, sem perder a natureza agile e UCD.
Design Thinking, Lean UX, Agile UX, Circular Design, Design Sprint da Google Venture e principalmente o da Totvs, são alguns frameworks que nos influenciaram.
Com duração de 8 dias, dividimos o processo em duas fases — fazendo referência ao double-diamond. Na primeira fase passamos por etapas voltadas ao entendimento do projeto e do usuário, já na segunda fase o objetivo é obter o máximo de ideias, testá-las e validá-las.
Mas por que 8 dias e não 7, 6 ou 5?
A maturidade de UX da sua empresa pode ser ponto decisivo no desenho e escolha de frameworks.
Já havíamos tentando aplicar o Design Sprint da Google, o que não deu certo. Muitas vezes é praticamente impossível alocar pessoas-chave durante 5 dias consecutivos para participar das sprints de design.
Adaptamos um formato com duas "reuniões-marco" em que todos participam: entender o projeto e gerar idéias. As outras etapas são feitas pelo UXer (facilitador), com o objetivo de juntar material necessário para os demais participantes conseguirem ter embasamento durante as discussões.
Quem participa?
Convidamos pessoas com perfis e papéis diferentes no produto, que podem colaborar de forma significativa dependendo da funcionalidade.
Normalmente limitamos entre 5 a 10 participantes, mais que isto, podem fazer com que as discussões percam o foco. Além disto, tentamos garantir que pelo menos 2 devs participem, o que é fundamental para que as discussões e insights obtidos permeie facilmente durante a codificação.
#Dia 1: Entender o projeto
O entendimento do projeto em uma visão macro é fundamental para o sucesso de uma sprint, para isto respondemos algumas perguntas:
- Qual o desafio que estamos propostos a resolver?
- Por que estamos fazendo isto?
- Quais são as premissas do projeto?
- Quem são os stakeholders envolvidos?
- O que os stakeholders esperam?
A partir destas respostas, cada participante anota em post-its as suas certezas, suposições e dúvidas sobre o projeto. O objetivo é levantar insumo suficiente para mais tarde validar com os usuários tudo o que julgamos saber e não saber. Nesta etapa usamos a matriz CSD para obtermos mais foco durante a reunião e estruturar todos os pontos levantados.
Com a matriz CSD pronta, agrupamos post-its em assuntos comuns. Para cada assunto criamos perguntas que garantam com que as certezas sejam verdadeiras, que as suposições sejam validadas e que as dúvidas sejam esclarecidas.
Muitas vezes, as perguntas podem ir de hábitos de consumo do usuário à regras de negócio. O próximo passo é encontrar as pessoas certas que nos ajudarão a respondê-las.
Ferramentas: Matriz de alinhamento, Definição do desafio, Matriz CSD
Tempo médio: 2 horas de reunião
#Dia 2 e 3: Aprender com as pessoas
Durante dois dias, "saímos da nossa sala" e vamos atrás de conversar com outras pessoas para responder as nossas dúvidas.
Ouvir pessoas com características extremas aumentam a nossa visão, pois elas geralmente encontram soluções alternativas aos problemas existentes. Por isto, para recrutar pessoas para as entrevistas utilizamos do princípio de perfis extremos. Esta ferramenta é a chave para se conseguir explorar um problema ao máximo e aumentar a oportunidade de inovar.
Entrevistas
Cada entrevista pode durar de 15 minutos a pouco mais de 1 hora, dependendo da forma que é conduzida e do tempo disponível. O importante é levantar o máximo de informações para o projeto atual e sempre que possível, insights para projetos futuros.
Durante esta etapa, é recomendável que se consiga também dados quantitativos sobre o produto, exemplo: X usuários utilizam determinada funcionalidade, ou X usuários não finalizaram determinado fluxo. A união de dados quantitativos e qualitativos, só tende a agregar.
Ferramentas: Perfis extremos, Roteiro da entrevista, Entrevistas, Analytics.
Tempo médio: 2 horas de reunião e 40min por entrevista
#Dia 4: Encontrar padrões
Com todas as informações que você conseguiu, é natural que fique um pouco perdido sem saber o que é relevante ou não.
Para alinhar e categorizar o que foi descoberto, usamos o User Centered Design Canvas.
Lembra do "cinto-de-utilidades"? Esta é uma ferramenta que se encaixa bem no conceito. O UCDC é dividido em 9 campos: o lado esquerdo do canvas se concentra nos usuários, o lado direito no negócio.
A nossa abordagem com o canvas ficou um pouco diferente da metodologia inicial. Dividimos o preenchimento em 2 etapas, primeiro os campos Users, Problems, Motives, Fears, Alternatives com dados levantados anteriormente, já os outros campos ajudam mais tarde a guiar a geração de ideias, confrontando com o que foi descoberto com as soluções que serão propostas.
- Users: Quem são as personas do projeto? Quais características as identificam melhor?
- Problems: Quais são os problemas que a faria usar a funcionalidade X?
- Motives: O que motivaria a utilizar o nosso produto?
- Fears: Quais os medos ela tem em relação a funcionalidade X? Quais os medos em relação ao nosso produto?
- Alternatives: Para resolver o problema, quais soluções alternativas ela utiliza?
Ferramentas: UCD Canvas, Jornada do usuário, Diagrama de afinidade.
Tempo médio: 3 horas dependendo da quantidade de material.
#Dia 5: Gerar ideias
Com todas as informações que precisamos à mesa, reunimos os participantes da sprint para apresentar o que foi descoberto na missão de ter o máximo de ideias.
Aqui o UCD Canvas entra novamente para guiar esta etapa. É o momento de preencher os campos de Solutions e Competitive Advantages.
Durante 15 minutos cada participante anota em post-its suas ideias tentando responder algumas perguntas, como podemos:
- Resolver os problemas/necessidades dos usuários?
- Apoiar as suas motivações?
- Mitigar seus medos?
- Quais os diferenciais competitivos estamos propondo com cada ideia?
Com todos insights anotados é feita uma rodada em que cada participante apresenta a sua ideia. O legal nesta parte é motivar os outros participantes a tentar agregar valor na ideia que está sendo apresentada.
Priorizando as ideias
Com a matriz de impacto vs. esforço, os participantes da sprint distribuem suas ideias em quatro quadrantes:
Normalmente, em nossas sprints optamos apenas pelas ideias presentes nos dois quadrantes que demonstram ter alto impacto para o usuário (essencial e estratégico).
Ao final desta etapa temos uma lista de ideias prontas para prototipar e testar.
Ferramentas: How might we, Matriz de impacto vs. esforço.
Tempo médio: 3 horas de reunião.
#Dia 6: Prototipar
Enfim, chegou a vez de botar a mão na massa.
Agora é reunir as ideias priorizadas e transformá-las em interfaces, com fidelidade necessária para a validação com os usuários.
Ferramentas: Papel, Sketch, Invision.
#Dia 7 e 8: Testar, validar e iterar
Em matéria de UCD, o teste de usabilidade é muito discutido: como fazer, investimento e materiais necessários, etc.
Na prática é possível fazer testes de usabilidade com pouco recurso e em pouco tempo, os famosos "testes rápidos". Apesar de metodologicamente não serem recomendados, percebemos que dá para conseguir muitos feedbacks e ter grandes insights.
É importante que durante os testes você faça o máximo de anotações e compile os resultados para apresentar para a equipe para que juntos discutam quais mudanças deverão ser feitas.
A planilha de sugestões para teste de usabilidade contém os campos de:
- Quem / Persona: Identificação do usuário para que, se necessário, fique mais fácil tirar alguma dúvida mais tarde. Dependendo do contexto vale apenas citar em que persona ele se encaixa.
- Observação: O que foi observado, qual o sentimento o usuário demonstrou.
- Sugestão de melhoria: Anotação sobre alguma sugestão deixada pelo usuário, ou mesmo, sugestão do próprio facilitador do testes.
Ferramentas: Teste de usabilidade, Planilha de sugestões.
Alguns resultados que alcançamos
Ao tornar este formato de design sprint como parte do nosso processo de desenvolvimento, experimentamos algumas melhorias importantes:
- Mais foco nas reuniões voltadas a criação.
- Time com maior envolvimento com o produto e empatia com o usuário.
- Funcionalidades criadas com foco na entrega de valor .
- Decisões tomadas com base em pesquisas com usuários e dados.
Este foi um resumo do nosso processo de Design Sprint, não é uma receita de bolo. Espero que este post possa te ajudar a aumentar o seu "cinto-de-utilidades".
Agora, diz aí.. qual o seu processo?… Deixe seus comentários. 😉
