From Jobs to Experience: Designing Flows From What Users Are Actually Hiring You to Do

A flow should be the shortest path from a job a user is trying to get done to the outcome that job requires — not a sequence of screens borrowed from a competitor or a design system's default pattern. Start with the job statement and its desired outcomes, score those outcomes for underserved opportunity, then design the minimum interface that closes the gap. Screens are the last decision, not the first.

Quick Answer: Derive flows from jobs to be done experience design, not interface conventions. Write the job statement and outcome statements, run Ulwick-style opportunity scoring to find underserved outcomes, then sketch the minimal flow — checking it against the Forces of Progress — before touching a single screen.

Why Starting From the Screen Gets the Flow Wrong

Starting from a screen template locks in someone else's assumptions about the job before you have tested your own. A dashboard, a wizard, a feed — each implies a job, and if you inherit the pattern before naming the job, you inherit the wrong one by default.

This is the core critique behind jobs to be done (JTBD), the framework Clayton Christensen popularized and Tony Ulwick operationalized into a repeatable method. The premise: people don't buy products, they "hire" them to make progress on a job in a specific circumstance. A flow is just the mechanism of that hiring — it should be judged entirely by how well it helps the job get done, not by how closely it resembles a familiar pattern.

Design-led PMs feel this tension acutely. Craft instincts pull toward polished, convention-following interfaces; job-first thinking pulls toward whatever is structurally minimal for the outcome, even if it looks unfamiliar. That tension is explored at length in our design-pm-role complete guide, and it echoes the identity friction covered in the designer-PM hybrid identity crisis — practitioners pulled between two disciplines with different starting points.

The fix is sequencing, not abandoning craft. Name the job and its outcomes first. Score the outcomes to find what's underserved. Only then let craft decide how the minimal flow looks and feels — typography, motion, spacing all still matter, they just get applied after the shape is right.

From Job Statement to Outcome Statements

A job statement names the progress a user is trying to make, independent of any solution; outcome statements are the measurable criteria they use to judge whether they succeeded. Get both wrong and every downstream flow decision inherits the error, no matter how well it's executed visually.

Writing the Job Statement

Ulwick's format forces precision: [verb] + [object of the verb] + [contextual clarifier]. Not "manage my expenses" (too vague, too solution-agnostic in the wrong way) but something like "consolidate spending across accounts when reconciling a monthly budget." The job is stable — it rarely changes even as solutions come and go, which is precisely why it's a more durable design foundation than a feature list.

Three properties make a job statement usable for flow design:

1. It's solution-agnostic. No reference to an app, screen, or feature name.
2. It's stable over time. The job "get from home to work" hasn't changed in decades even though the products hired for it have.
3. It's circumstance-bound. "Reconcile a budget" during a busy week differs from doing it on a quiet Sunday — the circumstance shapes which outcomes matter most.

Writing Outcome Statements

Outcome statements follow a template too: [direction of improvement] + [metric] + [object] + [contextual clarifier] — for example, "minimize the time it takes to identify unexpected transactions when reconciling a monthly budget." Each job typically yields 15-40 outcome statements once decomposed across its steps (define, locate, prepare, confirm, monitor, modify, conclude — the standard JTBD process map).

Well-formed outcomes are measurable and comparison-free — they describe what "better" looks like without naming how to get there, which is what keeps them useful for opportunity scoring rather than pre-committing to a design.

This is also where customer journey thinking earns its place alongside JTBD rather than competing with it — the job tells you what progress means, the journey (detailed in our customer journey complete guide) tells you where along the timeline emotional friction concentrates. Combining both gives outcome statements more texture than either produces alone.

Scoring Outcomes to Find the Underserved Job

Opportunity scoring ranks outcome statements by importance and current satisfaction, surfacing which ones are underserved and therefore worth building for first — instead of guessing from stakeholder opinion or whichever outcome is loudest in the room. Ulwick's formula, Opportunity = Importance + max(Importance − Satisfaction, 0), rewards outcomes that are both important and poorly served.

Collect both scores directly from users, typically on a 1-10 scale, for every outcome statement in the set:

An opportunity score above roughly 12-15 on a 1-20 scale typically marks a genuinely underserved outcome worth designing around first; scores clustering near 10 signal outcomes that are already adequately served, where more effort brings diminishing return. In the table above, "identify unexpected transactions" and "confidence that all accounts are reflected" are the underserved pair — that's where the flow's first version should concentrate, not on the already-well-served due-date reminder.

What Opportunity Scoring Changes About Flow Design

Ranked outcomes reorder the flow's priority, not just its feature list — the underserved outcome should usually get the most prominent placement and the fewest steps, even if it isn't the outcome a stakeholder mentions first. This is where opportunity scoring earns its keep over intuition alone; it's a documented middle ground between pure data and pure gut feel, a tension our piece on design intuition versus data covers directly.

• High opportunity, low current satisfaction — build here first; this is the flow's reason to exist.
• High opportunity, high satisfaction — a trap; users report it matters, but a competitor or existing habit already serves it, so a new flow here fights an uphill battle.
• Low opportunity — defer; even a beautifully designed screen for this outcome won't move the needle a user actually feels.

Designing the Minimal Flow From Scored Outcomes

The minimal flow is the shortest interaction path that closes the gap on the highest-opportunity outcomes, with every screen justified by an outcome it serves rather than by convention. This reverses the usual design process, where screens get sketched first and outcomes get retrofitted as justification afterward.

A Worked Example

Take the job: "consolidate spending across accounts when reconciling a monthly budget." Two outcomes scored highest: minimizing time to identify unexpected transactions, and maximizing confidence that all accounts are reflected. A conventional finance app might default to a tabbed dashboard with account balances, a spending chart, and a settings menu — the standard template.

A job-first flow looks different:

1. Landing state surfaces the underserved outcome directly — an "unexpected transactions" list, sorted by deviation from the user's typical pattern, is the first thing shown, not a chart requiring interpretation.
2. A single connected-accounts confirmation step addresses the second outcome — a visible checklist of linked accounts with last-sync timestamps, not a settings page a user has to go find.
3. Everything else is one tap deeper. Historical comparisons, category breakdowns, and export tools — all outcomes that scored lower — sit behind a single "more" affordance rather than competing for primary screen space.

The tabbed dashboard isn't wrong on its own terms; it's just optimized for a different job (ongoing monitoring) than the one actually scored highest here (fast anomaly detection during a specific reconciliation ritual). The flow that wins is the one built for the job that was actually measured, not the one that looks most like the category norm.

Forces of Progress: What Pulls Users In and What Holds Them Back

The Forces of Progress model — drawn from the "Jobs to Be Done" work of Bob Moesta and Chris Spiek — names four forces that determine whether a user actually switches to a new way of doing a job: two pulling toward change, two holding them in place. Scoring outcomes tells you what to build; the Forces tell you whether anyone will actually adopt it once built.

A flow built purely from opportunity scores can still fail if it ignores the two resisting forces — a flawlessly designed screen for an underserved outcome will still lose to an inferior incumbent if switching feels risky or the old habit is deeply grooved. Design against all four forces deliberately, not just the two that feel like "the product's job":

• Reduce anxiety with a low-commitment first step — a preview or import, not a full account re-linking demand up front.
• Interrupt habit by placing the new flow where the old habit already happens, rather than requiring a new destination to remember.
• Make the pull visible immediately — if the underserved outcome is "identify unexpected transactions fast," show one solved instantly, on the first screen, before asking for any setup.

Grounding the Flow Before Sketching a Screen

None of this requires new tooling to practice by hand — job statements, outcome statements, and a spreadsheet for opportunity scores get most PMs most of the way there. What a dedicated tool buys is consistency across projects and less time spent rebuilding the same scoring spreadsheet from scratch each cycle.

Prodinja's Customer Jobs tool is built around exactly this sequence: it combines JTBD job and outcome statements, Ulwick-style opportunity scoring, and Forces of Progress mapping in one workspace, so a PM can ground an experience in the job before a single screen gets sketched. It's designed to make the underserved-outcome-to-minimal-flow path something you can walk through directly rather than assemble across three disconnected documents.

Whether or not you use a dedicated tool, the sequence matters more than the tool: job, outcomes, scores, forces, then — and only then — screens. Teams that skip straight to wireframes are usually skipping the part of the process that tells them which wireframe is worth drawing. For a broader look at how design-minded PMs structure their day-to-day decisions, see our design-pm-role complete guide, and for the craft-versus-speed tension that often surfaces once a minimal flow is proposed, see defending craft against velocity.

Key Takeaways

• Jobs, not screens, are the starting point — a job statement is solution-agnostic and stable, which makes it a more durable foundation for flow design than any interface convention.
• Outcome statements make progress measurable — well-formed outcomes name direction and metric without naming a solution, which is what makes them scoreable.
• Opportunity scoring finds where to build first — Ulwick's formula (Importance + max(Importance − Satisfaction, 0)) surfaces underserved outcomes objectively rather than by stakeholder volume.
• The minimal flow is justified outcome by outcome — every screen should trace back to a specific scored outcome, with lower-scored outcomes pushed deeper into the interaction, not onto the primary screen.
• Forces of Progress determines adoption, not just design quality — push and pull drive a user toward a new flow, while anxiety and habit hold them back; a well-scored flow can still fail without addressing all four.
• Tools like Prodinja's Customer Jobs can consolidate the sequence, but the discipline — job, outcomes, scores, forces, then screens — is what actually produces the minimal flow, tool or no tool.