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á?

Mapeamento da jornada do usuário apresentado pelo Product Owner.

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.

fonte: Senior Sistemas S/A, todos os direitos reservados.

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!