What decision should the tool help someone make?
Define the decision before the interface. ‘Build a dashboard’ describes a format; ‘show an owner which leads need a response today’ describes the useful outcome.
- Name the audience.
- Describe the moment they arrive.
- Name the decision.
- Name the next honest action.
Rewrite your product idea without naming a screen, app, dashboard, or AI model.
Which states make the product real?
A product is the whole set of situations around the ideal screen. Empty, loading, error, success, permission, correction, and small-screen states belong in the brief before polish.
- Inventory normal and failure states.
- Define permissions.
- Write recovery copy.
- Test the smallest viewport.
Sketch the path when the main data source is empty, late, or wrong.
How will you prove the build works?
Tie verification to the original decision. Use an observable user path, accurate import, clean handoff, keyboard flow, or business response instead of treating a passing build as sufficient proof.
- Write the success condition.
- Write a failure condition.
- Choose a repeatable test.
- Record who signs off.
Create a five-line acceptance checklist another person could run without you.