Um checklist de consistência de UI que você consegue realmente executar

A lista padrão faz perguntas como "o visual e a sensação da interface são consistentes?" e "os labels são usados de forma consistente?". Isso é apenas reformular o objetivo. Quem executa a auditoria precisa converter cada pergunta em algo verificável, e fará isso de forma diferente a cada vez — o que torna a própria auditoria inconsistente.

Para valer a pena, uma verificação precisa de três coisas: um item específico para analisar, uma forma de analisá-lo e uma condição que determine aprovação ou falha. Tudo abaixo possui os três.

Cinco minutos, sem necessidade de julgamento, e detecta uma parcela surpreendente de drift real. Cada uma dessas verificações deve acabar no CI após ser aprovada; uma verificação que roda apenas durante auditorias permite que o drift se acumule entre elas.

1. 1

   Valores de cores literais fora do arquivo de tokens

   A verificação de maior rendimento. Qualquer hex em um componente significa que a camada de tokens foi ignorada, e significa que aquela cor não pode ser alterada centralmente.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \
     | grep -v 'tokens\|globals.css'

2. 2

   Pesos de fonte fora da sua faixa

   O peso é onde a hierarquia silenciosamente retorna aos padrões do framework. Se o seu sistema define 400 e 600, qualquer coisa mais pesada é drift, independentemente da aparência.

   Copy

   grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black)|font-weight:\s*[78]00' src

3. 3

   Valores de espaçamento fora da escala

   Saídas de escape com valores arbitrários são onde o ritmo morre. Um p-[13px] não é nada; quarenta deles são um segundo sistema de espaçamento com o qual ninguém concordou.

   Copy

   grep -rn --include='*.tsx' -E '\b(p|m|gap|space)-\[[0-9]+px\]' src

4. 4

   Valores de radius

   O radius sofre drift mais do que qualquer outra coisa, porque cada autor de componente escolhe o que parece certo isoladamente. Conte os valores distintos em uso; mais de três ou quatro é um achado.

   Copy

   grep -rhoE 'rounded-[a-z0-9]+|border-radius:\s*[0-9]+px' src -r \
     --include='*.tsx' --include='*.css' | sort | uniq -c | sort -rn

5. 5

   Propriedades que seu sistema proíbe

   O que quer que sua lista de proibições nomeie. Se ela diz que elevação nunca é uma sombra, esta verificação impõe isso. Se você não tem uma lista de proibições, esse é o achado — escreva uma primeiro.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E 'box-shadow|shadow-(sm|md|lg|xl)|gradient' src

A quarta verificação tem um detalhe importante: contar valores de radius distintos informa sobre a consistência, não sobre a correção. Três valores usados deliberadamente — 6px em controles, 12px em containers, full em avatares — é um sistema. Três valores que por acaso são 6, 8 e 10 é um drift que não foi notado.

Aqui está o erro de todo processo de auditoria. Revisar uma tela isoladamente diz se ela é internamente coerente. Não diz nada sobre se ela combina com as outras telas, porque você não consegue manter as outras telas na cabeça com precisão suficiente.

Portanto, abra três telas finalizadas da mesma superfície lado a lado — três telas de aplicação, ou três páginas de marketing, nunca uma mistura. Comparar um dashboard com uma landing page produz diferenças que deveriam estar lá.

As três últimas linhas são onde o trabalho de consistência é quase sempre mais fraco, e isso não é descuido — estados de empty, loading e erro são escritos sob pressão de tempo, individualmente, por quem quer que estivesse naquele arquivo. Eles também são, desproporcionalmente, o que um usuário frustrado vê.

As seis linhas acima são onde a divergência se concentra. Esta é a lista completa, agrupada para que você possa resolvê-la de uma só vez. Cada item possui uma condição de aprovação em vez de uma pergunta.

• Cada cor em cada tela resolve-se em um papel (role) nomeado. Falha se qualquer componente contiver um valor literal.
• A cor de destaque aparece nos mesmos tipos de elemento em todas as telas. Falha se for um botão em uma tela e um título em outra.
• Cores de status aparecem apenas para status. Falha se a cor de sucesso for usada decorativamente em qualquer lugar.
• Cada cor do modo claro tem uma contraparte no modo escuro que foi escolhida, não derivada. Falha se qualquer superfície for uma inversão direta.

• Cada tamanho na tela é um degrau da escala. Falha se você encontrar um tamanho que não seja.
• Os pesos permanecem dentro da faixa declarada. Falha em qualquer peso acima dela, por melhor que pareça.
• O mesmo nível semântico tem a mesma aparência em todos os lugares — cada título de página corresponde a todos os outros títulos de página. Falha se duas telas diferenciarem seus títulos de formas distintas.
• Números em colunas são tabulares e alinhados. Falha se os dígitos não estiverem alinhados entre as linhas.

• Cada valor de espaçamento é um degrau da escala. Falha em qualquer valor arbitrário.
• Os valores de raio distintos são poucos e cada um tem um propósito definido. Falha se você não conseguir explicar por que 8px existe ao lado de 6px.
• A elevação é indicada da mesma forma em todos os lugares. Falha se sombras e bordas forem usadas simultaneamente para a mesma função.
• O ritmo da seção é consistente — o espaço entre um título e seu conteúdo é o mesmo em cada tela. Falha em qualquer variação sem justificativa.

• Uma implementação por componente. Falha se dois arquivos definirem um card.
• Ações primárias são idênticas e ocupam a mesma posição relativa. Falha se uma tela a coloca à esquerda e outra à direita.
• Ações destrutivas são visualmente distintas e consistentes. Falha se o botão de excluir parecer o de salvar em qualquer lugar.
• Elementos interativos possuem um estado de foco visível, e esse estado é o mesmo em todo lugar. Falha em qualquer anel de foco ausente ou divergente.
• Estados desabilitados são visualmente distintos de conteúdos suavizados (muted). Falha se o usuário não conseguir distinguir um controle indisponível de um texto com menos ênfase.

• Estados vazios (empty states) usam o mesmo tratamento em todo o produto. Falha se houver uma ilustração em um lugar e apenas uma frase em outro.
• O carregamento (loading) usa um único mecanismo. Falha se houver um skeleton, um spinner e um flash em branco em três telas diferentes.
• Erros aparecem no mesmo lugar e com o mesmo tratamento. Falha se for inline em um lugar e toast em outro.
• O texto de erro diz o que deu errado e o que fazer. Falha em qualquer mensagem que apenas peça desculpas.
• Conteúdos longos são truncados da mesma forma em todo lugar. Falha se em um lugar o texto quebrar a linha e em outro houver reticências sem uma regra definida.

• O mesmo conceito tem um único nome em todo lugar. Falha se a interface disser "projeto" em um lugar e "workspace" em outro para a mesma coisa.
• Botões nomeiam a ação que executam, e a confirmação ecoa essa ação. Falha em "Enviar" seguido de "Suas alterações foram salvas".
• A capitalização segue uma única regra para rótulos, cabeçalhos e botões. Falha em misturar title case e sentence case.
• Datas, horas e números usam um único formato. Falha se houver dois formatos de data em um único produto.

O primeiro item desse grupo causa mais confusão real ao usuário do que qualquer inconsistência visual citada neste artigo. Dois nomes para um único conceito significam que o usuário mantém dois modelos mentais e não consegue saber se são a mesma coisa.

Uma vez por trimestre, audite o sistema em vez da interface. A questão não é se as pessoas seguiram as regras, mas se as regras podiam ser seguidas.

A primeira linha é a que deve ser verificada com mais rigor, pois uma regra com ressalvas parece ser uma regra detalhada. Se a sua orientação contém ressalvas, as superfícies que essas ressalvas descrevem precisam de documentos separados — a governança cobre a versão estrutural disso.

Duas coisas, em direções opostas, e ambas mudam a forma como você deve executar este checklist.

A verificação mecânica torna-se mais importante, pois o volume de código aumentou e a capacidade de revisão não. Um agente que produz quarenta telas entre as revisões reproduzirá qualquer inconsistência quarenta vezes antes que alguém a veja. Verificações automatizadas são a única coisa que escala nesse ritmo.

A análise comparativa também se torna mais importante, e por um motivo mais sutil. Um agente é extremamente consistente *dentro* de um arquivo e não possui memória entre sessões, portanto, seu output é um conjunto de telas internamente coerentes que diferem umas das outras. Esse é precisamente o modo de falha que a revisão por arquivo não consegue detectar.

A causa raiz geralmente está no upstream. Amostramos 299 arquivos DESIGN.md escritos para fornecer orientações de design para agentes: 86% especificam cores como hex puro sem um papel semântico, 76% não declaram nenhuma proibição de qualquer tipo, 69% não definem modo escuro, 57% não nomeiam motivos e 44% não contêm nenhum valor de tamanho concreto em lugar algum. 54% dependem de pelo menos um adjetivo vago — "clean" em 39%, "modern" em 36%.

Um arquivo como esse deixa decisões de densidade, hierarquia, elevação e empty-state sem definição, fazendo com que o modelo as crie do zero em cada tela. Descobertas de inconsistência contra essa orientação são reais, e corrigi-las tela por tela não será suficiente. Como escrever orientações que funcionem.

Se você tiver vinte minutos em vez de um dia:

1. Use o grep para buscar valores hexadecimais fora do arquivo de tokens. Cada resultado é uma inconsistência.
2. Use o grep para buscar pesos de fonte acima da sua faixa definida. Cada resultado é uma inconsistência.
3. Conte valores distintos de radius. Mais de quatro, investigue o porquê.
4. Abra três telas de uma mesma superfície. Compare densidade, hierarquia e elevação.
5. Olhe especificamente para os estados de empty, loading e error. É aqui que o problema será pior.
6. Verifique se sua orientação possui uma lista de proibição. Se não, essa é a correção que evita a próxima rodada.

Os passos um a três são automatizáveis hoje e nunca mais precisarão ser executados manualmente. Os passos quatro e cinco exigem uma pessoa e valem meia hora recorrente. O passo seis é o que decide se você fará isso novamente no próximo trimestre.