Defina decisões, não apenas uma galeria visual
Um sistema de design é mais que capturas de tela. Ele registra decisões que se repetem: espaçamento entre seções, o tratamento da ação primária, como um erro de formulário funciona e a linguagem usada após sucesso ou falha. O USWDS descreve os design tokens (tokens de design) como paletas discretas para valores como tipografia, espaçamento, cor, altura de linha e opacidade. Documente a regra, finalidade, variantes aprovadas e responsável. Comece com fundações e com os cinco a oito componentes usados com mais frequência nas jornadas importantes; padronizar todas as páginas de uma vez costuma criar ruído em vez de clareza.
Registre papéis de cor aprovados, tipografia, espaçamento, bordas, raios, breakpoints e escolhas de movimento que seu site realmente usa.
Use um padrão para um arranjo de tarefa repetível, como criação de conta ou resultados de busca, em vez de para um único detalhe visual.
Use tokens para controlar valores repetidos
Um design token é um nome legível associado a um valor. O Design Tokens Community Group descreve tokens como uma forma independente de plataforma para expressar decisões de design; no mínimo, um token é nome e valor. Use nomes por propósito como color-action-primary ou space-section em vez de espalhar valores brutos pelos templates. Mantenha um mapeamento documentado de tokens por propósito para valores base. Tokens facilitam mudanças coordenadas, mas não garantem contraste, identidade visual ou boa hierarquia. Valide cada combinação renderizada e estado de página.
Crie tokens para escolhas repetidas, não para todas as exceções; caso contrário a lista de tokens apenas preserva a inconsistência.
Para um token usado amplamente, liste as páginas afetadas, teste telas representativas e forneça orientação de migração ou rollback quando necessário.
Construa componentes com comportamento e limites
Um componente é uma parte de interface reutilizável com comportamento, não apenas uma forma visual. Documente a estrutura semântica, entradas obrigatórias e opcionais, variantes, comportamento responsivo e todos os estados relevantes: carregando, desabilitado, erro, vazio e sucesso. Inclua comportamento por teclado e orientação de conteúdo. Não force todo layout a se tornar um componente. O GOV.UK avalia componentes compartilhados quanto à utilidade, singularidade, usabilidade, consistência e versatilidade; essa é uma disciplina útil para decidir o que merece manutenção compartilhada. Um componente amplamente reutilizado pode espalhar um defeito em grande escala, então teste-o nas páginas onde as pessoas realmente o usam.
Liste cada estado visível ao usuário e mostre rótulos reais, textos longos e erros para que os limites de implementação fiquem visíveis.
Marque variantes antigas claramente, nomeie a substituição e remova-as somente após as jornadas afetadas terem sido revisadas.
Faça da acessibilidade uma condição para liberação
A acessibilidade precisa estar incorporada ao sistema porque escolhas repetidas podem repetir barreiras. A WCAG 2.2 exige, no Nível A, operação por teclado para funcionalidades exceto quando o caminho de movimento é inerente, e exige ordem de foco significativa quando a sequência importa. Faça controles semânticos, foco visível, rótulos, movimento lógico de foco, identificação de erro e conclusão de tarefas sem apontador parte da orientação de componentes. Use verificações automatizadas cedo, depois testes manuais por teclado, zoom, responsividade e revisão de páginas. O USWDS alerta que componentes acessíveis não garantem um serviço acessível; código personalizado, conteúdo, integrações e contexto ainda exigem revisão.
Confirme que as pessoas conseguem alcançar, operar, entender e sair dos controles sem mouse e sem armadilhas de foco.
Deveres legais variam por jurisdição e contrato. Busque revisão qualificada de acessibilidade e jurídica quando a conformidade for material.
Trate normas de conteúdo como normas de interface
Palavras são entradas de componente, não decoração adicionada após o design. Estabeleça regras para rótulos de ação, rótulos de formulário, erros, títulos, links, terminologia, datas, números e abreviações. A orientação do GOV.UK favorece voz ativa e tratar o usuário por você quando possível; use o princípio de linguagem clara e consistente, adaptando a voz ao seu público. Combine regras com um modelo de conteúdo: indique quais campos são obrigatórios, orientações sensatas de comprimento e o que acontece quando informação estiver ausente. Coloque a orientação na documentação do componente e nos fluxos de trabalho do CMS, onde editores possam usá-la.
Diga o que falhou, onde aconteceu e a próxima ação quando for seguro e útil fazê-lo.
Um limite é um sinal para redesenhar ou reescrever, não permissão para remover significado essencial.
Governança antes que o sistema cresça mais rápido que a confiança
Governança é o processo leve para propriedade, solicitações, revisão, liberações e aposentadoria. Nomeie um responsável e um grupo de revisão que reúna design, engenharia, conteúdo e expertise em acessibilidade. Combine evidência com raio de impacto. Um padrão local pode precisar de uma declaração de problema e teste de página. Uma alteração em botão ou token compartilhado deve incluir jornadas afetadas, verificações de acessibilidade, comparação visual, notas de migração e instruções de rollback. O GOV.UK pede que contribuidores mostrem que um componente é útil para muitas equipes, não um duplicado, e testado com usuários representativos; use isso como modelo prático, não como regra universal.
Salve o problema, opções, decisão, responsável, versão afetada e data de revisão onde as equipes possam buscar.
Rotule mudanças como patch, aditiva ou breaking para que consumidores saibam quando migração e período de compatibilidade são necessários.
Previna regressões antes da liberação
Conecte o sistema à entrega. Exija que uma mudança identifique tokens e componentes tocados, depois teste estados afetados e páginas representativas. Comparação visual, testes de interação, revisão de conteúdo e verificações de acessibilidade encontram defeitos diferentes. Priorize jornadas de alto impacto e também as de alto tráfego; acesso à conta e formulários de contato podem ser importantes mesmo com tráfego modesto. Isso apoia o trabalho de otimização proativa de uptime e remediação do Status Is UP ao reduzir o escopo de defeitos e tornar uma correção aprovada mais fácil de verificar. Não é monitoramento de indisponibilidade nem substituto para um plano de incidentes.
Mantenha a versão do componente, resultados de testes, achados, aprovações e qualquer risco aceito com o registro de liberação.
Preserve a versão estável anterior e teste etapas escritas de restauração e verificação durante manutenção de baixo risco.