Sobre construir sistemas

Design não é mais só sobre telas. O momento atual da tecnologia pede que designers pensem em sistemas.

Já disse antes que agora precisamos tratar o código como matéria-prima. Mas não para por aí.

Com a IA, nossos usuários não são mais só pessoas. As pessoas continuam sendo a parte mais importante, claro. Mas os agentes precisam ser levados em conta na mesma medida. Eles leem nossos arquivos, constroem nossas telas e tomam decisões que antes tomávamos à mão. Se desenhamos só para quem olha o resultado, deixamos quem produz o resultado no chute.

Só que a velocidade multiplica o que estiver por baixo. Sem uma fundação, o agente escala os padrões que aprendeu com todo mundo. A skill de frontend-design da Anthropic mantém uma lista deles e os chama de “os sinais mais comuns de uma página gerada”. Você já viu: as mesmas fontes, os mesmos cards dentro de cards, os mesmos gradientes. Funciona, mas não parece bem construído.¹

A IA ainda precisa de estrutura, gramática, gosto, regras e diretrizes para produzir algo que pareça bem construído de verdade. Esse é o trabalho agora.

O Linear é um bom exemplo. Quando redesenharam o app, o objetivo era “reduzir o ruído visual, manter o alinhamento e aumentar a hierarquia e a densidade dos elementos de navegação”. Isso não é uma tela. É uma regra que toda tela precisa seguir. Karri Saarinen descreve o “L invertido” da moldura global que controla a área principal. Quando esse formato existe, as novas telas não precisam reinventá-lo.²

A Stripe faz o mesmo por escrito. A orientação deles para apps de página inteira diz: “Comece com uma visão geral e deixe as pessoas descobrirem os detalhes no próprio ritmo”. Uma frase, e cem páginas saem consistentes.³

É isso que um sistema entrega. Não mais componentes, e sim menos decisões deixadas ao acaso.

Emil Kowalski resume bem: “Quase toda decisão de ‘gosto’ tem uma razão lógica”. Se você consegue explicar o porquê, consegue escrever. Se consegue escrever, um agente consegue seguir.⁴

Karl Koch mostra como. Ele transforma uma preferência vaga em três partes: quando a regra se aplica, o que ele costuma escolher e como verificar se funcionou. Cada regra vem junto do jeito como ela falha, o que ele chama de “um princípio, um teste”. “Deixa mais polido” vira algo que dá para testar de fato.⁵

Tenho feito isso no meu próprio trabalho. Meu design system tem uma camada de gramática, um conjunto de lições sobre como as partes se combinam. A primeira linha diz sem rodeios: “Os componentes são os substantivos. A gramática é como eles se combinam, e por quê”. Uma das lições é sobre cantos aninhados: o raio interno é o raio externo menos o padding, e um componente faz a conta, então ninguém escolhe no olho. Regra pequena, mas é o tipo de detalhe que separa o bem construído do gerado. E “os agentes leem os mesmos arquivos de lições” que as pessoas.⁶

Lauren Tan, que criou o pstack, diz: “A habilidade mais importante da sua caixa de ferramentas é uma boa skill de verificação”.⁷

O guia dela é direto: “‘Compila’ não é evidência”. O que mantém os agentes dela no rumo não são prompts espertos. É estrutura: passos claros, princípios pequenos e prova no final.⁸

Em design, prova significa olhar. Jakub Krehel criou uma skill que “renderiza qualquer componente em todos os seus estados, numa página descartável com dados de mentira”. Vazio, carregando, erro, texto longo demais. A maioria dos bugs de uma interface mora nos estados que ninguém abriu.⁹

O v0 segue a mesma linha com design systems. A documentação diz que uma skill de design system “não é uma cópia da sua documentação; é um adaptador que mostra ao v0 onde está a sua fonte”. E traça um limite claro: “Se um componente, uma prop ou um token não puder ser verificado nas fontes, o v0 não deve usá-lo”. Isso é um sistema que se verifica sozinho.¹⁰

Matt Pocock tem uma regra para trabalhar com agentes de que eu gosto: “Encontrar os fatos é trabalho seu, nunca do usuário”. O agente encontra os fatos. As decisões ficam com a pessoa. Em design, isso quer dizer que o agente pode construir cinco direções, testar todos os estados e verificar todas as regras. Escolher a direção certa continua sendo com a gente.¹¹

Então o trabalho muda. Menos tempo empurrando pixels numa tela. Mais tempo decidindo o que deve valer em todas as telas, escrevendo isso e garantindo que dá para verificar.

Se queremos software que pareça bem construído, precisamos construir o que fica por baixo: a estrutura, a gramática, as regras e as verificações. Os agentes vão escalar o que a gente der para eles. Por isso sistemas importam tanto agora. Dê a eles algo que valha a pena escalar.