Maick Fonseca Maia

Product Designer | Design Systems | UX/UI

Plasma UI - SMS Design System

Contexto

O cenário que encontramos ao começar a estruturar a equipe de design system foi uma biblioteca de componentes codificados (os componentes mais básicos foram baseados no Ant-design) com temas de tamanho (small, medium e large) e seus equivalentes no Figma. O principal problema relatado pelos usuários era a falta de consistência dos componentes comparados ao que foi prototipado, o que era um problema muito grande para a equipe de design e desenvolvimento.

7meses de trabalho
73componentes revisados
35%de redução dos chamados abertos

Design Audit

Para resolver esse problema inicial, a equipe de design system realizou uma auditoria de design, na qual analisamos componente a componente da biblioteca do PLASMA e também o componente correspondente no Figma. Identificamos +100 inconsistências, que classificamos em 3 categorias:

Inconsistência no componente do Figma: Problemas de visualização, como cores, dimensões, fontes, e também problemas de uso nos componentes da biblioteca do PLASMA.

Inconsistência no componente de código: Componentes com divergencias entre o que está desenvolvido e que foi prototipado no Figma.

Problemas de usabilidade: Problemas mais profundos na usabilidade do componente, como acessibilidade ou mau uso.

Priorização

Com isso, criamos um roadmap para a priorização de correção de acordo com a gravidade e impacto das inconsistências e também classificamos os componentes por volume de uso e importância dentro dos nossos produtos.


Processo de tokenização

Com as correções prontas, a equipe de design system começou a trabalhar no processo de tokenização dos componentes. Primeiro, passando por algumas definições prévias, como:

Níveis de tokens: Definimos 3 níveis iniciais para os tokens, primitivos, que são tokens que só delimitam os valores disponíveis para o uso, sem nenhum contexto. Tokens semânticos, que são tokens que definem o contexto de uso para ser utilizado nos componentes. E os tokens de componentes, que são tokens exclusivos dos componentes e que é o nível que será aplicado nos componentes.

Representação dos níveis de tokens aplicados no background do botão primário.
Representação dos níveis de tokens aplicados no background do botão primário.



Nomenclatura dos tokens: Definimos e, enquanto estávamos aplicando, aprimoramos os padrões para construir a nomenclatura dos tokens, posicionando primeiro o nível em questão, após incluimos o nome do componente, seguido de atributos, tipagem, sub-elemento do componente e estado (todos os tópicos são opcionais e são usados de acordo com a necessidade e contexto do token).

Protótipo
Como foram organizados os nomes dos tokens usados no PLASMA.



Tokenização: Identificação e criação dos tokens de cores, tamanhos e tipografia usando o Tokens Studio.

Protótipo
Interface do plugin Tokens Studio, rodando dentro do Figma, exibindo as paletas primitivas.



Adição do dark mode: Com a estrutura criada, podemos testar e posteriormente adicionar novos temas, incluindo o dark mode, que também era um desejo de alguns usuários do Plasma e que agora era possível graças aos tokens.

Protótipo
Mostrando como podemos alterar o tema de cor usando o tokens studio for figma

Colaboração cross-functional

Nossa equipe tambem trabalhou colaborando de forma bem próxima dos desenvolvedores, garantindo que os componentes estivessem alinhados com as necessidades dos usuários e aproveitando tambem para pedir feedbacks em relação ao handoff dos componentes. Tambem criamos um modelo para a recepção de novos componentes que recebemos dos times de produto, onde analisamos e sugerimos mudanças se necessário para integrar o design system.


Documentação

Em paralelo ao processo de tokenização, a equipe de design system começou a trabalhar no aprimoramento da documentação dos componentes e patterns, decidimos por migrar a documentação para a plataforma open-source docusaurus, onde conseguimos uma boa flexibilidade, alem de já conter a documentaçao de código construída lá.

Protótipo
Documentaçao do componente button, publicada usando a ferramenta Docusaurus

Conclusão

Com o processo de auditoria, tokenização e documentação dos componentes, a equipe de design system conseguiu melhorar a consistência dos componentes e reduziu em cerca de 35% os chamados abertos relacionados a inconsistências de componente. O resultado final foi uma biblioteca de componentes mais confiável, escalável, mais fácil de usar e mais fácil de manter.

Resultados e aprendizados

  • Redução de 35% nos chamados abertos
  • +70 componentes revisados com base em tokens reutilizáveis
  • Time mais alinhado entre design e desenvolvimento
  • Ganho de consistência e velocidade em novos projetos