Translating a Job Story into mobile features
Reading context, motivation, outcome from a Job Story.
Decompose situation, motivation, expected outcome; map commute constraints to offline, audio, quick-scan features.
What's really being asked
The interviewer checks whether you understand the Job Story format, situation, motivation, expected outcome, and can derive technical features from context rather than guessing at a UI. It rewards reasoning that ties each feature to the commute scenario.
The full answer
Decompose the story. The situation is commuting: the user may be on a train or bus, hands possibly occupied, connectivity intermittent, attention divided, time-boxed. The motivation is catching up on industry news efficiently. The outcome is feeling informed and ready for work. Map each to features. Intermittent connectivity argues for offline caching and background prefetch so content is ready before the commute, the highest-value technical implication. Divided attention and busy hands suggest audio playback or text-to-speech and a hands-free, swipe-light flow. Time-boxing favors short, glanceable summaries and a clear read or unread state so users resume where they left off. Wanting to be informed for work suggests personalization toward their industry and a quick save-for-later to revisit at the desk. Each feature traces to a piece of the job's context, and you would validate priorities with the researcher.
The mistakes people make
Ignoring the commute context and proposing a generic news feed needing constant connectivity. Jumping straight to UI mockups without grounding in the situation. Missing the offline and audio implications of being mobile and hands-busy. Treating the Job Story like a feature spec rather than a need to interpret.
What usually comes next
Which feature would you build first and why. How would you handle the connectivity constraint technically. How does a Job Story differ from a persona-based user story.
A concrete example
From this story you prioritize offline-first: a background job prefetches and caches a personalized digest of industry articles overnight so the commuter reads on the train without signal. You add text-to-speech so they can listen hands-free, short auto-generated summaries for time-boxed scanning, and a save-for-later queue synced to read at their desk. Each maps directly to commuting, efficiency, and being informed, and you confirm the build order with the researcher and product.
Interview question
Which commute constraint in the Job Story most strongly justifies building offline caching and prefetch first?
- a.The user wants to be informed for their workday
- b.The user is reading industry news specifically
- c.The story is written in Job Story format
- d.Connectivity is intermittent on a commute, so content must be ready without a live signalCorrect
Why? this is the answer
Intermittent connectivity is the situational constraint that makes offline-first essential; the motivation and content topic shape personalization but do not by themselves demand caching.
Just read this? Test yourself on what you have been reading.
- #job-story
- #ux-research
- #mobile
- #feature-design
- #requirements
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles