A maioria das equipes acha que um sistema de design é um arquivo do Figma e uma biblioteca de componentes. Esses são artefatos de um sistema de design, não o sistema em si. O sistema real é o conjunto de decisões — escala de espaçamento, lógica de cores, regras de movimento, quando usar qual padrão — que permitem que um produto permaneça coerente à medida que mais pessoas, em mais equipes, tocam mais partes dele.
O modo de falha que mais vemos não é uma biblioteca de componentes ausente. São componentes que existem, mas cujas decisões subjacentes nunca foram registradas, então cada novo colaborador reinventa o raciocínio do zero, e o sistema vai se desviando um pouco a cada adição.
O que construímos para os clientes, em vez disso, é um pequeno conjunto de primitivos com regras explícitas anexadas — não apenas como o botão se parece, mas quando você usaria um botão versus um link de texto versus um CTA magnetizado, e por quê. Os componentes importam menos do que as regras que os geraram, porque as regras se generalizam para casos que ninguém havia projetado ainda.
O teste de um bom sistema de design não é se ele parece polido no arquivo. É se um novo engenheiro, daqui a seis meses, consegue construir uma tela que ninguém desenhou ainda e fazer com que ela pareça pertencer ao conjunto.