Estratégias adotadas para aprimorar o design system para o Mercado Bitcoin

Introdução

Neste artigo abordarei meu processo para criar um design system para o Mercado Bitcoin, a maior plataforma de criptomoedas da América Latina, que atualmente atende a mais de 2 milhões de clientes.

Minha jornada na empresa se estendeu de junho de 2021 a outubro de 2022, sendo os 4 últimos meses dedicados ao aprimoramento do Design System do produto.

Contexto

Comecei trabalhando em uma squad multidisciplinar focada em segurança, na qual eu era responsável pelo design de novas funcionalidades, contemplando plataformas Web, mobile e app (Android & iOS). Atuei de ponta a ponta na criação das soluções, desde o discovery ao delivery, passando por pesquisa, ideação, testes e acompanhamento de desenvolvimento e pós-lançamento.

Para construir as interfaces eu consultava o design system existente na época, chamado Apollo. Esse design system ainda estava em fase embrionária: possuía poucos componentes e não contava com uma equipe dedicada, sendo mantido e atualizado eventualmente pelos próprios product designers, com pouco envolvimento do time de engenharia.

Enfrentei diversas dificuldades usando o Apollo: frequentemente não encontrava componentes que precisava ou não sabia qual era o correto, pois haviam várias versões de um mesmo componente. Havia um excesso de bibliotecas, que eram desorganizadas, com uma documentação rasa e confusa. Sem a existência de regras e guias de uso, cada designer aplicava e personalizava os componentes na interface à sua maneira, gerando um grande débito na consistência do design.

Outros problemas envolviam a falta de acessibilidade nos componentes, como baixo contraste nas cores e baixa legibilidade das fontes tipográficas, além de uma implementação demorada das interfaces, pois não havia quase nenhum componente já desenvolvido que pudesse ser reaproveitado.

Por consequência, a adoção do design system era extremamente baixa, além de ser utilizado de forma incorreta pelos poucos usuários e não ter seu verdadeiro valor e utilidade reconhecidos pela companhia.

Imagem 1: Logo do design system Apollo e alguns dos seus componentes.

A virada

Foi então que um novo projeto na empresa surgiu: o Rebranding. Com a alteração na identidade a partir de novas cores, logos, elementos gráficos e fontes tipográficas, houve a necessidade de uma maior atenção à manutenção do Design System, cuja utilização seria essencial para atualizar a experiência do produto com o novo estilo visual proposto para a marca de forma rápida e consistente.

Imagem 2: evolução do logo do Mercado Bitcoin após o rebranding, da esquerda para a direita.

Como meu interesse em atuar dedicada ao design system já existia, prontamente me ofereci para assumir esse desafio. Após a mudança de posição ser aprovada pela minha liderança, dei início ao trabalho com entusiasmo e otimismo com as possibilidades que tinha pela frente.

O time de design system foi composto inicialmente apenas por mim. Para me ajudar no desafio, foi feita a contratação de mais um product designer dedicado. Além então de 2 product designers, também contamos com a atuação part-time de mais 1 engenheiro web (front-end) e 1 engenheiro app (flutter).

Imagem 3: estrutura do time de design system.

Começando pela pesquisa

Para garantir que as mudanças no sistema fossem orientadas pelas necessidades reais dos usuários, realizamos pesquisas 1:1 em profundidade com todos os integrantes do time de design, que na época era composto por 11 pessoas.

A pesquisa com os usuários foi um passo estratégico crucial para esse início, pois revelou insights valiosos sobre o uso do sistema e nos possibilitou compreender melhor os comportamentos, preferências e dificuldades que o time possuía ao interagir com ele.

Ouvindo o time

A pesquisa inicial foi composta de 5 perguntas.

A primeira pergunta foi elaborada para medir a satisfação do time com o design system e descobrir o índice de satisfação (CSAT). Como resultado, obtivemos uma porcentagem de 19%, revelando uma alta insatisfação.

Imagem 4: resultados da pergunta “Qual o seu nível de satisfação hoje com o DS (caso use)”.

A segunda pergunta teve objetivo de entender o nível de conhecimento do time acerca do tema Design System, numa escala de 1 a 10. A média final foi de 5 pontos, indicando um conhecimento médio.

Imagem 5: resultados da pergunta “Quanto você avalia seu conhecimento sobre o assunto [Design System]?”.

A terceira pergunta visava compreender o nível de conhecimento do time sobre o tema Acessibilidade. A maioria (78,6%) dos designers avaliou seu conhecimento como sendo pouco ou nenhum.

O objetivo da quarta pergunta foi ouvir os pontos negativos e positivos que os usuários identificavam no design system.

A partir do resultado, montamos um top 3 com os pontos mais comentados pelos designers. Entre os pontos negativos estava a organização geral dos arquivos, enquanto entre os positivos estava o engajamento do time.

Imagem 6: resultados da pergunta “Você possui algum tipo de conhecimento sobre acessibilidade?”

Imagem 7: pontos negativos e positivos comentados pelos designers e um top 3 dos pontos negativos e positivos mais comentados.

A última pergunta teve como finalidade descobrir quais expectativas os designers tinham com a estruturação de um time dedicado ao design system.

A partir das respostas, identificamos os seguintes keypoints: organização, cultura, documentação e processos.

Entendendo o uso das ferramentas

Utilizamos os métodos de Desk Research e Matriz CSD para entender como a ferramenta Figma era utilizada. Após conversar com a equipe do Figma e apresentar a realidade do time, identificamos a necessidade de um upgrade para o plano Organization, principalmente por conta de funcionalidades como versionamento de arquivos, organização avançada de equipes e projetos e análise e relatórios a por meio do Figma Analytics, que seriam extremamente úteis para atender às necessidades do sistema.

Após negociação com a diretoria da empresa, a contratação do plano foi aprovada. Era o que precisávamos para começar a “organizar a casa”. Além disso, a revisão do plano do Figma gerou uma redução de custo de 6 mil dólares por ano, mesmo com o upgrade para o plano mais caro.

Imagem 8: expectativas dos designers com a estruturação de um time dedicado para o DS.

Imagem 9: Matriz CSD para entender o uso da ferramenta e slide apresentado à diretoria da empresa para negociação da contratação do plano adequado, destacando a economia anual para a empresa.

Colaboração

Com o Figma Organization contratado e os insights obtidos na pesquisa com os usuários, nossa próxima ação foi montar uma nova proposta de organização, que envolveu a reestruturação de times, projetos, bibliotecas, capas de arquivos e padronização da estrutura das páginas dentro do arquivo.

Para validar a proposta, realizamos sessões de critique junto ao time, que foram essenciais para garantir uma organização do Figma mais funcional e satisfatória.

Imagem 10: design critique no Miro com os usuários para validar a nova proposta de organização de arquivos, começando pela apresentação do problema e objetivos.

Imagem 11: apresentação da nova proposta de organização de arquivos e times no Figma.

Imagem 12: exemplo de slide da cerimônia “Design Sync”.

Aumentando o engajamento do time

Pensando em aumentar o engajamento do time, elaboramos novas cerimônias para os times de UX e Design System, que foram divididas em:

🗓️ DS Planning: executada todas as segundas-feiras com objetivo de planejar o que o time de DS faria durante a semana.

🗓️ DS Daily: executada todas as terças, quartas e quintas-feiras, com o objetivo de acompanhar o progresso das atividades e resolver impedimentos.

🗓️ DS Weekly: executada todas as sextas-feiras, com o objetivo de revisar as atividades feitas na semana e reportar o progresso das mesmas para lideranças.

🗓️ UX Sync: executada todas as quartas-feiras, com objetivo de alinhar o time, apresentando as tarefas feitas e em andamento, atualizações de liderança, research e ops e reconhecimentos para os colegas.

Na intenção de promover a transparência do progresso do novo design system, também adotamos as seguintes iniciativas:

💡 Comunicações no slack sobre atualizações no Design System.

💡 Criação de um espaço na ferramenta Notion para solicitações de demandas pelos designers (como componentes, revisão de interfaces, etc).

💡 Elaboração do roadmap do MVP do novo design system.

💡 Envolvimento dos designers na criação do novo nome para o DS, que foi rebatizado de Emibê.

💡 Definição de um guia de colaboração para os usuários.

Imagem 13: exemplo de comunicações no Figma envolvendo pesquisa de naming para o DS, atualizações no produto e demonstração do espaço para solicitação de demandas.

Imagem 14: Roadmap do Design System para o ano de 2022.

Imagem 15: MVP do guia de colaboração ao design system, detalhando o passo a passo para construção de novos componentes considerando três diferentes cenários.

Mão na massa!

Para garantir que todos os aspectos do design e desenvolvimento do produto fossem gerenciados de forma eficiente, consistente e escalável, começamos a definir e organizar nossas fontes da verdade.

Começamos fazendo um mapeamento de todas as interfaces do produto contemplando todas as suas plataformas (web, mobile e app android & iOS) para criar um inventário de componentes. Isso nos permitiu identificar inconsistências e divergências de experiências entre plataformas e enxergar oportunidades de melhoria e aplicações do design system.

Imagem 16: Mapeamento de todas as interfaces do produto com objetivo de criar um inventário de componentes.

Na sequência iniciamos a criação dos design tokens, que foram essenciais para gerenciar o estilo visual da marca, otimizar a personalização de componentes e garantir alinhamento com o time de desenvolvimento, que usavam esses mesmos tokens no código.Além disso, a possibilidade de escalabilidade e tematização atendia a duas principais necessidades de negócio: interfaces em modo escuro e lançamento e aquisição de novos produtos e marcas.

Criamos tokens de cor (light & dark mode), tipografia, espaçamento, sombras, arredondamento e espessura de borda, opacidade e z-index, devidamente documentados em um arquivo específico.

Imagem 17: estrutura de páginas do arquivo de design tokens e exemplo da organização da definição dos tokens de cor.

Em paralelo, elaboramos um processo conciso para a criação de novos componentes, composto por etapas de pesquisa, análise, ideação e entrega, além de uma estratégia de acompanhamento para o Emibê, pautada em medir a satisfação dos usuários bimestralmente, realizar pesquisas contínuas e qualificar de embaixadores para fortalecer a cultura de DS.

Imagem 18: processo de criação de componentes.

Por fim, refinamos os componentes e estruturamos arquivos principais no Figma para centralizar os fluxos do produto considerando todas as plataformas, além de uma biblioteca única para ícones.

Imagem 19: antes e depois do refinamento do componente botão, com novas variantes e temas e organização de arquivo para centralizar todas as interfaces do App.

Impactos

Após 4 meses trabalhando para aprimorar o design system, os principais impactos identificados foram:

✅ Economia de aproximadamente R$31.000,00 por ano com a revisão das ferramentas e contratação do Figma Organization.

✅ Maior alinhamento do time com as novas cerimônias.

✅ Redução no número de bibliotecas de componentes de 41 para 2.

✅ Maior liberdade aos designers para focarem em outras etapas do processo de design, como discovery e pesquisa.

✅ Melhora na organização dos arquivos.

✅ Aumento da colaboração entre os membros do time.

✅ Maior eficiência e velocidade no trabalho dos designers, que podem construir suas interfaces com componentes prontos e reutilizáveis e encontrar o que precisam de forma fácil e rápida.

✅ Consistência da experiência do produto em todas as plataformas de distribuição.

O fim da jornada

Em outubro de 2022 me desliguei do Mercado Bitcoin para abraçar um novo desafio.

O principal aprendizado que levo (além de uma compreensão ampliada sobre blockchain e criptomoedas) é que um design system é, acima de tudo, sobre pessoas. Uma das coisas mais legais sobre trabalhar com esse tipo de produto é poder estar perto dos meus usuários e mantê-los envolvidos e integrados em cada etapa do processo, adaptando o sistema continuamente para atender às suas expectativas e necessidades.

Me despedi da empresa grata e satisfeita com o trabalho que consegui realizar em um período tão curto de tempo (e 100% remotamente!). Deixei a estrutura do Emibê pronta para novas atualizações, e, o mais importante, um time satisfeito e engajado, que passou a reconhecer o valor e os benefícios do design system no seu trabalho. Além disso, fiz amizades que levarei pra vida toda, em especial o Sergio Lima, que foi não só minha dupla, mas também um mentor incrível!