Design system próprio ou biblioteca pronta: quem paga

Um design system que você constrói e uma biblioteca de componentes que você adota resolvem o mesmo problema. A diferença está em quem paga a manutenção e em quem decide quando algo muda. Adotar aluga essa decisão de um fornecedor. Construir compra a decisão e paga depois. Escolha perguntando qual conta o seu time consegue carregar no terceiro ano.

O que muda entre construir e adotar

Adotar uma biblioteca é comprar decisões já tomadas. Espaçamento, estado de foco, navegação por teclado e o trabalho de acessibilidade atrás de um select chegam prontos. O custo é uma dependência. A biblioteca decide o que o componente faz, e você decide como ele aparece.

Construir inverte essa conta. Você é dono do comportamento, dos tokens e da cadência de release. Você também é dono do bug no dropdown, da migração de um prop renomeado e da revisão que impede um hex cru de entrar num botão. O guia de tokens e tema cobre o que é ser dono dessa camada na prática.

O trabalho que desaparece quando você adota é o trabalho que fica invisível quando você constrói. O trabalho que aparece quando você adota fica invisível até o fornecedor mudar de rumo.

Quem paga a manutenção em cada caminho

A adoção espalha a manutenção por todo time que usa a biblioteca. Uma correção de segurança, uma diferença de navegador ou um padrão novo de ARIA entra uma vez e todos herdam. O problema é que ninguém dentro da sua empresa responde pelo calendário.

O Material Components for the web (em inglês), do Google, mostra como esse calendário se parece visto de fora. O README afirma que o projeto não é mais mantido ativamente e que as atualizações serão desligadas no futuro. O mesmo README diz que a biblioteca publica mudanças que quebram compatibilidade quase todo mês, seguindo semver, numa cadência de duas semanas com um major por mês. Um time que adotou cedo não pagou nada por anos e agora tem uma migração sem origem.

Construir concentra a manutenção em um time. Esse time responde as perguntas, entrega as correções e assume o plantão dos componentes. O Nielsen Norman Group nomeia o custo direto no Design Systems 101 (em inglês). Criar e manter um design system exige tempo e um time dedicado. O artigo acrescenta que um design system não é uma solução de uma vez só, porque ele evolui conforme os times mandam retorno.

Nenhum caminho remove o trabalho. A adoção converte um custo interno fixo num custo externo variável.

Quem controla a decisão de mudança

É isso que decide a maioria dos casos, e não tem a ver com custo.

Numa biblioteca adotada, a decisão de mudança pertence a pessoas que não conhecem o seu produto. Elas leem o próprio roadmap, a própria linguagem visual e a própria matriz de navegadores. O seu pedido vira uma issue num backlog público.

O padrão aparece no versionamento. O Radix Primitives publica um changelog datado por componente (em inglês), e as notas marcam entradas como quebra quando a mudança exige ação de quem chama. Uma entrada antiga marca o Accordion como major porque a API renomeou Accordion.Button para Accordion.Trigger e Accordion.Panel para Accordion.Content. Ninguém que usava aquele componente escolheu aquela data.

Num sistema que você constrói, a decisão pertence a um time dentro da empresa. Esse time anda mais rápido no seu requisito e mais devagar em todo o resto, porque as mesmas pessoas que decidem também implementam.

Controle vale o preço só quando o seu requisito difere do mainstream. Se o seu produto precisa do que todo mundo precisa, a decisão do fornecedor costuma ser melhor que a sua.

Quanto custa a exceção

Todo design system é sobrescrito em algum ponto. A pergunta é o preço da sobrescrita e quem paga por ela.

Numa biblioteca adotada, a exceção é local e barata no começo. Um componente de wrapper, um CSS de sobrescrita, um seletor com especificidade maior. O custo aparece depois, quando a biblioteca muda o markup e a sobrescrita quebra de um jeito que nenhum teste cobre.

Num sistema que você constrói, a exceção é cara no começo e barata depois. Alguém precisa decidir, nomear a variante nova e entregar para todos os chamadores. Depois disso, a exceção é parte documentada do sistema, e o próximo time herda.

Essa diferença pesa. Uma biblioteca adotada deixa a primeira exceção de graça e a centésima cara. Um sistema construído deixa a primeira exceção cara e a centésima barata.

Quando o requisito não cabe no componente alheio

Este é o momento em que a decisão é testada, e ele chega numa data que ninguém controla.

Há quatro jeitos comuns de o requisito não caber. O componente não tem um estado que o seu produto precisa. A linguagem visual diverge da linguagem do fornecedor. O comportamento conflita com uma regra ou uma convenção de plataforma do seu mercado. Ou o componente serve, e a versão que você precisa foi descontinuada antes do seu lançamento.

O Material Components for the web (em inglês) é o caso limpo da última hipótese. Um time que construiu em cima dele em 2019 tem código funcionando e nenhum caminho adiante, a menos que faça um fork. O fork significa que a manutenção terceirizada volta, com juros, para um time que não tem mais o contexto original.

O Radix (em inglês) toma a posição oposta para o mesmo problema. As primitivas entregam comportamento e deixam o estilo para quem chama, então uma divergência de design não é fork. É o uso previsto.

O erro a evitar não é nenhum dos dois caminhos. É adotar uma biblioteca estilizada pelo comportamento e brigar com os estilos dela por dois anos em vez de fazer fork ou trocar.

O caminho do meio: biblioteca headless com camada de estilo própria

Construir ou adotar não esgota a escolha. Existe um meio-termo, que carrega o comportamento de uma biblioteca adotada e as decisões de um sistema construído.

Uma biblioteca headless entrega a parte difícil. Gestão de foco, navegação por teclado, ligação de ARIA, posicionamento e portal chegam testados. Você fica com os tokens, com a camada visual dos componentes e com a linguagem de design. O Radix Primitives mantém um histórico público de versão por componente (em inglês) para o comportamento que ele controla.

A divisão reflete quem é bom no quê. Acessibilidade e detalhe de interação custam caro para acertar e são amplamente compartilhados. Linguagem visual é específica de um produto e barata de mudar quando os tokens são seus.

Isso tem custo. Você passa a manter uma camada de estilo entre as primitivas e as telas. Essa camada precisa de donos, testes e política de descontinuação, igual a um sistema construído. A economia é nunca ser dono da armadilha de foco.

Headless é o padrão certo para um produto com identidade visual própria e um time de plataforma pequeno. É a escolha errada para um time sem capacidade de manter uma camada, e para um produto satisfeito com a linguagem do fornecedor.

Quando a biblioteca pronta é a escolha certa

A adoção ganha mais vezes do que quem defende design system admite.

Adote quando o produto tem um time, ciclo de vida curto, ou uma linguagem visual que já combina com uma biblioteca madura. Adote quando o time não consegue nomear um dono da manutenção nos próximos doze meses. Adote quando a superfície de plataforma é pequena e o trabalho de acessibilidade é o risco principal.

O caso mais forte de adoção é um produto que precisa do que todo mundo precisa. Um painel, uma ferramenta interna e um checkout resolvem problemas que milhares de times já resolveram, e o fornecedor absorveu esse custo.

Quando o sistema próprio é desperdício

Um design system é uma aposta no reúso. Quando o reúso não existe, a manutenção não tem o que pagar.

Construir é desperdício quando o produto entrega uma interface só e não tem segundo consumidor. É desperdício quando o mesmo time cuidaria do sistema e do produto, porque o sistema passa a competir com o roadmap. É desperdício quando a linguagem visual ainda muda a cada trimestre, já que os tokens vão ser reescritos antes de serem reusados.

O NN/g lista as mesmas condições pelo outro lado. Um design system precisa de time dedicado, precisa de tempo para ensinar e enfrenta a percepção de que projetos são criações isoladas.

Onde as fontes discordam

Os três artigos do NN/g não descrevem o mesmo sistema, e a diferença vale ser nomeada antes de você orçar um.

O Design Systems 101 (em inglês) trata time dedicado como pré-requisito e como custo de entrada. O artigo de times enxutos de design system (em inglês) relata o formato oposto na prática. Equipes de duas a cinco pessoas são a norma, e é o tamanho reduzido que as torna eficazes, não uma concessão. O artigo de maturidade de design system (em inglês) acrescenta a parte que o planejamento costuma esquecer. A maturidade não é linear, e sistemas regridem depois de lançados.

Os três concordam em dois pontos, e são esses que ficam. O sistema precisa de dono nomeado, e continua mudando depois do lançamento. O artigo de consistência e padrões (em inglês) é a razão de o dono ter trabalho: consistência é uma propriedade que alguém mantém, não um estado que o sistema alcança.

Dimensione o time pela sua própria evidência, não pelo pré-requisito. Se duas a cinco pessoas dão conta, o caso de construir melhora, não piora.

O sinal para começar a construir é específico. Um segundo time aparece, ou o mesmo padrão de tela é reconstruído pela terceira vez. Os dois casos significam que alguém já paga pela duplicação.

Como decidir, e o que medir

Decida com três perguntas, respondidas antes de escrever código.

Quem responde quando o componente precisa mudar, e quanto isso leva hoje.
Quanto custa uma exceção em horas, em cada opção, e quem aprova.
O que acontece com este produto em três anos se a biblioteca parar de publicar ou o requisito mudar.

Depois da decisão, acompanhe esses três números, e não o tamanho da biblioteca de componentes.

Tempo da solicitação até o componente mudado, contado da primeira mensagem até o release publicado.
Número de sobrescritas locais contra componentes do sistema, contado por time e revisado numa cadência.
Custo de upgrade por versão major, em horas, incluindo as partes que quebraram em silêncio.

Mais dois ajudam no lado da manutenção. A fatia de componentes com dono nomeado no repositório, e a idade do pedido mais antigo sem resposta.

Meça por time, nunca como média. Um adotante forte pode carregar um número que esconde três times construindo fora do sistema.

Confira antes de assinar a decisão

Confirme que a decisão de mudança tem dono nomeado, nos dois caminhos.
Confirme que o custo de saída está escrito antes da adoção, incluindo a hipótese de fork.
Confirme que cada exceção tem motivo registrado e condição de encerramento.
Confirme que a camada de estilo tem política de descontinuação se você escolheu headless.
Confirme que as três métricas têm um leitor que age sobre elas.

Construir ou adotar importa menos que três coisas: um dono nomeado para a decisão de mudança, um custo medido para a exceção e um plano para o ano em que a biblioteca ou o produto se move.