Prototypes as Decision Tools
Traditional approach: Write 20-page spec, debate for weeks, build, discover issues in production.
Rationale approach: Build Prototype 1 in 2 days, put in user hands, get answer.
EXAMPLE: ZERO PROTOTYPE 3
Tested swipe direction. 73% of users expected opposite of our hypothesis.
We pivoted immediately—before writing any production code. Cost: 2 days. Savings: 2 weeks of rework.
A Systematic Prototype Approach
This is a guideline, not a prescription. Some projects need 3 prototypes. Some need 12. What matters is the systematic approach: identify assumptions, build minimal tests, validate or pivot before committing to production.
The framework below shows a typical progression. Think of it as a checklist of decision points, not a rigid sequence.
Core Interaction Model
Test fundamental user interactions and navigation patterns
Information Architecture
Validate content structure and data hierarchy
Edge Cases & Error States
Test failure modes and boundary conditions
Polish & Microinteractions
Refine timing, transitions, and feedback loops
Each prototype has success criteria. Pass → Next prototype. Fail → Pivot or kill.
Zero used this approach to go from concept to production-ready architecture in 2 weeks.
Why This Saves Time
Counterintuitive: "7 prototypes sounds slow."
Reality: Prototype 1 takes 2 days. Finding the same issue in production takes 2 weeks to fix.
PROTOTYPES
Low-fidelity
High-speed iteration
PRODUCTION
High-fidelity
Low-speed rework
We de-risk the high-speed phase so production is single-pass, not iterative guessing.
ZERO'S RESULT
0 architectural pivots during production because we validated with 7 prototypes first.