Na Concrete Solutions, somos sempre guiados pelo desenvolvimento ágil. Acreditamos em pessoas mais que processos, software em funcionamento mais que documentação, resposta a mudanças mais que seguir um plano etc. Entretanto, o design clássico prega começo, meio e fim de projetos (pesquisa, análise, prototipação e projeto final), o que entra um pouco em conflito com o ágil e acaba se aproximando um pouco mais de waterfall. Nesse contexto, tive a ideia de clarear um pouco como funciona o trabalho de um designer no desenvolvimento ágil, especificamente na Concrete. Para isso, dividi o processo em basicamente duas partes: Discovery e a Construção efetiva. Vamos lá?

1. Discovery

a) Entendendo o problema

O primeiro trabalho de um designer em um time de desenvolvimento ágil que se propôs a desenvolver um produto é descobrir se o problema que estão tentando resolver vale a pena ser resolvido. Para isso, é necessário criar um entendimento compartilhado entre times e stakeholders sobre o problema, o negócio e os usuários. Nesta fase, definimos quem são as personas com as quais vamos trabalhar, respondendo a perguntas como “o problema de quem vamos resolver?”, “o que essa pessoa gosta de fazer?”, “quais são os hábitos dessa pessoa”, “com que frequência ela acessa a Internet”, e assim por diante. Essas perguntas podem ser respondidas pelo time e stakeholders, mas vale também uma pesquisa mais extensa para chegar às respostas. O ideal é ir para campo e falar com o usuário/cliente na rua, e não decidir tudo isso dentro do prédio onde o time trabalha. Entretanto, tudo depende da complexidade do projeto, do quanto de informação nós já dispomos etc.

É também na fase de discovery que temos que definir quais são as métricas que vamos usar para medir o sucesso do nosso produto. Afinal, temos diversas maneiras de medir o sucesso: pode ser números de downloads, usuários ativos, receita, redução de custo, diminuição do tempo necessário para executar uma ação, taxa de conversão, número de acessos, porcentagem de engajamento etc. O importante aqui é ter uma forma de medir se o meu produto está dando certo ou não e se devo invalidar ou persistir em uma hipótese. Por fim, usamos essas informações que levantamos para preencher um Canvas (você pode saber um pouco mais neste artigo antigo).

b) Explorando o problema

A partir do momento em que temos todas as informações possíveis sobre o problema, é hora de pensar em todas as possibilidades de resolvê-lo. Neste momento, não é preciso se preocupar se é possível ou não realizar essas possibilidades, é importante apenas expô-las. Isso porque uma solução que parece inviável inicialmente pode se provar uma ótima hipótese no futuro. A ideia é ampliar as possibilidades para poder abarcar todas as informações recebidas e trabalhar de forma a buscar possíveis soluções.

Neste momento, também podemos montar as jornadas do usuário. Em que momento ele começou a perceber que tem um problema a ser resolvido? Depois, quando é que ele começa a pensar em qual seria a solução para esse problema? E quando efetivamente ele decide comprar uma solução? Com esse mapa nas mãos, fica muito mais fácil partir para o próximo passo.

c) Selecionando caminhos

Com várias hipóteses nas mãos, vamos escolher as ideias mais adequadas para solucionar o problema identificado, considerando também, agora, quais delas são as mais viáveis. Neste ponto, é importante eliminar soluções que resolvem o mesmo problema, ou seja, garantam que você não escolheu mais de uma solução para testar a resolução do problema que você definiu. E aí monte um storyboard para o protótipo, ou seja, defina qual história você vai contar para cada um de seus usuários para testar se a sua ideia é mesmo boa. Vale também desenvolver um script para guiar as entrevistas com os usuários (cuidado aqui para não sujar seus dados induzindo as respostas) e montar uma lista de hipóteses que pretendemos validar com o protótipo “na rua”.

d) Protótipo

Ação! Precisamos criar um protótipo, da forma mais rápida e barata possível, que nos permita validar as hipóteses que levantamos anteriormente. Neste artigo, eu falo um pouco sobre o assunto, tem algumas dicas para esse processo (de product discovery) neste do Victor Lima, e o Fernando de la Riva também deu algumas fontes de estudo para o assunto neste texto aqui. Se você quiser aprender mais, vale a dica.

e) Teste

E o último tópico dessa primeira fase é: testar! Faça os testes com usuários reais, identificados. Entreviste as pessoas, extraia o máximo possível de informações e identifique se as suas hipóteses estão de acordo com o que está acontecendo na prática. Observe os usuários utilizando o protótipo: eles estão tendo alguma dificuldade? Está faltando algo em que você não tinha pensado antes? É a sua chance de melhorar o sucesso do seu produto. Escute o seu usuário, é surpreendente a quantidade de coisas “óbvias” que não percebemos sozinhos quando estamos muito envolvidos no projeto.

E assim chegamos ao fim do discovery inicial do produto. A partir dele, a ideia geral será validada ou não. Depois dessa validação, temos o discovery contínuo, em partes menores, mais localizadas, que servirá para validação de features específicas. Mas isso já é na segunda fase do trabalho, a construção.

2. Construção

E só depois que entendermos a fundo o problema, traçarmos um caminho inicial, definirmos um MVP e um Backlog, podemos começar. Nesse ponto, o designer trabalha em duas frentes: no “refining” do backlog e na relação com os desenvolvedores, aqueles que vão efetivamente fazer o código do produto.

a) Refinar o backlog

Antes do Planning, ou seja, durante o sprint anterior, é preciso refinar o backlog. Para isso, é preciso que o PO, o designer e o tech lead participem e garantam que durante o Planning o time tenha o melhor entendimento possível de todos os itens e faça uma boa estimativa. Nesse processo, o ideal é que seja possível validar as histórias que já foram escritas pelo PO, então vale um “mini design-sprint”, assim como fizemos no Discovery.

Depois disso, já podemos evoluir os layouts e assets e prepará-los para a implementação. Ferramentas como o Zeplin, Sympli, Avocode etc. são cruciais para a agilidade nesse momento, além de garantir que os próprios desenvolvedores consigam exportar os assets diretamente de um repositório. Dessa forma, se garantirmos a continuidade desse processo, teremos sempre itens validados, desenhados e com uma base de assets (que foram usados nos protótipos) disponível para os desenvolvedores.

b) Relação com os desenvolvedores

O ideal é conseguir distanciar o processo de refining do desenvolvimento o suficiente para que sempre que se inicie o processo de construção, os desenvolvedores tenham tudo à disposição e não tenhamos gargalo. Normalmente, isso acontece quando temos um designer para no mínimo quatro desenvolvedores. De acordo com a minha experiência, o tempo ideal é que o refining seja uma ou duas histórias antes do início do desenvolvimento.

A partir daí, acompanhamos a implementação, revisando o que for necessário. E aí, com testes automatizados, Integração Contínua e gerando releases, estamos prontos para testar em produção.

Ficou alguma dúvida, tem algum comentário ou quer conversar? Deixe sua contribuição abaixo. Até a próxima!