Concrete Logo
Hamburger button

O papel do designer no desenvolvimento ágil

  • Blog
  • 13 de Abril de 2016
Share

Aqui na Concrete Solutions somos sempre guiados pelo desenvolvimento ágil. Acreditamos em pessoas mais que processos, software em funcionamento mais que documentação, resposta à 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 aqui 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 o 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 e 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 nesse post antigo do Blog).

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. Nesse 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 este 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 nas ideias mais adequadas a 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, garanta 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 post eu falo um pouco sobre o assunto, tem algumas dicas para esse processo (de product discovery) neste post do Victor Lima, e o Fernando de la Riva também deu algumas fontes de estudo para o assunto neste post 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 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 e 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 dai 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!