O desafio de reestruturar um Design System — o diagnóstico
Apesar de amar séries médicas (só fãs de House online), não é exatamente esse tipo de diagnóstico que estamos falando quando nos referimos a Design System. Mas a lógica aplicada é parecida: primeiro é preciso conferir como o paciente (ou o DS atual! rs) está, verificar suas condições de existência naquele momento, realizar exames e, enfim, chegar a conclusões e possíveis tratamentos.
Mas antes de continuar esse papo específico sobre diagnóstico, vamos recapitular o que rolou até aqui.
Recapitulando
Já contei como foi o planejamento da reestruturação do Design System da Passei Direto nesse post, onde dei um contexto completo do cenário, como foi a organização das informações e quais foram os próximos passos mapeados para continuar essa missão.
Logo em seguida, nesse outro post, contei como foi tooodo o processo de pesquisa e os insights gerados que apontaram a direção para onde seguir.
Passos seguintes
As etapas da reestruturação do DS da Passei Direto não foram cronologicamente lineares, então algumas delas aconteceram durante e após a fase de pesquisa.
Eu poderia dedicar um post para cada um desses passos, mas vou fazer um brevíssimo resumo deles, porque o foco do post de hoje é outro! 😉
- Fluxos — com ajuda da santíssima trindade que me apoia nesse projeto inteiro (meu líder + o Product Manager e o Engineering Manager do meu squad), fiz a proposta dos fluxos de trabalho envolvendo a construção do novo DS: desenvolvimento de novos tokens* e componentes*, solicitação de novos componentes e correções de bugs.
*Tokens são a menor unidade de elementos que fazem parte do Design System, como peças combináveis para formar componentes. Componentes (que são formados pelos tokens) ajudam a montar interfaces com mais agilidade e garantem consistência visual na experiência das pessoas usuárias.
Aqui tem um post rapidinho no LinkedIn falando sobre esses conceitos.
- Ferramentas — foi necessário pesquisar e tomar decisões em relação a ferramentas que usaremos para criar, manter e documentar o DS, além de entender como elas serão integradas. Nossas escolhas por aqui foram: ZeroHeight, Figma e Storybook.
- Naming — em colaboração com os times de Marca e Comunicação, UX e Tecnologia fizemos uma dinâmica para batizar o DS e assim criamos uma identidade verbal para nos referir ao nosso Design System.
Agora sim, o voltemos ao papo de diagnóstico
Foi absolutamente essencial fazer uma etapa de diagnóstico para mapear quais passos serão necessários para a organização e o desenvolvimento da nova versão do DS.
Olhando o presente, podemos decidir a melhor estratégia para o futuro.
O diagnóstico aqui no nosso caso foi uma Auditoria Visual super completa, dividida em 5 partes:
- Mapeamento das telas do produto
- Mapeamento dos tokens existentes
- Mapeamento dos componentes existentes
- Mapeamento das inconsistências de Design existentes
- Mapeamento dos times responsáveis por cada tela/parte do produto
Vem comigo que agora vou falar um pouquinho sobre os pontos positivos e negativos desses mapeamentos todos!
1. Telas do produto
Consistiu em: Printar todas as telas do produto que estavam no ar naquele momento. Sim, T-O-D-A-S.
Nessa fase contei com a ajuda da Thaís Dias, Designer de Produto de outro squad que se voluntariou para me ajudar (uma RAINHA! 👑). Dividimos o trabalho da seguinte forma: eu fiquei responsável por printar tudo que existia na versão desktop e a Thatá ficou responsável por toda a parte mobile/responsiva.
Sim, esse trabalho incluía investigar e achar aquelas páginas que foram feitas há 3.847 anos e ninguém lembra que está no ar. Todas elas. 😵💫
⚠️ Pontos negativos:
- Processo lento e chato de fazer depois de um tempo. No começo é bem legal ir explorando tudo, você acaba descobrindo partes que nunca achou no produto… mas depois de ver tantas telas, fazer tantos prints e tentar organizar tudo, o trabalho fica monótono.
- Demorou 84 anos para terminar. Ok, na verdade foram quase dois meses, mas pareceu que foram todos esses anos mesmo. Ah e até hoje encontramos alguma tela que não tínhamos ideia que existia rs
❇️ Pontos positivos:
- Identificamos de forma rápida e fácil os elementos visuais (tokens e componentes) usados em todo o nosso produto atualmente.
- Usamos um board no Miro para colocar todos os prints, separados por web/mobile, logado/deslogado, acessível para todos os times da PD. Essa organização ajudou em um outro projeto em desenvolvimento e deu visibilidade do tamanho do produto para todo mundo.
2. Tokens existentes
Consistiu em: Analisar todos os tokens presentes nos prints feitos na etapa anterior: cores utilizadas, estilos de tipografia, bordas, sombras, espaçamentos etc.
⚠️ Pontos negativos:
- Processo ainda mais lento e monótono do que o anterior. Cada tipo de token analisado demandava um pouco de estudo sobre o assunto para levantar pontos relevantes, o que contribuiu ainda mais para essa sensação de monotonia durante o trabalho.
- Senti que foi um processo solitário e ficou difícil de encontrar motivação para continuar realizando, porque dessa vez não contei com ajuda de outras pessoas.
❇️ Pontos positivos:
- Foi possível comparar os tokens usados no produto com os que temos atualmente documentados, decidir quais tokens devem ser mantidos e quais devem ser ajustados ou eliminados além de identificar pontos de melhoria (simplificação de uso, acessibilidade e documentação).
- A documentação dessa análise vai ser sempre acessada cada vez que precisarmos fazer um token para a nova versão do DS.
- Com essa análise foi possível fazer uma sugestão de priorização de desenvolvimento, que deve nos ajudar mais para frente.
3. Componentes existentes
Consistiu em: Analisar todos os componentes presentes nos prints feitos na etapa anterior: botões, controles, avatares, alertas, modais, formulários e inputs de texto, headers, footers e muito mais.
⚠️ Pontos negativos:
- Exatamente os mesmos da fase anterior.
❇️ Pontos positivos:
- Exatamente os mesmos da fase anterior.
4. Inconsistências de Design
Consistiu em: Mapear inconsistências que precisam ser ajustadas para garantirmos a melhor experiência para as pessoas usuárias do
Passei Direto.
⚠️ Ponto negativo:
- Vocês já imaginam o que vou dizer — e eu vou dizer mesmo assim. Mais uma vez, o processo foi suuuuper lento, solitário e monótono. Foi a fase que mais demorou, porque além de apontar as inconsistências de cada tela, foi necessário fazer uma análise das inconsistências que mais se repetiam e dividir entre o que poderia ser melhorado com a nova versão do DS e o que era backlog de melhoria para o squad responsável por aquela tela.
❇️ Pontos positivos:
- Ter em único documento todas as inconsistências de design sinalizadas.
- Possibilitou endereçar decisões e solicitações de ajustes em páginas existentes.
- Alta visibilidade sobre o que podemos resolver com novos tokens e componentes a serem criados.
5. Times responsáveis
Consistiu em: Sinalizar quais times eram responsáveis por cada tela (ou partes delas) no documento de inconsistências já pronto.
⚠️ Ponto negativo:
- O documento que centralizava as telas do produto + inconsistências virou um Megazord difícil de acompanhar. Quem abria tinha medo de dar zoom, do tanto de informação que tinha ali.
❇️ Pontos positivos:
- Conversei com Product Designers e Product Managers e eles me ajudaram nessa fase, fazendo quase 100% do trabalho. Melhores pessoas + processo colaborativo = ❤️
- Documento centralizado com visibilidade dos escopos dos times para toda a empresa.
- Conseguimos endereçar com facilidade as inconsistências para as equipes que podem solucioná-las.
Agora, finalmente, acabou! …né?
Bem, essa etapa de diagnóstico sim! 🥳
Foi de longe o que mais consumiu tempo, mas em compensação gerou dados e informações que vão ser preciosos na hora de colocar a mão na massa e começar o Design e Desenvolvimento dos novos tokens, componentes, documentação etc.
Mas… Ainda faltam algumas etapas até essa fase de produção começar. Eu conto quais são elas em uma próxima oportunidade. Até lá!
