Como evoluímos a consistência nas entregas para o time de desenvolvimento

Nesse texto gostaria de compartilhar como estamos fazendo o handoff de um produto que será lançado em breve aqui na Dasa, quais eram os problemas que enfrentamos e como melhoramos esse processo aqui na squad.

Exemplo de como desenhamos a anatomia de um componente.

Para quem já está familiarizado com entregas de UI para o time tech, sabe que esse processo não é tão simples como se imagina.

Não é só disponibilizar as telas de forma nu e crua e voilá, o time saberá exatamente como desenvolve-las, entender todas as interações, aplicações, estados dos componentes, interações, acessibilidade e por ai vai. É necessário que o designer passe essas telas para um formato mais técnico e abrangente.

Por aqui, os devs do time tem vivências diferentes com o processo de handoff, em suas experiências passadas, uns recebiam telas com comportamentos e states dos componentes no Zeplin, uns no Adobe XD e outros recebiam um fluxo no miro ou whimsical descrevendo a navegação.

Até pouco tempo, o time de design trabalhava com a seguinte stack: Abstract + Sketch + Zeplin + Whimsical(Miro) + Invision, era um processo de trabalho bem oneroso, e no handoff sempre surgiam dúvidas e inconsistências pelos desenvolvedores.

Com todas essas ferramentas e um processo nada simplificado, adotamos o Figma como principal stack de trabalho, antes o versionamento feito pelo Abstract, desenho das telas no Sketch, handoff no Zeplin, Whimsical para fluxo e Invision para protótipos, passamos a fazer isso tudo direto no Figma.

Dito isso, quero compartilhar com vocês como aplicamos essas mudanças:

1 — Kick-off

Fizemos uma apresentação sobre como dividimos os entregáveis para o time e quando acessar cada arquivo.

Os entregáveis para o time de desenvolvimento.

2 — Parceira com o time do Design System e Ops

Após isso, começamos a usar um modelo de handoff feito pelo time do ALMA, o design system da Dasa, que conta com boas práticas de aplicações, com descrições do que é padding, margin e anatomia dos componentes com as estilizações em CSS apontando para os tokens do ALMA.

Pude colaborar trazendo para esse processo um plugin chamado Redlines, que ajuda a mensurar as distancias dos elementos(padding e margin), faciltando para os devs na hora de trabalhar na construção da anatomia dos componentes.

Prancha que usamos para detalhar os componentes com as variações e interações esperadas.

3 — Detalhando o handoff

Nessa parte, buscamos ir a fundo em regras importantes, como limite de caracteres, empty states, erros sistêmicos, interações e acessibilidade. Tudo que pudermos deixar definido para o time, quando chegar no Design Review (por aqui temos uma coluna no Jira onde fazemos o design review das tarefas da sprint) irá ajudar o que validar e como validar, bem como introduzir cenários que não foram previstos.

Dica: Use o site codepen.io para buscar referências dessas interações ou como você imagina esse efeito aplicado, isso ajuda bastante o time tech a entender o que você está pensando.

Como descrevemos a anatomia do componente.

4 — Fluxo das entregas

Além do handoff, entregamos também um fluxo onde é explicado os caminhos do que a feature resolve, não apenas o caminho feliz. Isso ajuda não só o time tech, mas também o time de produto e sponsors a entender se deixamos de cobrir algum passo nos testes com usuários ou até mesmo nas user stories.

Entregamos também um protótipo daquela feature totalmente navegável, onde as interações serão os pontos principais de atenção.

Anexamos todos esses links no confluence no Jira para que fosse uma documentação de rápido acesso para o time, além de estarem presentes nas tasks os links descrevendo como material de apoio.

5 — Comunicação contínua é a chave para consistência

Alinhe com o seu time sobre como está sendo todos esses entregáveis. Colha feedbacks também, por aqui rodamos um form com o time, é importante ouvi-los nesse processo.

No final, os entregáveis foram:

• Prancha do handoff para desenvolvimento;
• Fluxo com todos os cenários previstos;
• Protótipo navegável.

Parece bastante coisa, eu sei, mas seguir boas práticas podem fazer a diferença em uma entrega como essa ser consistente, como:

• Todas as telas usadas utilizarem de uma library, assim, ao atualizar um componente, você terá atualizado em todos os arquivos conectados à ela;
• Ter seus componentes ligados ao Design System, além da consistência visual, questões ligadas à padrões e acessibilidade já estão previstas;
• Faça design review junto ao time tech, consistência é a chave;
• Faça Pair validade(aqui chamamos de pair validade quando um designer de outro squad te ajuda nas validações).

Após esses entregáveis, já colhemos bons resultados, como:

• O entendimento do time sobre o que as entregas se tratam ficaram muito mais claras, reduzindo o número de reuniões sobre o assunto;
• A consistência entre o que foi projetado e desenvolvido aumentou, diminuindo o tempo que as tarefas ficam presas no Design Review;

Nos próximos passos queremos trabalhar melhor as especificações de acessibilidade dos componentes e interações.

E vocês? Como aplicam o processo de handoff com time e quais são os aprendizados até agora? Conta pra gente aqui nos comentários ;)

Referências

https://zeroheight.com/7a44c04f2/p/40ca77-alma
https://pro-nav.dasa.com.br/

E um agradecimento especial para o Ricardo Goya, por ter ajudado na revisão e ideias para esse texto, você é foda o/