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:
- [Step 1] — [User action]
- [Step 2] — [System response]
- [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.
