O que aprendi como designer em um time ágil

Assim como a maior parte dos designers que conheço, aprendi a ser designer em um ambiente waterfall. Isso significa, mais ou menos, um “faz tudo e entrega tudo, se der errado refaz tudo e entrega de novo”. Durante um tempo me questionei qual seria o papel de um designer em um time multidisciplinar e ágil, como as famosas squads do Spotify.

Bom, há dois anos estou vivendo este mundo e acho que agora já posso compartilhar um pouco dessa experiência. Como é trabalhar junto e ao mesmo tempo em que os desenvolvedores?

O foco de um ambiente ágil é entregar o máximo valor possível ao usuário com o mínimo de esforço do time, e depois iterar continuamente em cima deste mínimo esforço. O mindset é: “Build, Measure and Learn”, ou seja, “Construir, Medir e Aprender”. Com isso, você pode fazer mudanças menores, sempre baseadas em feedbacks dos usuários, e conseguimos colocar funcionalidades novas em um espaço de tempo menor. Ou seja, o usuário não precisa esperar meses para ver algo novo, está sempre recebendo atualizações com real valor para ele.

Quando cheguei a essa cultura, percebi logo na primeira sprint a diferença entre o novo e o antigo trabalho. Se antes eu me dedicava a todas as telas do produto ao mesmo tempo, passava horas layoutando ou montando inúmeros wireframes e depois muitas vezes tinha que refazer todos eles, agora eu trabalho ao lado dos desenvolvedores, PO, Scrum Master e todos do time. Os contextos passaram a ser mais específicos, com foco sempre em uma etapa da jornada, e não no todo, com entregas a cada duas semanas e iterações durante todo o tempo de desenvolvimento.

Nos tempos de agência era necessário criar vários entregáveis baseados em um briefing ou demanda. Eu montava um fluxograma, um mapa do site, um wireframe, um layout e um protótipo; às vezes rolava um teste com usuário, às vezes não; quando rolava tinha a documentação do teste. De toda forma, cada entregável desses gerava uma apresentação, e-mails infinitos e uma possível reunião para validar. Ou seja, no final do projeto eu tinha em mãos muito material bem detalhado que nem sempre chegava nas mãos de quem iria desenvolver, e quando chegava nem sempre era uma solução viável tecnicamente.

Com Scrum, isso mudou consideravelmente. Não sou mais obrigado, a gerar tantos entregáveis, afinal trabalho lado a lado com o cliente e com o time de desenvolvimento, em um processo de co-criação. Passei a pensar em criar uma experiência que funcione para o usuário e para o time que vai desenvolver a solução. Não existe mais aquela guerrinha entre desenvolvedores e designers, pois ambos estão construindo um produto juntos, a solução técnica é decidida por todo o time. Muito menos aquela guerra com o cliente pedindo alteração, pois ele participa ativamente das tomadas de decisões. Aprendi a dar mais valor aos rabiscos feitos numa reunião com todo o time do que a um layout cheio de tendências, lindo, que pode não funcionar em um mundo real.

Beleza, já falei dos benefícios do ágil em si. E como entra o designer nisso tudo?

Nesses dois anos já trabalhei em times ágeis de duas formas: na primeira delas eu atuei na mesma sprint que o time de desenvolvimento, ou seja, desenhei, prototipei, testei e especifiquei a mesma feature que o restante do time. Na segunda eu trabalhei uma sprint à frente, ou seja, o time só vai desenvolver as telas que eu estou trabalhando na próxima sprint. Para mim, particularmente, a segunda opção funciona melhor, pois consigo pensar mais no usuário e tenho mais tempo para errar, afinal posso ajustar minhas telas de acordo com o feedback do meu usuário.

É claro que mesmo atuando uma sprint à frente, precisei ser mais ágil do que era nos tempos de agência. O fluxo de trabalho agora é o seguinte:

  • Refinar um assunto com meus clientes;
  • Recolher os requisitos com PO e cliente;
  • Montar um fluxo (no papel ou em post-its);
  • Rabiscar muito;
  • Prototipar em baixa fidelidade;
  • Testar com usuário;
  • Desenhar a interface;
  • Prototipar em alta fidelidade;
  • Testar com usuário;
  • Ajustar e retestar;
  • Especificar tudo, para que os desenvolvedores possam trabalhar nessa feature na próxima sprint;

Claro que essa não é um receita de bolo, é preciso adaptar esse fluxo ao seu contexto. Por exemplo: às vezes tem protótipo de alta fidelidade, às vezes não, às vezes tem rabisco, às vezes não… É importante entender que tudo em ágil é adaptável. Também tenho dicas de algumas ferramentas que ajudaram a otimizar o meu trabalho e a integrá-lo com os do cliente e do time de desenvolvimento.

Esse aqui é o arsenal de ferramentas que uso durante uma ou outra sprint.

Sketch: Já falei dele aqui. É nele que crio meus wireframes e meus layouts.
Photoshop: Não consegui abandonar por completo, infelizmente, pois ainda preciso editar uma ou outra imagem. Mas ele vem sendo útil apenas nestes casos.
Axure: Uso quando preciso criar wireframes navegáveis, com muitas possibilidades de fluxos.
Principle: Meu fiel escudeiro em protótipos de alta fidelidade. Para criar animações e transições mais trabalhadas.
Abstract: Torna a árdua tarefa de trabalhar com vários designers em um mesmo projeto ou arquivo uma tarefa mais simples. O Vitor Guerra escreveu essa bíblia do Abstract que vale a pena ler.
Invision: Meu repositório de interfaces. Para validar layouts com PO e cliente, criar protótipos navegáveis e testá-los com o usuário.
Jira: É lá que o(a) PO escreve as histórias e é por lá que consigo gerenciar as tarefas que preciso entregar durante a sprint.
Sympli: Aquela ferramenta de especificação que você respeita. Se você quer que o layout do seu produto fique igual ao que você desenhou, é isso aqui que vai te ajudar. Existe também o Zeplin e o Inspect do Invision, que funcionam bem também.
Google Slides e Google Sheets: Para documentar, tabular e apresentar resultados dos testes com usuário.
Google Forms: Para criar formulários de pesquisa com o usuário.Quicktime: Para gravar as sessões de testes de usabilidade.
Post its: Para montar jornada, fazer card sorting, até mesmo para uma sessão de ideação com o cliente.
Slack: Para comunicação entre o time. O legal é que o slack possui integração com diversas ferramentas, por exemplo: assim que faço upload de uma tela no invision ele já avisa todos os desenvolvedores do time e eles já podem ver e comentar.

Pode parecer que trabalhar pequenas partes do todo acarrete em um produto sem padrão, contraditório e confuso. Para evitar que isso aconteça, tanto o designer quanto o time precisam ter em mente a ideia tangível de como será o produto, o padrão de layout e as interações, ou seja, os dois precisam ser escaláveis. Isso vai evitar que em futuros incrementos o produto se torne um Frankstein. Uma biblioteca de padrões é a ferramenta mais certa para evitar que isso aconteça com o seu produto, e se você se interessar o Sketch lançou recentemente uma forma bem legal de trabalhar com bibliotecas.

Trabalhar em um ambiente assim, usando o Scrum como principal framework de trabalho, me trouxe diversas experiências pessoais e aprendizados técnicos num espaço tão curto de tempo, que hoje já não me imagino trabalhando em outro contexto e nem sei o quão duro seria aprender tudo isso fora desse ambiente.

E você? Tem alguma experiência com ágil ou waterfall que não descrevi aqui? Compartilhe suas experiências também! Minha motivação para escrever é saber que fui relevante para alguém, por isso se alguma coisa neste texto te fiz pensar, deixa um comentário aqui embaixo. Até a próxima! 👏

É designer e quer trabalhar em um time ágil de verdade? Clique aqui!

Like what you read? Give Raniel Oliveira a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.