Entregando UX Design no Agile
Hoje vou compartilhar algumas lições apreendidas trabalhando no processo de Design em uma equipe Agile. Irei comentar um pouco sobre o desenvolvimento deste processo, o papel do UX Designer e o que aprendi aplicando ele na prática em uma Design Sprint. Vamos lá?
Definindo o processo de Design
Nosso time de design trabalhou para definir um processo que atendesse as demandas dos times agile. Este processo ainda está em fase de amadurecimento e experimentação.
Iniciamos o processo nos apoiando em etapas de descoberta e definição, onde buscamos entender a fundo as dores de nossos usuários e clientes afim de solucionarmos estes problemas.
Após este entendimento dos problemas dos usuários, partimos para a prototipação e validação, avaliando se a solução está alinhada com os requisitos propostos pelo Product Owner e se atende as necessidades do usuário.
Papel do UX Designer
O UX Designer deve garantir que o processo de Design e a implementação do desenvolvimento sejam orientados a dores reais dos usuários e clientes, envolvendo e comunicando o time através da cocriação.
O processo de cocriação envolve principalmente o UX Designer e o Product Owner, definindo as prioridades das User Stories, fornecendo ferramentas de pesquisa (UX Research) e de entendimento do usuário.
O processo deve ser constantemente reavaliado conforme os resultados são revelados, fazendo adaptações e utilizando ferramentas que intensifiquem a compreensão e comunicação entre cada uma de suas fases.
A construção deste processo é aplicada de forma colaborativa, garantindo que todos estejam alinhandos em relação a expectativa do que será entregue ao final de cada sprint.
Design sprint
Enfim, chegou a hora de colocar a mão na massa! Após diversas conversas com o Product Owner para alinhar o escopo de negócio, ouvir as dores do usuário através de entrevistas, juntamos o time de desenvolvimento, de testes e de documentação técnica para iniciar a Design Sprint.
Nós criamos nossa própria versão de Design Sprint, baseada em uma abordagem mais enxuta do Google Design Sprint. Ela aconteceu 2 semanas antes da Release Planning.
1) Entendendo o contexto do usuário
Duração: Workshop de 2h 30min em um único dia.
Nesta etapa definimos que o Product Owner iria iniciar apresentando a dor do usuário de umas das user stories que definimos no escopo da solução, então juntamente com o time mapeamos a jornada de 3 personas, e para cada uma destas personas aplicamos uma ferramenta chamada de é, não é — faz, não faz.
Esta ferramenta foi muito útil para fazer o time enxergar pelos olhos do usuário, ajudou no entendimento do que era o produto e quais necessidades ele faz ou não faz. Vale apontar que o objetivo inicial desta dinâmica era trazer insights e criar um entendimento geral das informações com o time.
Após aplicarmos esta ferramenta, o time, guiado pelo Product Owner, fez um agrupamento das informações que possuiam relação e as priorizou conforme as necessidades do usuário.
2) Etapa de divergência e sketch em grupo
Duração: Workshop de 3h 30min dividido em 2 dias.
Juntamos todas as informações levantadas na etapa de entendimento e definimos “Fluxos do Usuário” e o time começou a criar sketches no papel para cada uma das dores mapeadas nestes fluxos.
O sketch no papel consiste em desenhos de baixa fidelidade de partes do fluxo e/ou interações específicas. Foi estabelecido um intervalo de tempo para que o time trabalhasse nos sketches para cada uma das personas. O time apresentou boas idéias para a solução.
3) Etapa de decisão e escopo da solução
Duração: Workshop de 1h 30min em um único dia.
Penduramos então os protótipos na parede lado a lado e cada um dos integrantes do time apresentou sua solução para o fluxo/interação propostos.
Após esta apresentação, o time utilizou o dot voting para priorizar quais são as soluções mais interessantes (azul), as soluções que não atendem (vermelho) e as soluções que podem ser desenvolvidas no futuro (verde).
Recolhemos os protótipos após a votação e encaminhados para o UX Designer, que compilou todas as informações para iniciar a prototipação em baixa fidelidade.
4) Prototipação em baixa fidelidade
Duração: Imersão de 16h divididas em 3 dias.
Nossa prototipação foi baseada nos insights gerados pelo time e pelas decisões tomadas na etapa anterior. Esta etapa é exclusiva do UX Designer pois neste caso ele é a autoridade no processo de User Interfacing (UI).
Desenvolvi 3 protótipos no papel, um para cada persona. Defini como premissa que todos os protótipos fossem interativos, para que pudessem ser validados com usuários e com o time na etapa seguinte.
Durante a prototipação eu interagi diversas vezes com o Product Owner para validar conceitos novos que surgiam com o detalhamento da solução, cada caso foi tratado individualmente mas no final a proposta ficou fiel a expectativa do time do Design Sprint.
5) Validação dos protótipos
Duração: Workshop de 1h divididas em um único dia.
Segmentamos as validações em 2 etapas:
- De forma informal com alguns membros do time — durante o desenvolvimento do protótipo essas micro interações aconteciam principalmente entre o Designer, Analista de Sistemas e Product Owner. Desta Forma garantimos que a solução estava alinhada com a proposta feita pelo time durante a Design Sprint;
- No momento do planejamento com todo o time — quando começamos a orçar as sprints durante a Release Planning, o time todo reviu os protótipos e deu sua contribuição sobre o resultado, levantando insights relevantes a implementação dos protótipos nas sprints do próximo release.
Lições aprendidas e conclusão
Minha experiência aplicando o processo de Design em um desenvolvimento de produtos Agile gerou os seguintes insights:
- Nosso principal papel como UX Designers é de mediar a comunicação entre todos os atores do processo tornando a visão do usuário concreta para o time;
- Percebi que a qualidade das entregas de UX esta diretamente ligada na relação entre UX Designer e Product Owner, tornando evidente nossa responsabilidade de mapear o processo de UX com o usuário e entregar para o Product Owner converter e priorizar as regras de negócios;
- O Design Sprint melhorou muito a entrega dos times agile, a assertividade na hora de orçar as sprints e consequentemente a qualidade do produto como um todo;
- Realizar validações/testes com usuários e o time o mais cedo possível, principalmente durante e após a prototipação;
- A importância de sistemas de Design em times Agile. Quanto mais maduro o sistema de Design menos custosa será a entrega e mais tempo o UX Designer poderá focar na pesquisa e entendimento das dores do usuário;
- Utilizar o Design Thinking como framework das dinâmicas da Design Sprint, sendo que quanto mais colaborativo o processo maior foi o entedimento e o engajamento do time e melhor o resultado da solução entregue;
- A documentação do processo de Design é fundamental para mostrarmos o valor para outros times e também para garantir a escalabilidade do nosso trabalho;
- Utilizar métricas que façam sentido para medir os resultados. Foi difícil definir métricas porque nesta fase de experimentação o resultado esperado da aplicação do processo é muito abstrato.
Para finalizar, acredito que a maior lição aprendida é de que não existe processo mágico para resolver todos os seus problemas, leve em conta que flexibilidade e experimentação rápida são as chaves para escalar soluções de qualidade e que tragam valor para o usuário.
Confie no seu time, não tenha medo de compartilhar informações e de escutar feedbacks de pessoas que não estão habituadas ao processo de UX. Mantenha o foco e sempre busque o caminho da simplicidade, FÉ NO PROCESSO!
