What we changed
We switched from user stories to job stories to capture and represent the user needs identified through our research.
Why we changed it
Initially, we used user stories to define user needs. These followed the conventional format:
As a [persona], I want to [action], so that I can [goal].
However, we found that user stories were too focused on predefined personas rather than the contextual motivations behind user behavior.
Through our research, we observed that users’ needs were often driven by situational factors rather than static roles. This insight led us to explore job stories as an alternative approach.
Job stories follow this format:
When [situation], I want to [motivation], so that I can [expected outcome].
This shift allowed us to better account for the varying contexts in which users interacted with our service.
What we learned
Insights from our research
During our first two rounds of user research, we conducted:
- card sorting exercises to understand how users categorised information
- task-based interviews where participants described their workflows
- scenario-based discussions to observe real-world decision-making processes
From these sessions, we identified that users’ needs were highly situational and dependent on changing constraints, such as:
- access to funding data at different reporting levels
- varying pressures from financial deadlines
- differences in funding policies across schools and local authorities
User stories did not capture these shifting contexts effectively, as they assumed static personas rather than adapting to the fluid nature of user needs.
Applying the rationale for job stories
The decision to adopt job stories was influenced by the following key factors:
- context matters more than persona – user stories center around a persona, but our research showed that the same person may have different needs depending on the situation they were in
- motivation is key – job stories emphasise the underlying reason for a user’s action, helping us clarify real needs rather than assumed ones
- clarity and flexibility – job stories allowed us to design for varying user scenarios and not limit ourselves to rigid assumptions about users
How this changed our design process
- refining problem statements - we used job stories to frame user needs before ideating solutions. This helped prevent assumptions about personas and instead focused on understanding motivations
- “How might we” statements - the job stories were transformed into "How might we" propositions, guiding ideation and ensuring we were solving the right problems
- prioritisation through decision matrices - the highest-impact job stories were prioritised using a decision matrix, helping us select which ideas moved forward
- prototyping with real scenarios - job stories allowed us to design prototypes that reflected the actual context in which users performed their tasks, keeping research insights relevant throughout the design lifecycle
Next steps
The adoption of job stories has improved how we document and act upon user needs. Moving forward, we plan to:
- continue refining our job story library to ensure it reflects emerging user behaviors
- test our job story-driven prototypes in upcoming research rounds.
- evaluate whether job stories effectively inform iteration decisions over time
This shift has reinforced the importance of designing for context rather than personas, ensuring that our solutions are adaptable to real-world user needs.