Discover
Map the people, problem, constraints, and evidence before proposing a solution.
Who decides, who uses the system day to day, and who pays if it fails.
Process
The method is lightweight enough for a small team and rigorous enough for a product people depend on. Each phase leaves a concrete artifact behind, not just a conversation.
Map the people, problem, constraints, and evidence before proposing a solution.
Who decides, who uses the system day to day, and who pays if it fails.
Shape the content and interface around the decisions users actually need to make.
The system's boundaries and the contracts between its parts, before the first screen gets built.
Deliver a vertical slice, keep the architecture legible, and use automation where it earns its place.
A thin, complete cut of the product — interface to data — working end to end before the rest gets built out.
Review behavior, keyboard access, performance, security, and maintainability before calling it done.
What can fail, how bad it would be, and what automated or manual test covers it.
Document the reasoning so the product can keep moving after handoff.
Why each decision was made, so the work can continue without depending on me to explain it in person.
The standard