UX e UI em escala: o argumento por tratar o design como infraestrutura, e não como ferramenta

O texto, publicado pela Penpot (que vende uma plataforma de design de código aberto), parte de uma troca de pergunta. Em vez de "qual ferramenta de design comprar", o time deveria perguntar de qual infraestrutura de design precisa para que UX e UI acompanhem o resto do negócio. O argumento é que o que funciona com 5 pessoas quebra quando há dezenas de times, mercados regulados, white-label e várias marcas compartilhando os mesmos padrões.

A definição central: infraestrutura de design é a camada em que artefatos estruturados e legíveis por máquina (componentes, tokens, documentação) ficam disponíveis para sistemas de engenharia e automação. Um exemplo do texto: mudar o token usado nos botões atualiza os arquivos de design e a biblioteca de componentes em código, sem cópia manual. O design system é o catálogo de diretrizes, e a infraestrutura é a engrenagem que faz o catálogo funcionar entre times, fluxos e repositórios. O texto cita ainda o formato de tokens do DTCG, MCP, APIs e webhooks como caminhos de integração, e cita o self-hosting como forma de controlar onde os dados vivem e quais ferramentas, inclusive de IA, acessam o quê. Do lado dos custos de plataformas fechadas, aponta preço por usuário, trabalho manual para cobrir lacunas, integrações frágeis e, em alguns casos, reconstrução completa ao trocar de fornecedor. Vale lembrar que o autor tem interesse comercial na tese.

A tese conversa com a cobertura recente do CEVIU, mas não é a evolução de um mesmo fato. Em 11 de novembro de 2026, o CEVIU noticiou "X morreu" morreu: design systems precisam funcionar independentemente das ferramentas, sobre toolchains padronizadas se fragmentando em fluxos mais personalizados. O texto da Penpot, um dia depois, leva o argumento adiante: se a ferramenta muda, o que sustenta o sistema é a camada de infraestrutura.

Em 8 de setembro de 2026, o CEVIU publicou Desvendando a Escalabilidade de Design Tokens: Um Guia para Equipes Maiores, que apontava gargalos quando os tokens crescem de 50 para 500 unidades, ligados à falta de clareza sobre responsabilidades. A infraestrutura descrita agora aborda essa escala pela via da governança e da integração com código.

Para quem opera design system, a leitura prática é olhar além da biblioteca de componentes. Pergunte se tokens e componentes chegam ao código sem retrabalho, se há papéis de comentário sem risco de edição e se dá para sair do fornecedor sem refazer tudo. Para o usuário final, o ganho esperado é consistência: uma mudança de marca ou de padrão chega a todos os produtos ao mesmo tempo. Como a fonte é de um fornecedor, vale comparar o argumento com as suas próprias restrições de segurança e custo.