happy-path-scope

What problem does it solve?

You are helping the user scope a prototype to the minimum needed for its purpose. Prototypes fail most often because they're over-scoped — too many screens, too many states, too much detail — which makes them slow to build, hard to iterate, and confusing to test.

Framework: Colin Matthews (prototype scope discipline), Shape Up (appetite-based scoping applied to prototypes).

Key principle: A prototype should contain only what's needed to answer the question it's designed to answer. Every screen and state beyond that is waste.

Core Features & Use Cases

The happy path is the sequence of steps where:

• The user knows exactly what to do
• Every input is valid
• Every system response succeeds
• The user achieves their goal

Map the happy path for the feature being prototyped:

1. [Step 1] — [User action]
2. [Step 2] — [System response]
3. [Step 3] — [User action] ... N. [Outcome] — [User has achieved their goal]

This becomes the spine of the prototype. Everything else is a branch — don't prototype branches.

Step 3 — Cut List

For each of the following, decide: In prototype or Out of prototype

| Element | Include? | Why | |---|---|---| | Auth / login flow | OUT | Start logged in. Auth is a solved problem. | | Empty states | OUT | Use mock data instead. | | Error messages / validation | OUT | Happy path only. | | Loading states | OUT | Mock instant load. | | Settings / configuration | OUT | Not in the happy path. | | Admin / internal views | OUT | Not the user's journey. | | Mobile responsive | OUT | Unless this IS a mobile test. | | [Feature-specific element] | [In/Out] | [Reason] |

Step 4 — Minimum Screen Count

Force a minimum screen count:

For user testing: You need at least 3 screens (start state, mid-flow, success state). You rarely need more than 7.

For stakeholder demo: You need the "before" (the problem state) and the "after" (the solution working). 2–4 screens is typical.

For engineering spec: You need every unique interaction state. Count the number of distinct interactions, not screens.

If the prototype has more than 8 screens, scope it down until it fits. Prototype one flow completely rather than two flows partially.

Step 5 — Mock Data Requirements

Define the mock data needed to make the prototype feel real:

• How many items in each list? (3–5 is almost always enough)
• What are the realistic values? (Use real names, real product language, real numbers)
• What's the "interesting" example? (The one that best illustrates the feature's value)

Step 6 — Output

Produce:

• Happy path definition (numbered steps)
• Screen list (only what's in scope)
• Cut list (what's excluded and why)
• Mock data requirements
• Prototype scope statement: "This prototype shows [user type] doing [action] to achieve [goal]. It does NOT show [list of exclusions]."

This scope statement should be shared whenever the prototype is shared, to prevent misunderstanding about what's implemented.

Quick Start

Provide a prototype scope by outlining the purpose, happy path, cut list, screens, mock data, and a formal scope statement.