Blog/Artigos · Engenharia
Os design tokens, o Atomic Design de Brad Frost, a biblioteca como fonte única da verdade e a governança que mantém o padrão vivo.
A Torá insiste, mais de uma vez, numa mesma regra: uma só lei e uma só ordenança haverá, para o natural e para o estrangeiro igualmente. A ideia é que o padrão vale para todos, sem exceção por origem, e é essa uniformidade que dá coerência ao todo. Interface de software sofre exatamente do problema oposto quando não há esse padrão. Cada time cria o seu botão, escolhe o seu tom de azul, inventa o seu jeito de mostrar um erro, e o produto vira uma babel visual onde nada conversa e o usuário sente a costura em cada tela. Design system é a torah achat da interface: uma só lei visual e de comportamento, um conjunto de componentes e regras que vale para toda a aplicação, para que o produto inteiro fale a mesma língua, independentemente de qual time construiu cada parte.
O sintoma que revela a falta de um design system é banal e caro: numa mesma aplicação, existem cinco botões primários ligeiramente diferentes, três tons de azul que deveriam ser um, dois jeitos de mostrar um campo com erro. Cada um foi criado por um time ou num momento diferente, reinventando o que já existia porque não havia uma fonte comum. O custo é triplo: inconsistência que o usuário percebe como falta de cuidado, retrabalho de construir de novo o que já foi construído, e a impossibilidade de mudar o visual do produto sem caçar dezenas de implementações espalhadas.
Design system resolve isso sendo a fonte única da verdade para a interface. Em vez de cada tela desenhar seu botão, todas consomem o mesmo componente de botão, da mesma biblioteca. Mudar o botão vira mudar num lugar só, e o produto inteiro acompanha. Consistência deixa de depender da disciplina de cada desenvolvedor lembrar do padrão, e passa a ser garantida por construção, porque o jeito fácil de fazer, usar o componente pronto, é também o jeito certo. É a mesma lógica da plataforma e do golden path: o padrão não se impõe por fiscalização, se sustenta por ser o caminho mais cômodo. Uma só lei para toda a interface, seguida não por obrigação, mas porque seguir é mais fácil que reinventar.
A fundação do design system são os design tokens: as decisões visuais mais básicas, cor, espaçamento, tipografia, raio de borda, capturadas como valores nomeados, não como números soltos espalhados pelo código. Em vez de azul cravado em cem lugares, existe um token cor-primária, referenciado por todos, e mudar a marca inteira vira mudar o token. Os tokens são o alfabeto do sistema, a camada onde a torah achat começa: as regras mais elementares das quais tudo o mais deriva.
Sobre os tokens, o Atomic Design de Brad Frost dá a gramática de composição, numa metáfora química. Átomos são os elementos indivisíveis, um botão, um campo, um rótulo. Moléculas combinam átomos num grupo funcional, um campo de busca é rótulo mais campo mais botão. Organismos combinam moléculas em seções complexas, um cabeçalho, um formulário inteiro. Templates arranjam organismos numa estrutura de página, e páginas são templates com conteúdo real. A beleza é a composição hierárquica: peças pequenas e bem definidas se combinam em peças maiores, e a consistência dos átomos propaga para cima, garantindo que tudo o que é construído a partir deles herde o padrão. É o mesmo princípio de construir o complexo a partir do simples e confiável que atravessa toda a boa engenharia.
Os componentes precisam viver em um lugar, e esse lugar é a biblioteca de componentes, materializada e documentada, tipicamente com uma ferramenta como o Storybook, que mostra cada componente isolado, em todos os seus estados, com a documentação de como usá-lo. A biblioteca é onde a torah achat fica escrita e visível: um catálogo vivo que o designer consulta para desenhar com peças reais e o desenvolvedor consome para construir sem reinventar. Documentação de design system não é um PDF à parte que apodrece; é a própria biblioteca executável, sempre em sincronia com o que de fato existe no código.
O ganho mais subestimado de centralizar os componentes é a acessibilidade. Fazer um componente acessível de verdade, com os atributos ARIA certos, navegação por teclado, contraste adequado, foco visível, é trabalhoso e fácil de errar, e refazer isso em cada botão de cada tela é impraticável. No design system, a acessibilidade é resolvida uma vez, no componente, e herdada por todas as telas que o usam. O botão do sistema já é acessível; quem o consome ganha acessibilidade de graça, sem nem pensar nela. É a inversão que torna a acessibilidade viável em escala: em vez de depender de cada desenvolvedor acertar em cada uso, ela é embutida na peça e propaga. A uma só lei da interface pertence também a regra de que o produto seja usável por todos, e o design system é onde essa regra se cumpre por construção.
O que mata a maioria dos design systems não é a técnica, é a governança. Um design system criado uma vez e abandonado apodrece: fica desatualizado, os times param de confiar nele, criam suas exceções, e a babel volta. Design system é um produto, com clientes internos, os times que o consomem, e precisa ser tratado como tal: mantido, evoluído, versionado, e sustentado por alguém que responde por ele. A pergunta de governança mais difícil é o modelo de contribuição: quem pode adicionar ou mudar um componente? Um modelo centralizado, um time dono decide tudo, garante coerência mas vira gargalo; um federado, qualquer time contribui, escala mas arrisca fragmentar. A maioria dos sistemas maduros adota um meio-termo, um núcleo curado com contribuições revisadas.
A régua de sucesso de um design system é a adoção voluntária, não a quantidade de componentes. Se usar o sistema é mais difícil ou mais limitado que fazer à mão, os times o contornam, e ele vira uma biblioteca cara que ninguém usa. Por isso o design system precisa resolver a dor real dos times, cobrir os casos comuns bem, e ter um caminho claro para o caso que ele ainda não cobre, senão a exceção vira reinvenção. A uma só lei para todos, da Torá, tem uma condição implícita: a lei precisa ser justa e viável, ou o povo a contorna. Um design system imposto sem servir bem aos times gera revolta silenciosa e fragmentação; um que serve bem é adotado por gravidade, e é essa adoção, não o decreto, que faz a interface inteira falar de fato a mesma língua.
O design system amadurece da babel à lei viva. No começo é cada time com o seu botão, inconsistência por toda parte. Depois vem uma biblioteca de componentes compartilhados, o primeiro passo. No meio vêm os tokens como fundação e a acessibilidade embutida. No topo é o design system tratado como produto, com governança clara, adoção medida, documentação viva e a IA vigiando a consistência e a acessibilidade. Cada degrau troca a fragmentação pela coerência, e o segredo é que a coerência se sustenta por servir bem aos times, não por ser imposta.
O design system é o colchete que fecha este eixo e o costura ao anterior. É ele que dá coesão aos microfrontends, permitindo que fatias autônomas formem um só tabernáculo; é a expressão, na interface, do vocabulário compartilhado que os design patterns e a linguagem ubíqua do DDD buscam em suas camadas; e é uma plataforma no sentido do Platform Engineering, um golden path para construir interface, que sustenta os times por baixo. A torah achat, uma só lei para todos, é a metáfora exata: o valor de um padrão único não está em restringir, está em libertar, porque quem não precisa reinventar o básico fica livre para resolver o que de fato importa. Um design system bem feito é isso, a lei comum que, longe de engessar, é o que permite ao produto inteiro falar a mesma língua e a cada time construir mais rápido sobre um alicerce em que confia.
Design system é a torah achat da interface: uma só lei visual e de comportamento para toda a aplicação, para o produto inteiro falar a mesma língua. Os design tokens são o alfabeto, o Atomic Design é a gramática que compõe dos átomos às páginas, e a biblioteca é a fonte única da verdade, com acessibilidade embutida uma vez e herdada por todos. Mas o que sustenta um design system não é a técnica, é a governança e a adoção voluntária, porque lei imposta sem servir bem é contornada. A IA audita consistência, acessibilidade e adoção. O valor da lei comum, no fim, não é restringir: é libertar os times de reinventar o básico para resolverem o que importa.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaמִשְׁכָּן אֶחָד
O frontend monolítico vira gargalo quando muitos times disputam o mesmo código. Microfrontends dividem a interface em pedaços que times independentes constroem e entregam sozinhos, compostos numa só aplicação. O desafio é que as muitas cortinas, unidas, ainda pareçam um só tabernáculo.
Engenhariaפֶּה אֶל פֶּה
Uma API é uma promessa entre quem serve e quem consome, e uma promessa vaga gera integração sofrida. Bom design de API é fala clara: contrato explícito, semântica coerente e evolução que não quebra quem confiou em você. REST, GraphQL e gRPC servem a necessidades diferentes.
