Visão geral
Job Stories é uma técnica de ideação usada para descrever requisitos de produto conectados a situações reais e motivações de usuário — não a personas fictícias — garantindo que a solução resolve o contexto específico que gera o comportamento, não um perfil demográfico. A utilidade dela está menos no ritual em si e mais na forma como ajuda o time a transformar uma dúvida de projeto em evidências, decisões ou próximos passos observáveis.
Ela faz sentido quando use após pesquisa qualitativa quando o time precisa traduzir achados em requisitos, ao refinar backlog com base em JTBD ou quando User Stories tradicionais estão centradas demais em funcionalidade e pouco em contexto. Ao aplicar Job Stories, o time deve chegar a conjunto de Job Stories por segmento ou situação, Base para critério de aceitação de soluções e Insumo para priorização de backlog, mantendo rastreabilidade entre o que foi observado, o que foi decidido e quais limites ainda precisam ser considerados.
Como entra no fluxo
Job Stories entra quando já existe uma pergunta de trabalho clara e o time precisa conduzir uma atividade estruturada antes de avançar para decisão, protótipo, priorização ou entrega.
Atenção ao usar
Sem pesquisa de base, as histórias refletem suposição interna, não realidade.
Combina bem com
- Jobs To Be Done
- User Story Mapping
- User Interviews
Para que serve
Descrever requisitos de produto conectados a situações reais e motivações de usuário — não a personas fictícias — garantindo que a solução resolve o contexto específico que gera o comportamento, não um perfil demográfico.
Quando usar
Use após pesquisa qualitativa quando o time precisa traduzir achados em requisitos, ao refinar backlog com base em JTBD ou quando User Stories tradicionais estão centradas demais em funcionalidade e pouco em contexto.
Contexto
Objetivos
Outputs
Situações ideais
- equipe desalinhada
- alta incerteza
Como executar
Pré-requisitos
- Pesquisa qualitativa realizada — entrevistas, JTBD ou contextual inquiry
- Situações e motivações de usuário identificadas
Materiais
- Template de Job Story
- Dados de pesquisa e citações reais
- Ferramenta de documentação colaborativa
Passo a passo
- 1Identifique situações reais extraídas da pesquisa — contextos concretos.
- 2Para cada situação, articule a motivação subjacente do usuário.
- 3Para cada motivação, defina o resultado esperado do ponto de vista do usuário.
- 4Escreva no formato "Quando [situação], quero [motivação], para [resultado]".
- 5Valide com dados de pesquisa — cada história deve ser baseada em evidência.
- 6Priorize por frequência e importância da situação.
- 7Use como guia para ideação e critério de avaliação de soluções.
Critérios de qualidade
- A situação descreve contexto real observado em pesquisa, não hipótese
- A motivação descreve intenção do usuário, não a funcionalidade desejada
- O resultado esperado é do ponto de vista do usuário, não da empresa
- Não há menção a solução específica na história — foco no problema
Dicas
- Situação é o diferencial — "quando estou no metrô sem internet" é mais útil que "como usuário móvel".
- Evite colocar solução disfarçada de motivação.
- Uma Job Story por situação — não combine contextos diferentes.
- Valide com o próprio usuário se a história captura o que ele viveu.
Antes (entradas)
- Dados de entrevistas com usuários
- Situações e motivações identificadas em pesquisa
- Jobs to be Done mapeados
Depois (saídas)
- Conjunto de Job Stories por segmento ou situação
- Base para critério de aceitação de soluções
- Insumo para priorização de backlog
Variações
Job Story com Força de Switching
Expande a estrutura incluindo o que empurrou o usuário para a mudança (push), o que o atraiu para a solução (pull) e o que gera ansiedade e hábito — conectado ao framework de forças do JTBD.
Outcome-Oriented Job Story
Detalha múltiplos resultados esperados por situação — resultados funcionais, emocionais e sociais — para garantir que a solução atende camadas diferentes da motivação.
Uso estratégico
Quando evitar
- Não há pesquisa qualitativa para embasar as situações
- Time prefere especificação técnica detalhada em vez de narrativa orientada a contexto
- Produto tem requisitos regulatórios que precisam de linguagem formal
Limitações
- Sem pesquisa de base, as histórias refletem suposição interna, não realidade
- Pode ser difícil de usar como critério de aceitação técnica sem complemento
- Não substitui critérios de usabilidade ou performance
Riscos
- Criar situações hipotéticas sem base em comportamento observado
- Descrever solução disfarçada de motivação
- Acumular histórias sem priorização ou conexão com decisões de roadmap
Exemplos de uso
- 01Quando estou fechando o mês e tenho várias faturas para conciliar, quero ver todas pendentes em um lugar, para não perder nenhuma e evitar multa.
- 02Quando preciso compartilhar resultado de pesquisa com stakeholders, quero exportar os achados rapidamente, para economizar tempo de formatação.
- 03Quando entro no app pela primeira vez, quero entender o que ele faz em 30 segundos, para decidir se vale meu tempo.
Perfis responsáveis
Também conhecido como
Referências e leitura
Ajude a melhorar este conteúdo
Encontrou erro, lacuna técnica ou exemplo fraco? Envie uma correção com contexto para revisão.
