Start with product intent
Define who needs the product, what they need to accomplish, and the evidence that would justify building it.
You are about to polish the crew-scheduler screen. Before you open Figma or code, write down what success looks like. Without that, a polished screen can look done while solving the wrong problem.
Keep the brief small enough to use while building. Record facts, assumptions, and decisions separately so your agent cannot turn a guess into a requirement.
Why this matters
Polish cannot rescue the wrong task. If a crew member still cannot find tomorrow's site or notice a change, the screen failed no matter how clean it looks.
What to understand
Write the decision before the screen: who is trying to do what, what happens today, what should improve, what constrains the solution, what is outside this version, and what needs evidence. Then separate the request from its purpose — "Add a dashboard" is a proposed interface, not a purpose. Comparing workload may need a table; noticing an urgent exception may need a short list.
Match the artifact to the cheapest open question: comprehension gets realistic labels in a flow, feasibility gets a narrow integration, trust gets offline and freshness rules, authority gets a server-checked rule.
Watch for
- Letting a guess become a requirement because facts and assumptions share one list.
- Inventing a conversion target or study result to sound rigorous.
- Building the entire product to answer one question.
- Quietly redefining success to fit what you built.
Strong default
Write a practical acceptance condition: "A crew member can find tomorrow's site and tell whether the assignment changed." Add an agreed measure only when it helps. Respect an explicit client choice, but make its cost and alternatives clear.
When this doesn't apply
A dashboard, a day view, or a week view is not the default answer. The brief above treats "whether a day view makes changes easier to notice than a week view" as an open evidence question — not a researched specification. Let the evidence pick the view.
In practice
Ask your agent: "Draft the brief from these answers, and mark what is a guess."
| Question | Useful answer |
|---|---|
| Who is trying to do what? | A crew member checks tomorrow's assigned site on a phone. |
| What happens today? | They search a group chat or ask the foreman. |
| What should improve? | They can find the current assignment and notice a change. |
| What constrains the solution? | Intermittent connectivity; the foreman controls assignments. |
| What is outside this version? | Payroll, time tracking, and location tracking. |
| What needs evidence? | Whether a day view makes changes easier to notice than a week view. |
These are illustrative answers, not a researched specification. In a real brief, cite interviews, support reports, or observed behavior when available.
Choose the next artifact with prototype fidelity. Once a preview exists, replay the original task, record what to keep, what no longer serves the purpose, and what needs further evidence. Change the brief when learning warrants it, with a reason.
Verify
Can a crew member find tomorrow's site and spot a change? Do not invent the evidence — cite interviews, support reports, or observed behavior.
Related skills
Use $intent to frame or revisit the promise, then $requirements to express testable behavior. Continue with Stakeholder communication to make the decision reviewable.
Last updated on