Como um formulário e um rebranding deram origem a um Design System
POSIÇÃO
Product Designer
TIME (FINAL)
1 Product Designer • 1 Product Manager • 1 Tech Lead • 1 Full-stack Developer
Introdução
Eu entrei no EBANX em 2021 com duas missões: migrar de UI Designer para Product Designer e ajudar o time de design a desenvolver um Design System. Quanto design em uma única frase 🙃.
Agora em outubro de 2022, data em que escrevi esse estudo de caso, posso dizer que sim, a V1 do Design System do EBANX saiu do papel! Mas o meu objetivo com esse case é falar justamente os percalços que a gente enfrentou para criar um DS do zero, que envolvem desde a minha pouca experiência (mas muito interesse) em desenvolver um Design System até os plot twists que vivemos na firma durante o processo.
Contexto
O EBANX possuía diferentes produtos, alguns B2B e outros B2C. Isso se refletia na organização dos times também. Quando eu entrei na empresa, haviam 3 times de Product Design, sendo que eu fui para o time de produtos B2B.
Todas essas linhas de produto tinham elementos muito semelhantes (mas não padronizados) entre si, assim como componentes únicos e mais específicos de cada produto. Os times de Product Design sentiam falta de termos uma linguagem visual unificada.
Eventualmente, a estrutura da empresa mudou e o que eram 3 times, virou um só, com 4 PDs. Com isso, a necessidade de ter um design system ficou ainda maior, porque seria uma forma de otimizar o nosso trabalho e também o de desenvolvimento.
Objetivos
-
Ganhar maior escalabilidade;
-
Reduzir esforços com prototipagem e front-end;
-
Melhorar a qualidade das interfaces e a consistência entre os produtos do EBANX.
Processo
Entendendo o problema
Como em todo processo de discovery, eu precisava entender o contexto atual e as dores que os usuários (nesse caso, Product Designers e desenvolvedores) estavam tendo. Por mais que eu estivesse imersa nesse mundo, cada squad tinha suas particularidades, seus desafios, e eu precisava mergulhar mais fundo.
Eu fiz entrevistas com todo o meu time de PD (um grandioso total de 4 pessoas) e tech leads que poderiam compartilhar um pouquinho a situação dos seus times. No final, cheguei a esses 2 grupos de dores:
Dores de design
-
Falta de padrão no uso de cores, ícones, ilustrações, imagens etc. entre os produtos e até mesmo dentro de um mesmo produto;
-
Não saber o que foi desenvolvido de interface e o que é só conceito; também há ajustes que não foram priorizados para desenvolvimento e ficaram esquecidos no Figma;
-
Não ter um processo de handoff bem estruturado. Cada PD faz de um jeito e dependendo do time há pouquíssima comunicação entre PD e engenharia.
Dores de engenharia
-
Muita dependência de legados e times novos fazem com que cada desenvolvimento tenha uma etapa de discovery técnico para conhecer o ambiente;
-
Arquitetura muito complexa — ajustes que deveriam ser simples acabam tomando muito mais tempo;
-
Todos os desenvolvedores são full-stack e a maioria não tem tanta habilidade com front-end. Por isso, eles acabam passando mais tempo desenvolvendo interfaces e tendo que fazer ajustes nelas após as reviews de design;
Também cheguei a conversar informalmente com alguns Product Managers. Do ponto de vista de produto, essas dores causavam atrasos nas entregas e em alguns momentos tiveram iniciativas que se esticaram por muito mais tempo do que o necessário e foram até despriorizadas por conta disso.
Montando um inventário
Depois das entrevistas e de muito ter sido falado sobre padrões visuais, eu achei importante que todos os designers tivessem visibilidade das inconsistências que existiam naquele momento nos produtos B2B e o que poderia ser melhorado.
Por isso, no final de 2021, eu montei um inventário de elementos visuais. Eu coletei cores, escala tipográfica e alguns elementos mais simples como botões e alertas. Além de fazer a comparação entre os produtos, também comparei o que existia no Figma com a realidade dos códigos.
No final desse processo eu pude notar, dentre outras coisas:
-
Vários problemas de acessibilidade nas cores e nos tamanhos de fonte que usávamos. A cor oficial do EBANX por exemplo não batia nenhum critério de contraste.
-
Não existiam padrões de experiência. Diferenças de tons de voz dentro de um mesmo produto, botões quadrados e redondos, labels dentro e fora dos campos de texto… Tudo isso por não termos uma linguagem visual definida.
-
Muitas diferenças entre o que estava no Figma e no código. Mas, pelo que eu coletei nas entrevistas, os desenvolvedores tentavam seguir à risca o que nós desenhávamos. Um insight que eu tirei disso é que ter uma documentação de handoff mais detalhada poderia melhorar essas inconsistências e também a nossa comunicação com engenharia.
Eu apresentei esse mapeamento para os outros times de Product Design do EBANX, e ele acabou sendo usado como referência para que análises desse tipo fossem feitas por eles e que a gente conseguisse ter a mesma visão para todos os produtos.
Dedicando 2022 a desenvolver um Design System
No início do ano, o time de Product Design B2B se reuniu para definir o planejamento para 2022. Já havia um consenso entre a gente de que seria importante termos um plano a longo prazo em vez de 1 por trimestre, já que estávamos com dificuldade de lidar com as nossas iniciativas de time e as iniciativas de produto ao mesmo tempo.
A nossa lead entendeu que colocar como objetivo desenvolver um Design System para B2B seria uma forma de engajar todo o time para tirar esse projeto do papel e também tirar o peso das minhas costas de ter que lidar com essas tarefas sozinha, o que agora eu vejo que seria realmente difícil de dar conta.
Então, sentamos todos juntos e montamos o nosso planejamento. No macro, seria algo assim:
Análise
-
Analisar componentes de produtos;
-
Analisar processos de Design;
-
Apresentar resultados e alinhamento com engenharia e stakeholders;
Definição
-
Definir/Refinar a estrutura do DS;
-
Definir como seria organizada a documentação;
-
Definir estrutura dos design tokens e componentes dos produtos B2B (no lado de design);
-
Alinhamento com engenharia e stakeholders.
Criação
-
Construir os componentes no Figma;
-
Categorização deles em bibliotecas;
-
Testes de usabilidade com Designers e de aplicações em produtos;
-
Handoff para engenharia e design review
Planejamento definido, agora era só começar.
Só que não.
Plot twist: Rebranding do EBANX
Em fevereiro, o nosso time já estava sabendo que haveria uma mudança na marca do EBANX, mas a gente não tinha muitos detalhes nem noção do quão grande ou pequena ela seria. Então combinamos de seguir com os nossos planos enquanto o rebranding não vinha.
Mas aí em março ele veio. E veio com tudo. Foi um rebranding institucional, então a gente tinha acesso a um brand book com paleta de cores, tipografia, exemplos de fotografia, mas ele era muito mais voltado à comunicação interna e externa, especificando a nova estratégia da marca e expressão de voz.
Não havia um estudo de experiência e de aplicação da nova marca nos produtos. E o time de PD entendeu que seria nosso papel fazer essa análise, mas isso envolveria um bom tempo de dedicação a esses estudos, enquanto ao mesmo tempo a gente tinha outras iniciativas de produto para tocar.
Fizemos várias reuniões para definir o nosso plano de ação. Então decidimos que faríamos uma pausa em todas as nossas atividades para fazer uma primeira entrega mais emergencial. A gente fez uma planilha listando todas as páginas, telas, pdfs, emails etc. que tinham o logo do EBANX e, junto com os times de produto e engenharia, montamos uma força tarefa para substituí-lo pela nova marca. Assim, definimos um roadmap e uma data limite para essa mudança e compartilhamos isso com o time de marketing.
Enquanto esses ajustes aconteciam, o nosso time ganhava um pouco mais de tempo para estudar a nova marca e tomar decisões sobre como a gente adequaria os produtos a ela.
Fazendo da laranja um suco de laranja (odeio limão)
Durante o estudo, eu entendi que o rebranding foi maravilhoso para a gente!
Apesar de todo o caos que se instaurou na empresa, ele seria uma ótima forma de iniciar um Design System, já que precisaríamos em algum momento ajustar os produtos a essa nova linguagem visual.
Eu compartilhei esse meu sentimento com o time e todos os PDs embarcaram nessa jornada comigo!
No mesmo período, eu estava participando de um discovery sobre um formulário de reembolso e da decisão de refazê-lo do zero. Eu também vi nisso uma ótima oportunidade de começar um DS criando componentes para o formulário que pudessem ser utilizados também em outras interfaces. Aqui eu devo tudo ao Product Manager, tech lead e desenvolvedor envolvidos nesse projeto, que confiaram em mim e ficaram tão engajados em fazer um Design System quanto eu! 🥹
Se você ainda não viu, eu tenho um estudo de caso sobre a saga do formulário de reembolso.
Como o rebranding e outras mudanças organizacionais estavam deixando todos os designers com muitas demandas, eu resolvi liderar as etapas seguintes, já que eu conseguiria encaixar elas no projeto do formulário, e fui envolvendo os PDs em alinhamentos e iniciativas que não fossem muito trabalhosas para eles.
Design Tokens
Depois dos estudos, a gente saiu com cores e uma escala tipográfica definidas, além de outros elementos como espaçamentos e sombras.
Com isso, eu montei uma nomenclatura de design tokens. Como a gente tem produtos que atendem a diferentes tipos de usuário, o time sempre teve em mente que tokens e componentes deveriam ser flexíveis, para que conseguissem se adaptar a diversos contextos. Por isso, eu usei uma nomenclatura mais genérica, que não tentasse especificar onde ou como o designer deveria usar aquele token.
Documentando guidelines
Mas também não está tudo liberado! Nós precisávamos ter alguns direcionamentos, principalmente quando se trata de acessibilidade. Por exemplo: na hora de definir as cores, a gente levou em conta as que tinham maior contraste, mas ainda existem alguns tons que não funcionam em fundo claro e só podem ser usadas de forma decorativa ou em fundos escuros.
Um designer do meu time foi essencial na parte de documentar essas guidelines. Tudo o que o time definiu junto conversando em reuniões, ele passou para o Notion de uma forma bem organizada e com exemplos. Escolhemos o Notion porque é uma ferramenta que o nosso time e o time de produto já está bem acostumado, e que os times de engenharia já estão começando a utilizar também.
Nessa etapa, nós conseguimos gerar um Style Guide e compartilhamos ele com todas as áreas envolvidas na construção dos produtos.
Desenhando componentes
Como eu encaixei essa etapa no projeto do formulário de reembolso, eu criei componentes que fossem de fato ser usados nele (para não ter nenhum esforço de desenvolvimento a mais do que o previsto), mas que funcionassem muito bem em outros produtos, afinal é para isso que estamos fazendo um Design System!
Nessa etapa foi fundamental o apoio do time de Product Design. Eu fiz uma rodada de design critique para detalhar todos os componentes que eu desenhei, suas estruturas, estados e afins, para pedir feedbacks e assim fazer os ajustes necessários. Os designers também exercitaram aplicar esses componentes em outras interfaces.
Especificando os componentes para handoff
Como eu já estava dando muito trabalho para o time de desenvolvimento, pensei que a melhor forma de me redimir seria fazendo um handoff decente, então eu me dediquei muito nessa etapa.
Antes de montar a documentação, eu apresentei para o desenvolvedor, tech lead e PM o protótipo do formulário com os componentes em uso, e ali alinhamos tudo o que precisaria ser criado, quais componentes fariam parte do DS e quais eram somente para o contexto do formulário.
Também tive que ceder em algumas coisas, como deixar o estado de loading dos botões para uma v2, mas tudo bem, faz parte…
Para montar o documento de especificação, eu tive a “sorte” do desenvolvimento do formulário ter sido posto em espera por algumas semanas, então eu consegui tempo suficiente para caprichar nos detalhes.
O meu objetivo, além de tentar deixar o processo de handoff o mais claro e simples possível para o desenvolvedor, foi também ter um case de sucesso que eu pudesse compartilhar com o meu time de como um handoff feito com dedicação faz diferença na entrega final. E fez muita diferença, eu fiquei impressionada com o trabalho incrível do desenvolvedor (que nunca tinha trabalhado com design systems!) e recebi um feedback muito positivo dele.
Organizando os componentes no Figma e finalizando a V1
Com os componentes prontos para desenvolvimento, eu organizei eles em uma biblioteca no Figma para que os outros designers já pudessem começar a experimentá-los.
Eu tomei um cuidado de não publicar os componentes na biblioteca antes deles estarem prontos e revisados no código, para não correr o risco de alguém usar um componente em outro projeto, passar isso para desenvolvimento, e outro desenvolvedor ter um trabalho desnecessário.
Com isso, entregamos a V1 do design system, bem enxuta, poucos componentes, mas o suficiente para começar a engajar outros designers e outros times a consumi-lo e contribuir com ele.
Próximos Passos
Graças ao apoio e engajamento do time de desenvolvimento para fazer isso acontecer, conseguimos criar uma biblioteca de componentes no Storybook, disponível em código para os devs, além da biblioteca que eu criei no Figma para os PDs.
Como próximos passo está juntar as documentações de design e desenvolvimento, devemos seguir usando o Notion para isso.
Além disso, é importante começar a pensar em aspectos de governança. Já há planos de um outro time de desenvolvimento utilizar os componentes criados em um outro projeto, então precisamos conversar sobre responsabilidades, se teremos “guardiões” do design system, quem pode contribuir com sua construção etc.
Eu espero que, se você chegou até o final, tenha sido porque entendeu o meu propósito de escrever um estudo de caso o mais realista possível, mostrando os altos e baixos que a gente tem que enfrentar no mundo de produtos. Mas, ainda assim foi um projeto muito prazeroso de fazer, e saber que eu não estava sozinha nessa, que eu tinha o meu time de Product Design e meus companheiros de produto e engenharia se empenhando em fazer isso funcionar, foi o que fez toda a diferença.