Estruturando um processo de revisão de componentes em um Design System
No nosso time, não são os designers dedicados ao Design System que constroem os componentes; essa tarefa fica a cargo dos Product Designers envolvidos nas diversas frentes de produto.
Como parte do processo uma coisa fundamental seria adicionar etapas de revisão no fluxo de trabalho dos PDs para ver se estavam construindo as coisas alinhado com os padrões definidos por Design System. Eis que surge a DS Review.
A DS Review, ou Design System Review tem como objetivos:
- Garantir que os componentes atualizados estão sendo aplicados corretamente;
- Identificar oportunidades de melhoria nos componentes, documentações e bibliotecas;
- Identificar oportunidades de criação de novos componentes;
- Identificar sinergia entre necessidades (é relativamente comum um designer estar atuando em um componente que outro designer também precisa);
- Educar os PDs em relação ao uso do Design System;
- Ouvir feedbacks sobre o uso do Design System: A DS Review é um papo 1:1 de 1h no total e como todos nós sabemos, é sempre muito rico ouvir o nosso cliente, né?
O início
Antes de estabelecer a DS Review como parte do processo, a gente tentava resolver a vida nas Design Critiques, que além de ser uma etapa obrigatória a presença do time DS, também é.
No começo, eu organizava as agendas e facilitava com o apoio do time de UX Writing tomando notas. Um tempo depois, compilamos todo o processo de construção, dicas e aprendizados em um playbook para permitir qualquer outro designer estruturar e rodar a sua própria Critique.
E olha só que legal: Você pode acessar esse material através desse link aqui.
Com o tempo, percebi que só as Critiques não eram suficientes para fazermos todos apontamentos sobre o uso correto dos componentes. Começamos a instruir os designers a puxarem papos isolados para falarmos no detalhe. Isso se tornou recorrente, logo, vi a oportunidade de estabelecer como processo. BOOOOOM! DS Review ✨.
Algum tempo rodando Critiques, percebi que as discussões se concentravam em falar da experiência de uso olhando para navegabilidade, regra de negócio, cenários de erro e afins. Discutir isso no detalhe é importante para garantir a entrega da melhor experiência possível para o cliente final, tal como ir ainda mais no detalhe, e discutir o componente da tela, o botão, a cor e o ícone.
O time de DS participar dessa agenda, tem um ganho ENORME pra todo mundo! Pensa só, é uma reunião de 1h-1h30, geralmente com mais de de 10 designers de diferentes produtos ouvindo você comentar qual deveria ser o componente certo a ser aplicado e também discutindo padrões. E também observando os próprios PDs apontando e questionando o uso de padrões. Praticamente um Focus Group, né?
Estruturando e rodando uma DS Review
Inicialmente, na Critique já falávamos para o PD agendar um papo de 1 hora com alguém do time de DS (1 ou 2 pessoas. Geralmente Eu + o DS Designer responsável pela plataforma, web ou app). Rodamos por um tempo nesse formato e aprendemos que:
Era comum a gente travar em alguns casos de uso e ficarmos discutindo entre a gente (galerinha do Design System) enquanto isso o PD lá, só assistindo.
Geralmente eram discussões ricas, que fazia sentido o PD acompanhar para aprender mais sobre o DS, como a gente fazia e decidia as coisas, porém, isso sempre fazia com que o tempo da DS Review fosse além da 1h agendada e essa reunião começava a ficar improdutiva e cara (tempo = $).
Uma das premissas para o nosso modelo de trabalho funcionar é ter processos bem otimizados para os PDs, sendo assim quebramos a DS Review em 4 momentos, sendo 3 deles com a participação do PD.
- DS Review — Introdução: Agenda de 30min puxada pelo PD para apresentar novamente o fluxo e a gente enquanto DS, tirar dúvidas. Essa agenda pode ser puxada logo após a Critique (mesma semana) ou depois de um tempo (1–2 semanas). Independente de quando acontece, vimos que não tem problema o PD precisar explicar novamente o fluxo, já que nem sempre todo mundo consegue participar da Critique, além de que as vezes o PD já havia feito ajustes nas telas.
- DS Review — Grupo de trabalho: Com agendas marcadas ou não e com tempo de 1 a 3 dias para fazer. Esse é o momento em que o time de DS para pra analisar no detalhe cada tela, discutir (quando necessário) e fazer apontamentos para depois devolver ao PD. Para ajudar a gente nisso, estabelecemos um template de DS Review.
- DS Review — Devolutiva: Agenda de 30min puxada pelo time de DS para apresentar ao PD todos os apontamentos que fizemos. No arquivo o PD tem visão da Identificação do componente (verde: existente, rosa: novo, laranja: parcial — só tem no figma, ou só tem no código), link de referência (Link para a doc do componente no figma ou do exemplo no código) e Direcionamentos em post-its (DS: ajustes que o time DS precisa fazer, PD: O que o PD precisa fazer, além de Dúvidas, Sugestões e Elogios — todo mundo adora um biscoitinho 🍪).
- DS Review — follow-up: Aqui é acompanhar de forma assíncrona os ajustes. Tudo pelo Teams e quando necessário, agendando reuniões pontuais até a demanda estar redonda para ir para Dev. Estamos estudando se há necessidade de uma agenda específica para formalizar a entrega, provavelmente, sim.
Hoje o nosso Lead Time está com uma média de 8 dias (não tão bom) com uma meta inicial de cair para 4 dias
Aqui entendemos que é natural esse lead time diminuir conforme a curva de aprendizado dos designers em relação a uso dos componentes aumentar. Com o tempo também a demanda de criação tende a cair o que vai impactar esse lead time. Usamos o Jira para documentar todas as nossas tarefas, então a ideia é acompanhar essas mudanças por lá.
Os tópicos que mais demandam nossa atenção em uma DS Review são:
- Componentes novos: Passamos bastante tempo avaliando a real necessidade de criar um novo componente, o que implica em diálogos constantes com Product Designers e Desenvolvedores. Se identificamos que um novo componente é necessário, integramos essa tarefa em nosso fluxo de trabalho de criação de componentes, seja de forma individual ou colaborativa (vou falar mais disso em outro texto). O processo começa com a revisão de design e culmina com o componente sendo testado, documentado e implementado em produção.
- Revisão de componentes: Em algumas revisões, o foco é adaptar um componente já existente para atender a uma demanda específica. Isso requer que identifiquemos se há outras demandas similares que também poderiam se beneficiar desse componente e avaliemos se o componente é tão datado que necessita ser recriado do zero.
Conclusão
Para o nosso time de Design System, a DS Review vai além de um simples procedimento. É uma chance de aprofundar nosso conhecimento sobre os produtos, exercitar nossa capacidade de argumentação e receber feedbacks em tempo real. É com base nessas revisões que atualizamos nosso backlog de melhorias e crescemos como time e profissionais.
O que tem feito a diferença é a comunicação constante e o compromisso de todos em se adaptar e aprender. Com o tempo, esperamos que a curva de aprendizado dos designers se estabilize, contribuindo para uma entrega ainda mais eficiente e impactante.
Até a próxima :)
