Story Mapping: onde colocar IA na jornada do usuário

Quase todo projeto de IA que trava começou pelo lugar errado: pela tecnologia. Alguém decide que o produto precisa de IA, e a conversa vira uma caça a lugares onde encaixar um modelo. Um resumo aqui, um chatbot ali, uma sugestão automática acolá. Seis meses depois, o produto tem cinco enfeites de IA e nenhuma jornada que ficou melhor. O Story Mapping resolve isso invertendo a ordem da pergunta.

A técnica foi formalizada por Jeff Patton, que a descreveu no livro "User Story Mapping" e a espalhou pela comunidade de produto na década passada. A ideia é simples e visual, e é justamente a simplicidade que a torna útil quando o assunto é IA.

As duas dimensões do mapa

Um backlog comum é uma lista vertical: uma pilha de itens que não conta história nenhuma. O story map tem duas dimensões, e é aí que está a mágica.

No eixo horizontal fica a espinha dorsal: as grandes atividades do usuário, na ordem em que ele as realiza. Para um app de suporte, poderia ser algo como "descobrir que tem um problema", "descrever o problema", "achar uma solução", "confirmar que resolveu". Lida da esquerda para a direita, a espinha conta a narrativa inteira do usuário, do começo ao fim.

No eixo vertical, embaixo de cada atividade, ficam as tarefas detalhadas, empilhadas por prioridade. Debaixo de "descrever o problema" moram coisas como "anexar um print", "informar o número do pedido", "escolher a categoria". As mais essenciais em cima, as opcionais mais embaixo.

Pronto o mapa, você tem a jornada inteira à vista, não uma lista sem forma. E é essa visão de conjunto que permite as duas decisões que interessam a um projeto de IA.

Primeira decisão: onde a IA muda a jornada

Com a espinha na parede, faça a pergunta certa, que não é "onde cabe IA?", e sim "em qual atividade o usuário gasta mais esforço ou trava mais?". A IA entra onde ela reduz esforço ou remove atrito de verdade, não onde é mais fácil pregá-la.

No exemplo do suporte, "descrever o problema" costuma ser o passo mais penoso: o usuário não sabe nomear o que sente, erra a categoria, esquece o dado que o atendente vai pedir. É um candidato forte para IA, um agente que faz perguntas e monta a descrição estruturada. Já "confirmar que resolveu" talvez seja um clique, e não precise de modelo nenhum. O mapa deixa isso óbvio de um jeito que uma lista de features nunca deixaria.

Essa disciplina conversa com o que já tratamos em Jobs to Be Done: você não coloca IA numa tela, coloca numa tarefa que o usuário está tentando cumprir. O story map é o mapa onde essas tarefas aparecem em sequência, com o esforço de cada uma visível.

Segunda decisão: onde a IA não deve entrar

O mapa também é honesto sobre o contrário. Nem toda atividade quer um modelo probabilístico. Passos com baixa tolerância a erro, ou com alta exigência de auditoria e previsibilidade, pedem regra determinística, não IA.

Cálculo de imposto, aplicação de desconto, verificação de permissão: nesses pontos, o usuário e o negócio querem a mesma resposta sempre, e uma resposta plausível mas errada é pior que nenhuma. Marcar no mapa quais atividades são "sempre igual" e quais toleram "quase sempre certo" evita o erro mais caro de projeto de IA, que é botar um modelo onde o certo era um if. É a lógica de escolher o método pelo tipo de problema, aplicada passo a passo na jornada.

O corte que salva o projeto: fatiar na horizontal

Aqui está a contribuição mais forte de Patton para quem opera. Com o mapa montado, a tentação é escolher uma atividade e construí-la até a perfeição antes de passar para a próxima. É o caminho da ruína: você entrega uma etapa impecável e descobre tarde que as outras não se encaixam.

O corte certo é horizontal. A primeira fatia atravessa a espinha inteira, da esquerda à direita, pegando só a tarefa mais essencial de cada atividade. É o que Patton chama de esqueleto ambulante, o walking skeleton: a versão mais magra que percorre a jornada de ponta a ponta e já funciona, mesmo que tosca. Só depois você desce pela pilha, engordando cada atividade com as tarefas de menor prioridade.

Uma fatia fina que atravessa a jornada inteira ensina mais do que uma etapa perfeita que não conversa com as outras. Em IA, isso vale dobrado: você descobre cedo se o modelo aguenta o mundo real antes de investir um trimestre nele.

Para IA, o walking skeleton tem um bônus. Ele te força a rodar o modelo contra a jornada real logo na primeira fatia, com dado de verdade, e não numa demo controlada. É a diferença entre fingir a IA antes de gastar o trimestre e descobrir na fatia fina que aquele passo, na prática, o modelo não dá conta. Melhor saber na semana um do que no mês seis.

Como rodar na prática

O ritual cabe numa tarde. Junte as pessoas que conhecem o usuário, produto, suporte, quem atende. Escrevam a espinha de atividades na parede, da esquerda para a direita, e confiram se ela conta a jornada sem buraco. Empilhem as tarefas embaixo de cada atividade. Marquem, com cor ou etiqueta, dois atributos por atividade: quanto esforço o usuário gasta ali, e quanta tolerância a erro aquele passo tem. Onde tem muito esforço e boa tolerância a erro, a IA é candidata. Onde tem baixa tolerância, regra determinística.

Depois, desenhem a primeira fatia horizontal: a linha mínima que atravessa tudo. Essa fatia é o seu primeiro entregável, e o seu primeiro eval contra o usuário real. As fatias seguintes descem pela pilha.

O resultado é o que faltava: uma ambição vaga de "colocar IA no produto" vira uma fila de fatias finas, cada uma testável, cada uma atravessando a jornada inteira. Você troca a caça a lugares onde encaixar um modelo por um mapa que mostra onde ele muda o resultado e, tão importante quanto, onde ele não deve chegar perto.

Se você quer montar o story map do seu produto e decidir onde a IA entra, onde ela fica de fora e qual é a primeira fatia, fala com a gente no WhatsApp.