Concrete Logo
Hamburger button

O que aprendi como designer em um time ágil

  • Blog
  • 24 de Novembro de 2017

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 sobre 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 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 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 de 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 em uma 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 onde entra o designer nisso tudo?

Nesses dois anos já trabalhei em times ágeis de duas formas: na primeira delas 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, 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 clientes;
  • 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 aos cliente e ao 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 abandoná-lo 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 a todos os desenvolvedores do time, que por sua vez 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 vai ser o produto, o padrão de layout e as interações, ou seja, o padrão visual e as interações 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 fez pensar, deixe um comentário aqui embaixo. Até a próxima!

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