Até pouco tempo atrás, quem consultava um Design System era sempre uma pessoa, um designer decidindo qual componente usar, um desenvolvedor conferindo o estado de um botão, alguém novo no time tentando entender o padrão antes de propor algo diferente. Hoje, além dessas pessoas, ferramentas de IA também estão gerando telas, componentes e código a partir das bibliotecas de design, e é por isso que as pessoas têm se perguntado como pensar um Design System para IA, mas na verdade, nada é muito diferente do que já deveria estar sendo feito.

Um problema que já existia antes, ficou mais visível

Já falamos aqui no blog sobre como Design System não é só biblioteca de componentes, é a base que sustenta consistência e decisão dentro de um produto, e mesmo assim é comum encontrar empresas com um DS que existe no Figma mas ninguém usa de verdade, ou que foi criado durante um projeto específico e nunca mais evoluiu junto com o produto. Essa lacuna gera um problema onde cada squad resolve à sua maneira: as decisões de interface são tomadas por preferência e não por seguir algum critério, e com isso acaba gerando inconsistência entre módulos do mesmo produto.

Agora, esse mesmo problema aparece multiplicado, porque quando uma ferramenta de IA não encontra uma regra clara para seguir, ela também improvisa, só que em minutos e em escala, e o resultado é o mesmo caos, só que mais rápido e mais difícil de rastrear depois. É por isso que eu acho que falar de governança de design system deixou de ser um assunto só de maturidade de processo e virou uma conversa sobre o que sustenta qualquer produto daqui pra frente.

Importância da documentação: Cases Catarinas Design

Aqui na Catarinas, temos um cuidado de entender o que de fato vai entregar valor para o cliente e de que forma podemos construir o Design System para que facilite a escala do produto.

No case da Arlequim Technologies, empresa especializada em soluções de virtualização de desktops e aplicações em nuvem, nosso objetivo era desenvolver um design system para modernizar a interface da plataforma. Desde o início, adotamos uma abordagem centrada no cliente, realizando diversas rodadas de conversas com diferentes departamentos da empresa para mapear as áreas prioritárias.

A criação do design system começou pela definição das variáveis semânticas de estilo, os design tokens, que abrangeu cores, fontes, border radius, opacidade, sombras, inline & stack spacing e spacing inset. A partir dos design tokens, criamos os componentes, e a lógica de construção foi partir de base components, os componentes menores e indivisíveis, para chegar aos componentes mais complexos. Ao todo, o DS ficou composto por 32 famílias de componentes, com seus respectivos estados (default, hover, disabled, pressed, error e outras variações) em light e dark modes, e cada componente também contou com o descritivo de “o que são” e “pra que servem”, além da representação visual das anatomias.

Já na plataforma PRIMe Unimed, voltada para a gestão de operadoras e prestadores de saúde, era preciso melhorar a experiência, redesenhar os fluxos e atualizar a interface, respeitando os padrões de marca da Unimed e os requisitos técnicos do time de desenvolvimento. Iniciamos a criação do design system em diálogo com o time técnico, que indicou a necessidade de apoio em uma biblioteca de componentes bem estruturada, e a decisão conjunta foi construir o Design System com base na biblioteca Angular Material, o que favorecia a velocidade de implementação. Com os fluxos definidos, mapeamos os componentes básicos e os componentes de negócio, aqueles mais específicos das operações do Prime, e documentamos cada um com suas variações, estados e modificadores.

A criação dos design tokens, cores, fontes, espaçamentos, sombras e demais estilos visuais garantiu a coerência visual e o alinhamento à identidade da Unimed, e conseguimos transformar os componentes da biblioteca base em elementos únicos do Prime, mantendo a familiaridade técnica e a identidade visual proprietária. O projeto resultou na criação e documentação de 27 componentes personalizados, cada um com suas variações, estados e estilos visuais definidos, e o novo design system trouxe consistência visual, redução do tempo de entrega e mais fluidez no trabalho entre design e desenvolvimento.

Em nenhum dos dois casos nós estávamos pensando que a IA iria consumir essa base, o objetivo era reduzir retrabalho, dar consistência entre telas e permitir que qualquer pessoa nova no time entendesse o padrão. Mas agora, todo nosso trabalho fez sentido, pois o que faz a diferença entre quem vai ter que refazer padrões e quem vai aproveitar o que já foi feito é justamente ter uma documentação de qualidade. Quando a regra é clara o suficiente para uma pessoa seguir, ela também acaba sendo clara o suficiente para qualquer ferramenta, e talvez seja esse o jeito mais simples de entender o que muda quando se pensa em Design System para IA.

O que muda, na prática

Pensar em Design System para IA começa por entender que ele deixa de ser só uma referência que alguém consulta quando tem dúvida e passa a ser a base da qual depende a construção de telas, protótipos e novas funcionalidades, seja esse trabalho feito por uma pessoa ou com apoio de IA. Isso não tira espaço do designer, pelo contrário, quanto mais IA entra no processo de um produto, mais importa ter alguém pensando na estrutura por trás, decidindo o que é consistente com a marca, o que faz sentido para o usuário, o que precisa de exceção e o que não pode virar padrão. Esse tipo de decisão a IA não faz sozinha, ela só segue o que já foi definido pelo humano.

Nosso time tem testado como isso funciona no dia a dia, e uma coisa que já notamos é que não basta ter os componentes bonitos e documentados, é preciso que exista uma correspondência técnica correta entre os tokens de design e os componentes reais do código, preservando a lógica da biblioteca que o time de desenvolvimento usa. É basicamente o mesmo princípio que aplicamos no projeto da PRIMe Unimed, só que agora pensando em como isso também vale para a IA lidar com essa base.

O que esperar daqui pra frente

Quando se pensa em Design System para IA, a ideia que se repete é que o design system está deixando de ser um repositório passivo de componentes e virando a base de regras, não só visuais, mas também de uso, quando aplicar cada componente e quando não aplicar. Outro benefício é que dessa forma, qualquer pessoa consegue gerar protótipos pertinentes e testar hipóteses com menos risco de errar na usabilidade. Isso vale pra quem já é designer, mas também abre espaço pra outros papéis do time, como PM ou dev, rodarem experimentos com apoio de ferramentas de IA e ainda assim chegarem perto do padrão esperado, porque a base já carrega a lógica certa. Algumas empresas já falam até em padronizar seus tokens de design para que funcionem em qualquer plataforma ou ferramenta, exatamente para que essa base sirva de referência única, não importa quem está construindo em cima dela, seja alguém do time de design, alguém de outra área ou uma ferramenta de IA. Mas o julgamento sobre o que é certo pra experiência continua sendo humano, a IA só executa dentro do que foi definido.

Quem já tem um Design System bem documentado e revisado vai continuar crescendo com consistência, não importa quantas mãos ou ferramentas estejam produzindo telas ao mesmo tempo. Quem ainda tem aquele DS que foi feito sem pensar na documentação vai precisar rever isso, principalmente se pensa em usar IA no processo, porque o problema que antes aparecia de vez em quando agora se multiplica em escala.

Adotar um design system é uma escolha estratégica que afeta diretamente a forma como produtos são concebidos, escalados e percebidos pelo mercado, e pode aumentar o ROI de UX, reduzir retrabalho, melhorar a experiência do usuário e contribuir para retenção e engajamento.

Se você está nesse momento de decidir como estruturar, ou reestruturar, a base do seu produto pensando em Design System para IA, fale com a gente.