Um componente de tabela padronizado atravessa o produto inteiro sem fricção até encontrar uma tela onde a tarefa do usuário exige comparação em vez de listagem. A tabela continua funcional, com tokens corretos e densidade conforme a regra do sistema, ainda que a conversão daquela tela caia. A equipe de design insiste que o padrão deve ser mantido pra preservar a consistência, enquanto a de produto observa o abandono subir. Pra mim, esse descompasso é o sintoma inicial de um problema mais profundo em quase todo design system que atinge maturidade: a consistência deixou de ser um meio e virou o próprio objetivo.
O argumento pela consistência é conhecido e legítimo. Um sistema previsível reduz carga cognitiva: à medida que o usuário internaliza os padrões, o aprendizado se acelera e os erros de interação diminuem, sustentando a percepção de qualidade em jornadas longas. É por isso que design systems existem, e é por isso que o post anterior desta série tratou deles como investimento de engenharia e não como capricho. O problema começa quando a previsibilidade do sistema entra em conflito com a previsibilidade da tarefa. Usuários executam intenções em contextos específicos, com restrições próprias de tempo, atenção, risco e objetivo. Quando o componente padrão não foi desenhado pra aquele contexto, aplicá-lo por obrigação de consistência transfere o custo da decisão pra cima do usuário.
Na minha análise, a consistência relevante em UX opera em camadas. A consistência interna mantém o mesmo componente com o mesmo comportamento em situações equivalentes, e é a que o design system protege diretamente. Sobre ela se apoia a consistência externa, que alinha o produto a convenções de plataforma e mercado e torna produtos novos imediatamente operáveis. Quando essas duas funcionam, ganha destaque o que Jakob Nielsen descreve como consistência funcional, a correspondência entre o componente e a tarefa que ele serve, e é justamente essa camada que a governança rígida sacrifica primeiro. As duas primeiras são mensuráveis em auditoria. A terceira só aparece quando a métrica de negócio começa a degradar numa tela específica e a equipe resiste a modificá-la porque o componente está correto segundo o catálogo.
A degradação tem mecanismo conhecido. Componentes de design system são otimizados para o caso de uso mais frequente do portfólio e representam uma média ponderada de cenários e não uma solução ótima para nenhum caso individual. Um date picker calibrado para agendamento eventual falha numa tela de reserva onde o usuário compara disponibilidade em múltiplas datas, e o mesmo padrão reaparece num modal pensado pra ações destrutivas infrequentes quando acaba aplicado a uma operação reversível de alta frequência, ou num formulário com validação on-blur que funciona em cadastros curtos e acumula erros em fluxos longos. O componente não está errado no catálogo. Está errado naquele contexto.
Um caso recente ilustra o padrão. Uma plataforma de seguros adotou o mesmo componente de seleção de produto em toda a jornada, do comparador ao checkout. No comparador, o usuário avaliava quatro planos em paralelo, com diferenças sutis de cobertura e preço. O padrão exibia cada plano num card vertical, coerente com o resto do sistema, mas o usuário era forçado a ler em sequência e memorizar valores pra comparar. A solução foi criar uma variante de comparação, com densidade aumentada, alinhamento horizontal de atributos e destaque das colunas diferenciais. Ela entrou no design system como componente especializado, e a taxa de seleção subiu em torno de um quinto nas semanas seguintes. A consistência de layout foi deliberadamente quebrada porque a tarefa era comparar, e o padrão estava desenhado pra listar.
O trade-off é direto. Variantes contextuais ampliam o catálogo e elevam o custo de manutenção, com governança mais sofisticada pra evitar proliferação descontrolada e o risco de fragmentação ao longo do tempo. A consistência estrita simplifica a governança e reduz o custo marginal de cada nova tela, mas joga pra cima do usuário o custo de adaptar a tarefa ao componente. Na minha avaliação, a decisão entre os dois lados é calibração contínua e não escolha binária, e depende da frequência e do valor da tarefa: contextos de alto volume ou alto impacto de conversão justificam variantes especializadas, contextos raros e de baixo risco devem aceitar o padrão mesmo com fricção marginal.
O que diferencia um design system saudável de um tirânico é a forma como as exceções são tratadas. No tirânico, a exceção é negociada como favor, documentada como dívida e eventualmente removida em nome da consistência. No saudável, ela é observada e medida, e quando justificada vira variante contextual formal com critérios de uso explícitos. A governança passa a se parecer com curadoria de API: o catálogo cresce, mas cada adição tem contrato claro, contexto de aplicação e métrica de justificativa. Isso exige que o time de design system converse com métricas de produto continuamente e trate os designers de feature como clientes do sistema e não como executores dele.
A medida real da consistência está na previsibilidade que o usuário extrai da interface ao longo de tarefas reais. Um sistema que entrega previsibilidade de comportamento, de token e de linguagem visual, mas admite variação deliberada de layout e densidade conforme o contexto, preserva o valor original da consistência sem impor seu custo oculto. Pra mim, é aí que a régua se inverte: quando a regra do sistema compete com a tarefa que ele deveria servir, é a regra que precisa ceder.