Design system é uma biblioteca de decisões e não de componentes.

Tenho trabalhado no desenvolvimento de um portal institucional que reúne diferentes tipos de conteúdo em uma mesma estrutura: notícias, artigos de opinião, boletins, webstories, mesacasts, publicações, pesquisas de mercado e outros formatos.

À primeira vista, parece um grande problema de interface. Não é. Ou melhor: a interface é apenas a parte mais visível do problema.

Quando você olha para a quantidade de conteúdos, relações, regras editoriais, formas de publicação e maneiras diferentes de apresentar cada informação, percebe que está diante de um produto, e não apenas de um site.

E essa diferença importa.

Um site pode ser tratado como um conjunto de páginas que precisam ser desenhadas, desenvolvidas e aprovadas. Um produto exige outra coisa: alguém precisa manter a visão do sistema enquanto todas essas partes estão sendo construídas.

É aí que começam as decisões que realmente importam.

Produto

Um produto digital não é uma tela. Ele tem dados, estados, comportamentos, regras, objetivos e diferentes situações que precisam funcionar juntas. A tela é apenas o lugar onde parte dessas decisões fica visível para alguém.

Isso parece uma distinção simples, mas muda bastante a maneira como projetamos um produto. Por exemplo: o que deve aparecer quando uma busca não encontra nenhum resultado? Parece uma questão de interface.

Mas antes de pensar no desenho daquela tela, alguém precisa decidir o que o sistema entende como “nenhum resultado”, se haverá recomendação de conteúdo, se a busca poderá ser refinada, se determinados conteúdos serão priorizados e assim por diante.

A interface vem depois.

O mesmo acontece quando uma notícia não tem imagem de capa, quando um conteúdo pertence a duas categorias diferentes ou quando um determinado tipo de publicação precisa aparecer na home.

São situações que eventualmente precisam de uma representação visual, mas que não começam no visual, começam na regra.

Regras

Todo produto digital é sustentado por regras. Algumas vêm do negócio, outras do conteúdo, do produto, da tecnologia ou da própria interface. O problema é que, muitas vezes, elas não estão claramente definidas e, quando isso acontece, alguém precisa tomar a decisão. Frequentemente, esse alguém é o designer.

É aí que começam alguns dos problemas que depois aparecem como “problemas de design”. Uma regra de negócio mal definida vira uma tela difícil de desenhar. Uma estrutura de conteúdo mal resolvida vira uma arquitetura de informação cheia de exceções. Uma decisão de produto que não foi tomada vira uma interação que precisa ser inventada.

O design acaba compensando uma decisão que deveria ter sido tomada antes, e isso custa caro. Não necessariamente porque o designer vai gastar mais algumas horas no Figma, mas porque uma decisão que não foi tomada no início acaba sendo distribuída por várias partes do projeto.

Um produto digital não é uma tela. Ele tem dados, estados, comportamentos, regras, objetivos e diferentes situações que precisam funcionar juntas. A tela é apenas o lugar onde parte dessas decisões fica visível para alguém.

Decisões

Foi isso que ficou mais evidente para mim trabalhando nesse portal. A pergunta não é simplesmente: “Como vamos desenhar esse card?”. Antes disso, precisamos responder: “O que esse conteúdo é?”

Ele se comporta como uma notícia? Como um artigo de opinião? Como uma publicação? É um novo tipo de conteúdo? A resposta muda o que acontece depois.

Porque, dependendo da decisão, mudam os dados que precisam ser armazenados, a forma como o conteúdo é cadastrado no CMS, as regras para exibição, os componentes disponíveis, os estados da interface e até o que o usuário consegue fazer.

Por isso, uma boa regra produz uma decisão mais precisa. Uma regra ambígua não desaparece, ela apenas passa para outra pessoa.

Componentes

É nesse ponto que começo a enxergar o design system de uma maneira um pouco diferente. Um componente não é apenas um pedaço de interface que podemos reutilizar, ele é uma decisão que foi transformada em objeto.

Quando definimos um card para notícias, estamos materializando uma decisão sobre como aquele tipo de conteúdo deve ser apresentado naquele contexto.

Quando definimos um botão primário, estamos estabelecendo uma hierarquia de ações.

Quando definimos os estados de um formulário, estamos dizendo como o sistema deve responder às diferentes situações pelas quais aquele formulário pode passar.

O design system registra essas decisões para que não precisemos tomá-las novamente a cada tela e talvez seja justamente aí que esteja o seu maior valor. Não é a quantidade de componentes que faz um design system ser eficiente, é a quantidade de decisões que ele evita que o time precise discutir novamente.

E quando alguém pede uma pequena alteração?

Aqui começa uma parte interessante.

“É só um ajuste.”

“É só mudar esse espaçamento.”

“É só fazer uma versão desse card para essa página.”

“É só uma exceção.”

Se eu altero um componente que é utilizado em vários lugares, posso estar alterando uma regra que já foi definida para todos esses lugares. Se eu crio uma nova variação, estou dizendo que existe uma situação que o sistema anterior não conseguia representar. Se essa variação precisa de uma nova condição, já não estamos falando apenas de Figma.

Pode ser necessário alterar o front-end. Talvez o CMS. Talvez o backend. Talvez os dados.

Depois vêm os testes, a documentação e a manutenção.

É por isso que algumas mudanças que parecem pequenas na interface podem representar uma mudança grande no produto. O tamanho da alteração visual não é necessariamente proporcional ao tamanho da alteração sistêmica.

Mas então não podemos criar exceções?

Claro que podemos. E, às vezes, devemos.

No próprio portal, tivemos uma situação desse tipo.

Existia uma regra definida para a home e surgiu uma necessidade específica de apresentação de um conteúdo naquele contexto. Poderíamos alterar o componente global para atender àquela necessidade, mas isso significaria mudar uma regra que não precisava ser mudada em todos os outros lugares onde aquele componente era utilizado.

A outra alternativa era resolver a necessidade na camada de apresentação da home, sem alterar a regra global do componente. Foi essa escolha que fizemos. Não porque customização seja ruim, mas porque nem toda necessidade precisa entrar para o sistema.

Essa, para mim, é uma das questões mais importantes quando falamos de design system e governança de produto: em que camada essa mudança precisa acontecer?

Ela precisa mudar uma regra de negócio? Precisa mudar o modelo de conteúdo? Precisa criar um novo comportamento? Precisa alterar um componente? Ou pode ser resolvida naquele contexto específico? Essa pergunta pode evitar muito trabalho desnecessário.

Governança

É aqui que entra a governança. Não como uma camada burocrática para aprovar cada alteração de layout, mas como uma forma de decidir o que deve fazer parte do sistema e o que não deve. Quando uma nova necessidade surge, a pergunta não deveria ser apenas “conseguimos fazer?”. Deveria ser: “Isso precisa existir para todo o sistema ou apenas para este contexto?”

Se a resposta for “para todo o sistema”, talvez estejamos diante de uma nova regra, de um novo componente ou até de uma mudança na estrutura do produto. Se for “apenas neste contexto”, talvez não faça sentido alterar todo o sistema para acomodá-la.

Parece uma diferença pequena, mas é esse tipo de decisão que determina se um design system vai ficar mais consistente ou mais complexo ao longo do tempo.

Governança, nesse sentido, não é impedir mudanças, é dar um lugar certo para cada mudança.

O custo aparece depois

O problema das exceções é que elas raramente parecem caras no momento em que são criadas.

Hoje é uma pequena alteração. Daqui a seis meses, alguém olha para aquele componente e pergunta: “Por que isso funciona desse jeito?”. Ninguém sabe. Então alguém precisa investigar. Depois descobre que existe uma condição no código. Essa condição depende de um campo no CMS. O campo foi criado para resolver uma demanda específica.

E agora ninguém quer removê-lo porque não sabe o que pode quebrar. É assim que sistemas ficam complexos. Não necessariamente por causa de grandes decisões erradas, mas pela soma de pequenas decisões que nunca foram tratadas como decisões.

E o custo não está apenas no desenvolvimento, mas também na manutenção, na documentação, nos testes, no onboarding de novos profissionais e no tempo que a equipe perde tentando entender por que determinadas coisas existem.

Quando uma nova necessidade surge, a pergunta não deveria ser apenas “conseguimos fazer?”. Deveria ser: “Isso precisa existir para todo o sistema ou apenas para este contexto?”

Menos possibilidades também pode ser design

Existe uma ideia de criatividade muito associada ao design: quanto mais possibilidades conseguimos criar, melhor estamos desenhando. Eu penso diferente quando estou trabalhando com produtos: explorar possibilidades é importante, mas o trabalho não termina aí.

Desenhar é explorar possibilidades. Projetar é decidir quais delas precisam existir.

É uma diferença pequena na frase, mas grande na prática. Cada possibilidade que transformamos em uma regra passa a fazer parte do sistema. E, a partir daí, alguém terá que implementá-la, testá-la, documentá-la, explicá-la e mantê-la.

Por isso, criatividade em produto não é criar o maior número possível de soluções. É conseguir enxergar as possibilidades e entender quais realmente resolvem o problema.

No final, talvez uma das decisões mais importantes de design seja decidir o que não precisa existir. Não porque fazer menos seja sempre melhor, mas porque toda decisão que entra em um produto passa a ter um custo de existência.

Produtos digitais não são telas esperando criatividade. São sistemas esperando decisões. A questão não é quantas possibilidades conseguimos colocar dentro deles, mas quais delas realmente valem a pena sustentar.