O que é Design System (e por que um UI Kit não é a mesma coisa)
Se você trabalha com design digital, provavelmente já ouviu o termo Design System. Muita gente confunde com UI Kit, com Style Guide ou até com um arquivo de Figma bem organizado. Mas Design System é muito mais do que isso. Entender o que ele realmente é, como funciona e quais modelos de time existem para mantê-lo pode mudar a forma como você enxerga o seu trabalho como designer.
Apparicio Junior
Head of Product Design
Design System não é UI Kit
Essa é a confusão mais comum. Você cria suas cores, tipografia, grid e espaçamentos. Isso é um Style Guide. Depois, adiciona botões, cards, checkboxes e outros componentes. Isso é uma biblioteca de componentes. Juntando os dois, você tem um UI Kit.
Muita gente para aí e chama isso de Design System. Mas o Design System vai muito além. Ele inclui documentação, padrões de comportamento, arquitetura de informação, taxonomia, princípios de conteúdo, acessibilidade, motion, hierarquia, performance e o código em si. Design System é quando design e tecnologia falam a mesma linguagem.
Um UI Kit faz parte de um Design System, mas sozinho ele não é um. Da mesma forma que um motor faz parte de um carro, mas um motor sozinho não é um carro.
Design System é um produto
Essa mudança de mentalidade é fundamental. O Design System precisa ser tratado como um produto. Isso significa que ele tem backlog, tem processo de melhoria, tem bugs, tem versionamento e, idealmente, tem um time dedicado ou pelo menos pessoas responsáveis.
Se ninguém cuida do Design System, ele morre. Vira aquele arquivo de Figma que todo mundo sabe que existe, mas ninguém confia o suficiente para usar. Componentes desatualizados, tokens inconsistentes, documentação que não reflete o código. Quando o Design System não é tratado como produto, ele vira mais um problema em vez de uma solução.
Ele existe para servir outros produtos. É um produto para designers e para desenvolvedores. E muitas vezes, ele é mais importante para os desenvolvedores do que para os designers, mesmo se chamando Design System.
Os níveis de maturidade
Nem todo Design System está no mesmo estágio. Existem níveis de maturidade que ajudam a entender onde a empresa está e para onde pode evoluir.
No nível mais básico, o Design System se relaciona apenas com interfaces. É como a empresa projeta e constrói suas telas. No próximo nível, ele passa a ser relacionado ao produto, influenciando como a empresa projeta seus produtos digitais. Depois, ele se torna um serviço interno, onde outros times da empresa consomem o Design System como se fosse um produto que atende às necessidades deles.
Em empresas maiores, o Design System pode chegar ao nível de marca, suportando múltiplas marcas com tokens customizáveis para diferentes cenários. E no nível mais alto de maturidade, o Design System se torna uma prática da empresa. Todo mundo sabe usar, todo mundo colabora, ninguém questiona por que ele existe. É parte da cultura.
Modelos de time: solo, centralizado, híbrido e federado
A forma como o time é estruturado para manter o Design System muda tudo. No modelo solo, uma pessoa assume a responsabilidade. Funciona no início, mas não escala. Quando a empresa cresce, essa pessoa vira gargalo e acaba num cenário de demanda impossível.
No modelo centralizado, existe um time dedicado exclusivamente ao Design System. É bom porque o time conhece profundamente o sistema, cria processos e mantém consistência. O ponto negativo é que esse time não vive o dia a dia dos outros produtos. Ele recebe pedidos pontuais, mas não tem o contexto completo de cada time.
O modelo híbrido resolve parte desse problema. Você mantém um time central, mas coloca representantes dentro dos times de produto, como embaixadores. Essas pessoas trazem o contexto do produto para dentro do Design System e levam as práticas do Design System para dentro do time.
E o modelo federado funciona com pessoas selecionadas, temporárias ou fixas, que assumem a responsabilidade pelo Design System dentro do seu contexto. Cada modelo tem vantagens e desvantagens. O importante é entender que manter um Design System exige estrutura, não só boa vontade.
Princípios guiam as decisões
Todo Design System precisa de princípios. São eles que definem por que o sistema existe e qual é o seu propósito. Eles guiam as escolhas do time e explicam o conceito por trás de cada decisão.
O Carbon Design System, da IBM, tem como princípio ser aberto. As bibliotecas são mantidas pela comunidade. O Design System do Airbnb tem como princípios ser unificado, universal e icônico, refletindo a ideia de que a interface deveria se comunicar sozinha, sem precisar de explicações excessivas.
Para definir os princípios do seu Design System, responda algumas perguntas: qual modelo de time vai ser usado? O sistema será open source ou interno? Quais são as maiores dores que ele precisa resolver? Quais são as dores dos designers, dos desenvolvedores, dos PMs e dos QAs? As respostas vão formar a base dos princípios que guiam todas as decisões futuras.
Na Design Circuit, você aprende Design System do conceito à prática, com instrutores que trabalham em Design Systems de grandes empresas. Quer entender como construir e manter um sistema de verdade? Conheça nossos cursos em designcircuit.co.
