A maioria dos processos de design de serviço é construída em torno da jornada ideal: o usuário motivado, informado, com os dados corretos em mãos, seguindo o caminho que o time de projeto imaginou. Esse recorte é útil para organizar o raciocínio, mas produz um ponto cego sistemático. Ele descreve como o serviço deveria funcionar, não como ele de fato vai ser usado por quem não se encaixa no perfil previsto.
O problema da jornada feliz
Uma “jornada feliz” (happy path) é uma simplificação necessária no início do projeto. O risco aparece quando ela se torna a única referência de qualidade do serviço. Times de design costumam tratar desvios da jornada feliz como falhas de adoção do usuário, quando na verdade são falhas de cobertura do próprio modelo.
Isso tem um custo concreto: cada situação não prevista vira um ticket de suporte, uma reclamação, uma exceção manual resolvida por um atendente que “sabe como funciona de verdade”. O conhecimento sobre como o serviço realmente se comporta nas bordas migra para pessoas individuais, e não para o desenho do serviço.
O que são anti-jornadas
Anti-jornadas são os caminhos que o usuário percorre quando algo no serviço não corresponde à premissa de projeto: dados incompletos, contexto atípico, motivação diferente da esperada, ou uma combinação de decisões corretas em cada etapa que, somadas, levam a um resultado ruim.
Elas não são o oposto da jornada feliz (isso seria apenas “erro”). São jornadas plausíveis, muitas vezes frequentes, que o modelo de projeto não contemplou como caso central. Uma anti-jornada pode envolver:
-
um usuário legítimo tratado como fraude por um padrão de comportamento incomum;
-
um processo que assume sequência linear, mas é acessado fora de ordem (por indicação, engano ou necessidade real);
-
uma exceção regulatória, contratual ou geográfica que não foi parametrizada;
-
um usuário que depende de terceiros (procurador, cuidador, tradutor) para completar etapas pensadas para execução individual.
Por que edge cases são sinal, não ruído
Tratar edge case como exceção estatística é um erro de escala. Em serviços com volume relevante, uma anti-jornada que afeta 2% dos casos ainda representa milhares de pessoas, e frequentemente concentra os usuários mais vulneráveis, mais urgentes ou mais lucrativos a longo prazo (o cliente que está justamente em uma situação atípica de vida costuma ser o que mais precisa do serviço funcionando bem).
Além disso, anti-jornadas tendem a se repetir com padrão. O que parece um caso isolado na primeira ocorrência, na quinta vira um sintoma de que a arquitetura do serviço presume um contexto que não é universal.
Como mapear anti-jornadas na prática
Mapear anti-jornadas exige um método diferente do usado para a jornada principal, porque a fonte de informação não está nos dados de sucesso.
1. Parta dos pontos de fricção operacional. Tickets de suporte, exceções manuais, reclamações e cancelamentos são a matéria-prima primária. Eles indicam onde o modelo de serviço já está sendo contradito pela realidade.
2. Entreviste quem resolve o problema, não só quem tem o problema. Atendentes, analistas de backoffice e equipes jurídicas acumulam conhecimento tácito sobre exceções que nunca chega ao time de design, porque nunca foi formalmente registrado.
3. Desenhe a anti-jornada com a mesma disciplina da jornada principal. Etapas, decisões, atores envolvidos, tempo gasto, emoção. Tratar a anti-jornada como anotação lateral, em vez de artefato completo, é o que a mantém invisível no roadmap.
4. Classifique por causa, não por sintoma. Duas anti-jornadas podem parecer parecidas na superfície (ambas terminam em reclamação) e terem origens completamente diferentes (uma é falha de dado, outra é falha de premissa de elegibilidade). Agrupar por sintoma leva a soluções que tratam o efeito errado.
Integrando anti-jornadas ao processo, não como anexo
O erro mais comum é documentar anti-jornadas em um apêndice do relatório de pesquisa, sem conectá-las às decisões de arquitetura do serviço. Para que tenham efeito, elas precisam entrar no mesmo blueprint de serviço da jornada principal, com donos, pontos de contato e responsabilidade operacional definidos.
Isso implica decisões de priorização explícitas: nem toda anti-jornada compensa ser resolvida de forma automatizada. Algumas devem permanecer como exceção tratada manualmente, desde que essa decisão seja consciente (com processo, treinamento e SLA definidos) e não um vazio de responsabilidade.
O risco de ignorar
Ignorar anti-jornadas não elimina o problema, apenas transfere o custo. Ele migra para o time de atendimento (sobrecarga operacional), para o usuário (frustração e possível abandono) e, em serviços regulados, para o risco legal e reputacional (tratamento desigual de casos que deveriam ter cobertura prevista).
Um serviço que só funciona bem no caminho ideal não está pronto: está testado apenas para a parte mais fácil do problema.
Saiba mais:
Dia 20 de outubro de 2026 começa o curso onde eu mostro como incluir anti-jornadas num projeto de design de produto digital. Você pode assistir a primeira aula gratuitamente preenchendo esse formulário: https://cursoservdes.vercel.app/aula-gratis.html