Construir um design system raramente é um processo linear. Nesta série eu compartilho os bastidores da criação do design system da Doji — incluindo erros, decisões técnicas e aprendizados ao longo do caminho.

Parte 1

Conversas, alinhamentos, discussões e definições

Começando do começo: o que aprendemos com nossas tentativas anteriores

Olhando de fora, criar um design system pode parecer uma tarefa simples. Basta documentar algumas regras, definir alguns componentes, organizar uma biblioteca rápida no Figma e o time já está pronto para construir o mundo!

Pelo menos essa é a teoria. Na prática, a história costuma ser bem diferente.

Na Doji, essa não é nem de longe a primeira vez que tentamos criar um design system. Já houve 3 outras tentativas espalhadas pelos últimos 4 anos. Diversos membros de diferentes times já trabalharam nesse projeto. Nós documentamos regras, definimos componentes e até criamos uma biblioteca no Figma, mas nada disso foi suficiente para implementarmos o sistema de fato.

Por isso, antes de começar essa nova iniciativa, decidimos fazer algo que raramente acontece nesses projetos, e que não havíamos feito em outras iterações do design system: olhar para trás e entender por que as tentativas anteriores falharam. E esse acabou sendo o passo mais importante do processo.

Pontapé inicial

Nossa primeira reunião foi dedicada a analisar o passado. Nosso time é pequeno, e nem todo mundo estava aqui quando as outras tentativas rolaram. O time responsável pelo projeto atualmente conta com quatro pessoas. Do lado de Design, temos a Gabi e o Vitor (eu), e do lado de Dev, a Ingrid (Ina) e o Jonas.

A Ina, nossa Tech Lead, abriu a conversa com uma apresentação sobre como um design system poderia ser estruturado e como isso ajudaria o time a:

  • Desenvolver mais rápido;
  • Reduzir inconsistências;
  • Compartilhar decisões entre design e código.

Isso ajudou a mudar o foco da conversa. Em vez de discutir ferramentas ou componentes imediatamente, começamos com perguntas mais fundamentais como: Como dividir as responsabilidades entre os times de Design e Dev?

Assim, focamos em responder as perguntas que realmente importam na hora de começar a desenvolver um design system, evitamos os mesmos erros que nos fizeram falhar antes.

O que deu errado antes?

Quando analisamos as tentativas anteriores, um padrão ficou evidente. O problema não estava nas ferramentas. Nem na qualidade do design. O problema era estrutural. As tentativas anteriores falharam principalmente por três motivos:

  1. Falta de responsabilidade clara
    Não existia um dono do sistema, que pudesse criar um planejamento e guiar o desenvolvimento do design system. Sem alguém organizando os esforços, o projeto acabou ficando sem direção.
  2. Falta de engajamento entre Design e Development
    Houve pouca interação entre Design e Dev, fazendo com que as necessidades de cada lado ficassem incertas, e não fosse colocadas regras e diretrizes adequadas para o desenvolvimento. No final, o sistema acabou sendo desenvolvido apenas no Figma, dentro do time de Design. Isso criou uma distância entre o design system e o código do produto.
  3. Um sistema grande demais
    Na falta de um direcionamento claro, na tentativa de prever todos os cenários possíveis, o design system acabou ficando inchado e complexo. No final, ele não atendia às necessidades do time e acabou não sendo implementado no código, virando apenas uma ferramenta para o time de design criar layouts adequados à identidade visual.

Definindo novas bases

A partir das conclusões que chegamos após esse período inicial de dicussões, definimos alguns princípios para essa nova tentativa. Entendemos como um time que, para que o design system tivesse chance de funcionar, precisaríamos de:

  • Engajamento entre Design e Development;
  • Definição clara de ferramentas;
  • Responsáveis bem definidos;
  • Um workflow claro de evolução do sistema.

Uma das decisões mais importantes foi definir que os Devs seriam os donos do design system. Isso significa que o registro oficial do sistema fica no Storybook, e não no Figma.

Essa decisão muda bastante a dinâmica do projeto. O sistema deixa de existir apenas como uma biblioteca visual e passa a viver no mesmo lugar onde o produto é desenvolvido: no código.

Outra decisão importante foi evitar a tentação de construir o sistema perfeito logo no início. Em vez disso, decidimos trabalhar com pequenos passos.

Nada de redesenhar o produto inteiro. Nada de criar centenas de componentes novos. A ideia é evoluir o sistema aos poucos, permitindo que o time se familiarize com as ferramentas, o novo workflow e, principalmente, as responsabilidades de cada papel.

E o sistema que a gente já usava no Figma?

Nosso produto já vem sendo desenvolvido há um bom tempo, e já está implementado e operacional em muitas lojas. Além disso, também temos uma identidade visual consolidada, que se estende além do produto digital, em outros materiais e pontos de contato com o usuário. 

Para construir isso tudo até agora, o time de design desenvolveu ao longo do tempo um design system relativamente robusto exclusivamente dentro do Figma, que auxilia os designers a criarem os layouts.

Apesar de já ter componentes e definições estabelecidas ser uma vantagem, também apresenta problemas. Esses componentes que já existiam no Figma não faziam parte de um sistema organizado. Na prática, isso significava layouts e componentes com:

  • Espaçamentos inconsistentes;
  • Diferentes variações do mesmo componente;
  • Padding e alinhamentos sem padrão;
  • Uso pouco controlado de cores e tipografia.

Ou seja, tínhamos componentes, layouts e até um produto pronto, mas não tínhamos um design system.

O papel do Design nesse processo

Com a parte técnica começando a tomar forma, o trabalho do time de Design mudou um pouco de natureza. Em vez de apenas criar componentes novos, nosso foco agora é organizar o sistema que já existe.

Grande parte do trabalho envolve revisar e estruturar o material que já tínhamos. Isso inclui:

  • Organizar tokens existentes;
  • Criar variáveis novas quando necessário;
  • Reduzir variações desnecessárias;
  • Definir padrões de espaçamento;
  • Definir padrões de borda e arredondamento.

O time de Design também fica responsável por definir e registrar as variáveis no Figma, já que decisões visuais como cores, tipografia e espaçamento fazem parte do domínio do Design.

Essas variáveis depois podem ser consumidas pelo sistema técnico. Esse modelo tem funcionado bem: Design define as decisões visuais. Development garante que elas sejam implementadas e distribuídas no sistema.

O trabalho invisível de um Design System

Uma coisa que fica clara rapidamente nesse processo é que a maior parte do trabalho não está em criar coisas novas. Está em reduzir variações desnecessárias. Isso significa tomar decisões como:

  • Quantos espaçamentos diferentes o sistema realmente precisa?
  • Quais arredondamentos são permitidos no sistema?
  • Quando um novo componente realmente faz sentido e deve ser introduzido?

Essas decisões podem parecer pequenas, mas são elas que criam consistência ao longo de todo o produto. Um design system não depende apenas de bons componentes, ele depende principalmente de boas restrições.

Onde estamos agora

No momento estamos em uma fase que chamamos internamente de saneamento do sistema. Alguns componentes já foram importados para o Storybook através do fluxo entre Figma, IA e MCP.

Agora estamos revisando esse material para garantir que o sistema fique mais simples, mais consistente e mais fácil de usar. A ideia é transformar um conjunto de componentes existentes em um sistema real de design e desenvolvimento.

No próximo artigo

Uma das partes mais interessantes desse processo está começando agora!

Estamos trabalhando com Figma Variables conectadas ao código através de MCP, permitindo que tokens de design — como cores, tipografia e espaçamentos — sejam compartilhados entre Design e Development.

Essa integração está mudando bastante a forma como pensamos a relação entre design e código. No próximo artigo quero explorar melhor:

  • Como organizamos nossas variáveis no Figma;
  • Como elas são interpretadas pelo MCP;
  • Como chegam até o Storybook e os componentes em React.

É isso!

Espero que tenha gostado do conteúdo até agora. Te vejo na parte 2!