When a role does not explain an action
A job story connects a person's situation, motivation and desired outcome.
Two people with the same job title may behave differently because their circumstances differ. One calmly chooses a class a month ahead; another is stuck in traffic and trying to change a booking an hour before it starts. The role's name alone does not explain which solution would help.
The job story format starts with context: “When [situation], I want [motivation or action], so I can [desired outcome].” Below is an illustrative workshop example. We do not present an invented story as an interview finding or a verified user insight.
- Situation
My plans have changed, I am already travelling and I cannot make a phone call.
- Motivation
I want to know whether I can change my booking without calling.
- Outcome
I want to keep a chance to attend and avoid losing the arrangement.
A completed example without prescribing a feature
There is no button, chatbot or account area in this story yet. The solution could be a clear email explaining the rules, a booking-change page or contact with the organiser. The story first explains why the person needed to act at all.
Writing “I want to press a reschedule button” immediately risks discussing the button's convenience without checking the central uncertainty: is a change allowed this late, and under what conditions? Sometimes it is more useful to explain a limitation honestly and offer another option than to elegantly automate an impossible promise.
A specific situation matters more than a dramatic one. You do not need to invent a biography or add unsupported emotional detail. Include the circumstances that change the choice: little time, no ability to call, unknown rules or a risk of losing the place.
Job story or user story: which should you choose?
| Format | Emphasis | Example |
|---|---|---|
| User story | Who wants a capability, and why | As a booked participant, I want to change my session so I can attend at an available time. |
| Job story | The situation in which the need arises | When my plans change just before a class, I want to understand rescheduling options so I can choose an allowed solution. |
This is not a competition between a right and a wrong template. A user story briefly describes a particular participant's need. A job story makes the circumstances and reason for choosing more explicit. Roles still matter: organisers and visitors have different permissions.
If the team already understands the situation, changing the format will not necessarily improve the work. If the same role conceals several motivations, a contextual story can reveal useful differences. Choose the format according to the question that remains unclear.
How to write a user story: a separate walkthrough of the role, need and criteria.
A hypothesis is not a research finding
Our story is still an assumption. To check it, talk to people who actually rescheduled or missed a class. Ask them to reconstruct a specific incident: what changed, where they looked for information, which options they considered and how it ended.
- What happened before you decided to change your booking?
- How did you first try to resolve the situation?
- Which information was unclear or unavailable?
- Why did the chosen option seem acceptable?
- What happened in the end, and what remained unresolved?
“Would a reschedule button be useful?” already suggests a solution and asks for an opinion about the future. An account of a real incident gives you different material: a sequence of actions and constraints. It is not absolute truth either, but it helps you check the initial hypothesis.
Keep observations, interpretations and decisions separate. “The person looked for the rules in the email” is an observation from a specific account. “Add the rules to the email” is a possible solution. Between the two, you still need to ask how often the situation occurs and whether the solution suits other participants.
From a story to possible solutions
Suppose the illustrative investigation reveals that the main difficulty is uncertainty, not rescheduling itself. The person does not know whether they will lose their payment or whom to contact. The first check can then be small: show the rules and an available contact channel in the booking confirmation.
- Information
Clear conditions and contact details in the email let the person know what is possible.
- Self-service
Change a booking without calling, when the rules and available places permit it.
- Help
Send a short request to the organiser when an individual decision is needed.
Compare options by whether they remove the obstacle, not by how impressive their technology is. Manual help may be reasonable for a rare, complex situation. For a frequent standard action, it may create a queue. Without observations, you cannot honestly name a universally best option.
Then define how to check the hypothesis. For example, in a test scenario, a participant can find the permitted options and explain the next step. This checks whether the solution is understandable; it does not yet prove that real behaviour will change after launch.
Common wording mistakes
An overly general context such as “when I use the website” adds little. A predetermined solution such as “I want a chatbot” closes off alternatives. An abstract outcome such as “so it is convenient” does not explain the uncertainty the person wants to resolve.
Improve one layer at a time. First, clarify the event that triggered the need. Then describe what the person is trying to achieve. Finally, name the observable useful outcome. The entire research process does not need to fit into one sentence; supporting detail can sit alongside it.
Where to keep the working result
In Sinqly, you can create a task called “Check the rescheduling hypothesis” and add the job story, questions about real incidents and the chosen check method to its description. Signing up is free.
How to use the story after research
Update the wording if real incidents differ from the original scenario. Do not protect a well-written sentence from the facts. You may discover a different need: a refund, the ability to transfer a place or simply confirmation that the organiser saw the message.
Keep a link to the supporting evidence and indicate your confidence. A story supported by several observations and an author's idea may look equally polished, but they carry different weight in a decision. This transparency makes a job story a working tool rather than an attractive caption for a feature already chosen.
More questions to clarify
Are job stories related to Jobs to Be Done?
Yes. The format is associated with an approach that considers the progress someone seeks when choosing a solution. A single story does not replace a full investigation.
Can you write a job story without interviews?
Yes, as a hypothesis. Clearly mark the situation as invented or assumed and check it before drawing confident conclusions.
Should you remove the user's role?
No. The role and permissions may still matter. The format simply shifts the emphasis towards situation, motivation and outcome.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Intercom: the origins of job stories
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
User stories: how to write one, with examples
The user story format, three improved examples and a workshop booking story: distinguish a need from a feature, add acceptance criteria and split work that is too large.
Project brief: what it is and how to complete one before starting work
What to include in a project brief, how to clarify vague answers and what to agree before estimating the work. A completed example for a small digital project.
User story mapping: how to build a map of user stories
A workshop example of user story mapping: the visitor's journey, action cards, a first end-to-end release and common mistakes when splitting releases.