Design system morre depois do lançamento, não nele

Design system raramente falha no lançamento. Ele falha meses depois, quando um time entrega uma tela com uma cor avulsa e ninguém anota o motivo. O que sustenta o sistema depois disso é processo de manutenção, não a biblioteca de componentes. Versionamento, depreciação e caminho de contribuição decidem se ele sobrevive.

O lançamento é a parte fácil

O dia do lançamento é um esforço coordenado, com prazo e dono visível. A biblioteca entra no ar, a página de documentação abre, e os primeiros times adotam porque ajudaram a construir.

Os meses seguintes não têm nenhuma dessas condições. Não existe prazo, não existe canal de lançamento, e não existe atenção compartilhada.

O Carbon, design system da IBM, modela isso na página Product Development Lifecycle (em inglês). Ela divide a contribuição em discovery, delivery e launch and scale. A página diz que um ativo fica estável nessa última fase, então estabilidade é etapa posterior e não linha de partida.

O Nielsen Norman Group faz a mesma observação no artigo Design Systems 101 (em inglês). O texto chama o design system de “not a one-and-done solution” e diz que o sistema segue evoluindo conforme os times mandam retorno. O artigo também nomeia o custo: criar e manter exige muito tempo e um time dedicado.

A falha não faz barulho. Ninguém apaga um design system. As pessoas param de importar dele, um arquivo por vez.

Manutenção é processo, não biblioteca

Uma biblioteca de componentes é um artefato. Ela não tem opinião sobre o que acontece quando quem chama precisa de algo que ela não oferece.

O NN/g separa as duas partes de um design system: o repositório e as pessoas que o administram. O repositório guarda o guia de estilo, a biblioteca de componentes e a biblioteca de padrões. A segunda parte é a que se degrada.

Processo responde o que a biblioteca não responde. Quem decide quando um componente muda. Como uma mudança quebra quem chama. Onde um time pede algo novo. O que acontece quando o pedido é recusado.

Biblioteca sem processo vira retrato de uma época. Ela continua instalando e continua correta na documentação, enquanto o produto se afasta dela.

O que vira componente e o que fica local

Nem todo elemento repetido merece lugar no sistema. A decisão é sobre reúso e custo, não sobre arrumação.

O GOV.UK Design System publica critérios de contribuição (em inglês) que respondem isso direto. A proposta precisa ser útil, ou seja, precisa de evidência de que muitos times precisam dela. E precisa ser única, sem duplicar o que já existe.

Os critérios de publicação somam mais três. A implementação precisa ser usável em pesquisa com usuário, consistente com os estilos e componentes existentes, e versátil o bastante para servir vários serviços.

Versatilidade é o critério que prevê custo de manutenção. Um campo de data que serve um único serviço vai pedir mudança no dia em que o segundo serviço chegar.

Na dúvida, mantenha local. Um elemento usado em duas telas de um produto, com um dono e sem plano de reúso, é mais barato dentro do produto. A página de ciclo de vida do Carbon (em inglês) marca uma fronteira parecida por outro motivo: ele não assume a propriedade de aplicações inteiras nem de ferramenta de terceiro.

Leve o elemento para o sistema quando um segundo time precisar dele, ou quando a terceira cópia aparecer. Os dois sinais querem dizer que outra pessoa já está pagando pela duplicação.

O componente que aceita qualquer coisa

Componente com prop para todo valor é folha de estilo disfarçada. O invólucro parece ativo do sistema, e as decisões de design ficam no ponto de uso.

O checklist de componente do Carbon (em inglês) mostra o padrão oposto. Os requisitos de spec exigem que o desenho use os tokens de cor, de tipografia e de espaçamento do sistema, e que as cores fiquem tokenizadas. A página dá o motivo: tokens reduzem o custo de manutenção e tornam o tema possível. O guia de tokens e tema cobre como esse conjunto de tokens vira um tema.

Uma prop que aceita cor crua, espaçamento cru ou objeto de estilo livre remove essa garantia. O conjunto de tokens deixa de ser a fonte da verdade, porque quem chama pode definir qualquer valor sem passar pelo sistema.

A conferência é simples. Conte as props que aceitam valor cru em vez de opção nomeada. Cada uma é um lugar onde a regra pode ser quebrada sem revisão.

Dois limites mantêm a regra usável. Um componente de layout precisa aceitar largura e posição, porque o sistema não conhece a página. E um invólucro que repassa classe existe em quase todo sistema real, como válvula de escape.

A diferença está em registrar a válvula de escape. Válvula não registrada vira o caminho normal em dois trimestres.

Versionamento e depreciação

Versionamento é promessa sobre o contrato, não sobre o código. O número que importa é o que quem chama lê antes de atualizar.

Versionamento semântico dá o formato. Patch não muda nada observável, minor acrescenta, e major quebra. A parte difícil é combinar o que conta como quebra. Prop renomeada, padrão alterado e estado visual removido quebram quem chama mesmo com a marcação idêntica.

Depreciação é a parte que a maioria dos sistemas pula. Ela precisa de quatro campos escritos no momento da decisão: o que está depreciado, o que substitui, quem é dono da migração, e a data em que o caminho antigo sai.

O GOV.UK Design System define uma expectativa parecida para os recursos que linka (em inglês). Um recurso da comunidade precisa responder chamado em até um mês e ficar no máximo três meses atrás da última versão do GOV.UK Frontend. São termos de manutenção, publicados antes.

A janela importa mais que a data. Depreciação sem data de remoção acumula caminhos paralelos, e cada caminho dobra a superfície que o sistema precisa testar.

O Carbon trata o mesmo problema com status em vez de data. O checklist (em inglês) mapeia cada ativo para um status, de Draft e Preview candidate até Preview e Stable, e amarra esses status às fases do ciclo de vida. Só o time do Carbon move um ativo de discovery para delivery, e a página avisa que nem toda proposta avança.

O Material Components for the web, a implementação do Material pelo Google, coloca a porta mais cedo. Os requisitos de um componente novo ficam num guia de contribuição (em inglês) que qualquer pessoa lê antes de propor. Componente que não dá para testar não dá para outra pessoa manter.

O caminho de contribuição

Caminho de contribuição é a rota de “precisamos disso” até “o sistema tem isso”. Se a rota é confusa, os times constroem local e o sistema perde a autoridade sobre o produto.

O USWDS, design system do governo dos Estados Unidos, publica a rota inteira (em inglês). Qualquer pessoa pode sugerir um componente, começando por uma discussão no GitHub. Se a discussão ganha apoio, o time central transforma em proposta formal, e a proposta recebe 45 dias de comentário público antes da decisão.

Os 45 dias são o detalhe interessante. Uma janela pública longa custa velocidade e compra legitimidade, porque componente que entra no sistema com discordância anexada entra com objeções conhecidas (USWDS (em inglês)).

O USWDS também roda pedidos de recurso e relatos de bug em listas públicas, onde voto e comentário definem prioridade. Isso dá ao time uma segunda opção além de construir local: somar peso a um pedido existente.

Três propriedades fazem o caminho funcionar. Ele está escrito. Tem um dono que responde. E tem resposta de recusa, para o time saber por que o pedido caiu em vez de adivinhar.

Registre a exceção, não proíba

Toda regra de um design system vai ser quebrada em algum momento. O que importa é se dá para ver quando isso acontece.

Exceção registrada carrega cinco campos: a regra quebrada, o motivo, o dono, a data e a condição que encerra. O último campo transforma exceção em decisão em vez de hábito.

Exceção não registrada é invisível do pior jeito. Parece arquivo normal do produto, e parece componente normal na revisão.

Um arquivo curto no repositório resolve. Uma linha por exceção, revisada no mesmo ritmo do código, com contagem que qualquer pessoa lê.

O útil está na contagem. Sistema com quatro exceções abertas é sistema com quatro lacunas conhecidas. Sistema com quarenta é sistema cujas regras já não descrevem o produto.

O que medir depois do lançamento

Três números mostram se o sistema está de pé, e nenhum deles é o tamanho da biblioteca.

Adoção por time: a fatia de telas construídas com componentes do sistema em vez de cópias locais, medida por import ou por contagem de implementação duplicada.
Exceções abertas: quantas estão registradas, qual a idade delas, e quantas passaram da condição de encerramento sem fechar.
Tempo para entregar tela nova: o intervalo entre a spec de design e a tela no ar, medido também para quem contribui pela primeira vez.

Mais dois ajudam no lado da manutenção. Tempo para fechar um bug relatado por outro time, e a fatia de depreciações concluídas na data publicada.

Meça o primeiro número por time, não no agregado. Um adotante forte carrega a média enquanto três times constroem por fora.

Quando o design system não vale a pena

Design system é aposta em reúso ao longo do tempo. Quando o reúso não existe, o custo de manutenção não tem o que pagar.

O NN/g lista as condições que fazem a aposta falhar. O trabalho exige muito tempo e um time dedicado. Ensinar as pessoas a usar leva tempo. E os projetos podem ser percebidos como criações avulsas que não precisam de componente compartilhado.

Isso aponta para três casos reais contra construir um. Produto único com um time só, que já compartilha canal e hábito de revisão. Time pequeno demais para alguém ser dono da manutenção. Produto com ciclo de vida menor que o tempo de retorno do sistema no primeiro ano.

Nesses casos, uma folha de estilo compartilhada, uma escala tipográfica documentada e hábito de revisão cobrem quase todo o valor por uma fração do custo.

Enquanto o produto estiver num desses casos, manter um sistema custa mais do que devolve. Os sinais de que chegou a hora estão no post sobre construir um design system ou adotar uma biblioteca.

Onde os artigos do NN/g divergem

Três artigos da mesma casa não concordam sobre quem toca o design system.

Para o Design Systems 101 (em inglês), um sistema pede gente dedicada a ele, e isso entra na conta. Times enxutos de design system (em inglês) mostra que a maioria dos times tem de duas a cinco pessoas, muitas vezes dividindo o trabalho de sistema com o de produto. O artigo trata o tamanho pequeno como escolha deliberada. Os dois textos divergem sobre time dedicado.

Eles também divergem sobre o que conta como avanço. O artigo 101 ancora o valor do sistema na escala: dezenas de times e milhares de telas. Maturidade de design system (em inglês) diz que maturidade não é linear, que a adoção nunca termina e que sistemas regridem. Um time de dez pessoas e uma empresa de dez mil podem ter sistemas maduros. Os dois textos divergem sobre escala como régua.

Eles concordam em pouca coisa. O sistema precisa de donos, e ele segue mudando depois do lançamento.

Verifique antes de chamar de mantido

Confirme que todo componente tem dono nomeado no repositório.
Confirme que o caminho de contribuição está publicado, com prazo de resposta declarado.
Confirme que cada ativo depreciado tem substituto, dono e data de remoção.
Confirme que o conjunto de tokens é o único caminho para cor, tamanho de texto e espaçamento.
Confirme que o registro de exceções é legível, atual e contado em periodicidade definida.
Confirme que a adoção é reportada por time, não como média única.
Para cada uma das três métricas, nomeie quem a lê e o que essa pessoa faz quando ela piora.

O design system que sobrevive ao lançamento raramente é o de maior biblioteca. É o que tem rota documentada para o próximo pedido, plano com data para a próxima remoção, e registro que mostra onde as regras já quebraram.