O desafio de reestruturar um Design System — o planejamento
Quando me tornei Designer de Produto na Passei Direto, um dos assuntos que estava no meu radar para estudar era Design System. Pensar design de forma escalável sempre foi do meu interesse (desde a faculdade de Publicidade eu era fascinada por estudar Brand Guides, por exemplo), então assim que tive oportunidade, fiz o curso Design System Specialist, da Meiuca.
Fazer esse curso não era do meu interesse apenas por querer me desenvolver e aprender novas coisas, mas também contribuiria para o meu próximo desafio na Passei Direto: reestruturar o DS da PD era uma necessidade latente para os times de Produto e Tecnologia.
Precisei de alguns meses para consumir todo o conteúdo do curso — cada videoaula me trazia perguntas que me faziam passar horas pesquisando mais e mais sobre o assunto — mas consegui concluir bem a tempo de iniciar o desafio de reestruturação do Design System.
Por onde começar?
Essa foi a minha primeira pergunta quando encontrei com meu líder para discutir como seria o planejamento de reestruturação do DS. Mas antes, vamos para o contexto: após 6 anos do produto rodando e sendo aprimorado, surgiu a necessidade de pensar na primeira versão de Design System da Passei Direto. Na ocasião, todo o produto foi mapeado, tokens e componentes foram desenvolvidos e uma documentação foi criada.
Mas durante os 3 anos seguintes, esses elementos acabaram evoluindo de forma desigual entre Design e Tecnologia, as informações não foram repassadas entre os times ao longo do tempo e muitas pessoas (principalmente as recém-chegadas) não sabiam que esses elementos existiam.
O cenário então consistia na existência de vários elementos de Design System parcialmente organizados, principalmente para Designers de Produto. Porém, esses elementos precisavam de atualização com a evolução do nosso produto e também de espelhamento em desenvolvimento.
Sério: por onde começar?
Agora sim voltamos a fatídica pergunta: levando em consideração todo esse histórico e contexto, por onde podemos começar a reestruturar um Design System inteiro?
Usamos a metodologia do Duplo Diamante para nossas soluções no time de UX da PD, então nada mais justo que usar para repensar o nosso DS:
Sendo assim, o primeiro passo precisava ser o processo de Descoberta (inclusive já compartilhei aqui como foi minha primeira experiência mergulhando no problema a ser resolvido).
Para planejar, é preciso descobrir
E antes de descobrir, é preciso organizar: a primeiríssima coisa que fiz foi abrir uma documentação para centralizar todas as informações sobre o assunto. Essa documentação mais tarde se tornaria o que eu carinhosamente chamo de “Bíblia do DS”, porque nela estão contidos todos os detalhes (informações, links, insights, cronogramas etc) referentes ao planejamento da nova versão do DS da Passei Direto.
As primeiras informações que entraram nessa documentação foram dados de pesquisas que encontrei ao buscar os benefícios de se ter um DS estruturado. Estudos do Figma e do Atlassian foram fontes dos números que comprovavam esses benefícios: além de melhorar produtividade e agilidade, o Design System colabora para uma melhor comunicação entre Design e Tech, gera mais consistência, maior acessibilidade e permite revisão do tempo que investimos em cada tarefa (foco na experiência e não no desenho de telas).
Depois de coletar esses dados, foi o momento de olhar para dentro e investigar tudo o que já havia sido feito em relação a Design System dentro da Passei Direto. Além da documentação do Zero Height, tínhamos:
- um arquivo no Figma com tokens e componentes para uso de Designers de Produto
- dois repositórios privados diferentes no Github (um para desktop e um para mobile)
- um material de estudo sobre o assunto levantado pelo squad há alguns meses
- um manual de comunicação desenvolvido pelo time de Content Design.
A primeira vez que todos esses materiais ficaram centralizados, ou seja, acessíveis de um mesmo local, foi nessa documentação de planejamento do DS.
O passo seguinte foi entender como estava o conhecimento dos times em relação aos conceitos de Design System — o que é DS, o que são tokens, o que são componentes — e quais expectativas em relação a nova versão. Para isso, rodei uma dinâmica com o meu squad (que seria responsável pela nova versão do DS) e com o chapter de UX (formado por designers, researchers, writers e leads).
Ao final dessas dinâmicas, foi possível reunir alguns consensos sobre esses conceitos e identificar quais eram os pontos mais críticos que precisariam ser alinhados. Registrei na documentação os links para os boards feitos no Miro e fiz um resumo dos principais pontos levantados nessa iniciativa.
Para finalizar essa primeira parte do planejamento, me reuni com meu líder junto com o Product Manager (PM) e o Engineering Manager (EM) do meu squad para pensarmos juntos quais seriam as próximas etapas necessárias para avançar com o projeto, rascunhando um roadmap.
As etapas mapeadas nessa ocasião foram:
- pesquisa interna para identificar uso do DS atual e possíveis melhorias
- criação de fluxos de trabalho (como vai ser o desenvolvimento de novos componentes, por exemplo)
- escolha de ferramentas para uso e documentação da nova versão do DS
- naming
- auditoria visual
- inventários de tokens e componentes
- proposta de MVP
A definição dessas etapas foi fundamental para prever um cronograma e deixar sempre bastante alinhado com os stakeholders qual a etapa atual e quais as seguintes desse projeto tão desafiador.
Todo o processo mostrado nesse artigo foi fruto de muita colaboração e quase um mês de trabalho entre as etapas de organização, coleta de dados, realização das dinâmicas, análise de resultados e definição de roadmap.
E, apesar de ter sido um ótimo direcionador, já posso adiantar: alguns pontos desse roadmap mudaram, outros se desdobraram em outras etapas… mas isso é assunto para um próximo artigo. Até lá! :)
