Start with the decision
A useful brief names the decision the product should help someone make. ‘Build a dashboard’ is a format. ‘Help an owner see which leads need a response today’ is an outcome.
Write the audience, the moment they arrive, and the next honest action in one paragraph. If that paragraph is fuzzy, the interface will be fuzzy too.
Create a truth ledger
Separate verified facts, owner-reported claims, and ideas that still need validation. This keeps confident design from turning an assumption into public proof.
- Facts with sources
- Claims with an owner
- Unknowns that stay unpublished
- Words the product must not imply
Specify states, not just screens
Describe empty, loading, error, success, permission, and small-screen states. An interface is a set of situations, not a stack of ideal screenshots.
Name the proof
Decide how you will know the build works: a user path, a measurable response, a clean import, a keyboard flow, or a specific business handoff. Verification belongs in the brief, not at the end.