Conheça o Tangram, o Design System da RD Station
Quando um produto digital cresce, ganhando mais funcionalidades e gerando experiências cada vez mais complexas, surge o desafio de mantê-lo consistente sem perder o ritmo de crescimento.
Com nosso produto, o RD Station, não foi diferente. E foi principalmente após a adição do CRM à plataforma que nos deparamos com o desafio de torná-los produtos com uma experiência única, consistente do ponto de vista visual e funcional. Além disso, a empresa iniciou um processo de redesign de marca, que afetaria também os produtos, sendo a oportunidade que queríamos para redesenhá-los utilizando um design system para garantir consistência e escala.
Foi nesse momento que optamos por reaproveitar um projeto que andava um pouco esquecido por aqui: o Tangram.
Tangram é como chamamos o nosso design system. Atualmente, ele é um projeto criado e mantido pelo time de Design Ops. Além do Tangram, este time atua em outros projetos, ferramentas e processos que atendem todos os designers do chapter de design de produto.
A versão atual do Tangram foi construída com base na biblioteca de componentes da versão anterior, com alguns novos componentes que surgiram com o tempo e que nunca haviam sido documentados. Temos, hoje, aproximadamente 50 componentes. E contando…
O mapeamento inicial de componentes foi bem mão na massa, sem muito mistério: colocamos todas as telas e suas interações em um Miro, onde separamos as referências por feature e por componente.
A partir deste mapeamento, criamos uma lista com todos os componentes que o novo Tangram deveria ter, para que então todas estas telas pudessem ser reconstruídas utilizando o design system. Neste levantamento, descrevemos como cada componente deveria ser, considerando a versão que estava nas telas e as necessidades dos times, de forma que as inconsistências fossem resolvidas.
Nesta etapa de desenvolvimento do Tangram, queríamos testar alguns componentes bastante utilizados, como o componente “Lista”, por exemplo. Ele era um dos mais utilizados no produto, porém nunca foi um componente robusto o suficiente para atender todos os times.
Criamos, então, uma série de dinâmicas que chamamos de “Semana do Redesign”, em que juntamos designers e pessoas interessadas em um determinado componente e exploramos o problema, as inconsistências e necessidades, para conseguirmos gerar propostas mais globais.
Essas dinâmicas começavam com uma definição sobre o problema que o componente deveria resolver e as necessidades dos times dentro de cada aplicação. A partir disso, exploramos formas de construir o componente de maneira que ele suportasse o máximo de casos de uso. Com isso, conseguimos chegar ao final da semana com componentes mais consistentes e robustos.
O próximo passo era documentar o componente no Tangram, algo que a versão antiga deixou a desejar — e que era nossa principal aposta para criar consistência e escalabilidade no design. Todos os componentes têm uma documentação que explica sua função e traz diretrizes de aplicação, envolvendo questões visuais, comportamentais, de conteúdo e localização e também aplicações que precisamos evitar.
Temos, também, uma cerimônia que acontece uma vez por semana, onde tiramos dúvidas sobre o uso de componentes ou diretrizes de design, mas não é um momento focado apenas para isso. Quando um componente é utilizado de uma forma diferente do que está na documentação, conversamos e tentamos entender se o componente precisa ser atualizado, se ele foi bem aplicado no contexto ou, ainda, se há a possibilidade de utilizar outro componente.
A nova documentação do Tangram passou por diversos formatos e plataformas. Começamos documentando tudo diretamente na biblioteca de componentes no Figma. Cada página continha o componente com suas variações e também uma página com regras de uso, contendo a descrição do componente, anatomia de seus elementos, tokens, estados em que ele poderia aparecer, casos de uso permitidos e não permitidos, diretrizes de acessibilidade e manuais de escrita. Manter tudo no Figma nos deu muita agilidade no início e facilitou a comunicação com o time de design.
Do lado de tecnologia, utilizamos o Storybook, para que os desenvolvedores pudessem acessar a documentação e o live view dos componentes sem precisar abrir o Figma.
Porém, à medida que os componentes foram sofrendo alterações e revisões de estilo, tanto no design quanto no código, começamos a ter certa dificuldade para manter uma documentação sincronizada e foi neste ponto que o Figma deixou de nos atender.
Hoje, toda a nossa documentação de design e de código está centralizada em uma ferramenta chamada Docussaurus e pode ser acessada em https://tangram.rdstation.com.br. Mantivemos no Figma apenas os componentes e suas variações.
Com a documentação pronta, cada time ficou livre para decidir o momento certo para implementar suas telas já com componentes do Tangram. Como falamos, o redesign foi o veículo dessas mudanças no produto e a documentação do Tangram nos ajudou a manter a consistência.
É claro que componentes estão sempre evoluindo, enquanto novos estão sendo criados. Para isso, criamos um formulário no Typeform, em que as pessoas podem solicitar novos componentes, ícones, ilustrações ou sugerir melhorias no Tangram. Esse formulário cria um card em nosso Trello e a priorização e o andamento da tarefa é feito conversando com a pessoa via Slack ou chamada de vídeo.
Falando em evolução, acompanhamos alguns indicadores para entender se o projeto está atendendo nossos clientes de maneira satisfatória.
Inicialmente, realizamos algumas pesquisas informais e recorrentes dentro do time de design para entender qual era sua expectativa com o design system e para obter feedbacks sobre o uso do mesmo. Através desse formulário, com perguntas descritivas, conseguimos entender melhor como estava a saúde do projeto e como poderíamos melhorar.
Utilizamos também algumas métricas de adoção, medindo a quantidade de fluxos já implementados com o redesign, já que, no nosso contexto, o redesign é feito utilizando componentes do Tangram.
Outra métrica que utilizamos é a quantidade de issues abertas no Github do Tangram. Essas issues envolvem bugs e sugestões de melhoria, e nos ajudam a refinar cada vez mais nossos componentes.
E você, usa algum Design System? Conta aqui nos comentários o que achou deste post ou mande perguntas que a gente vai te responder! ;)
