Project briefs
Write acceptance checks before handing off a brief
Turn each promise in a brief into a check with a starting state, an action and an observable result, and keep it apart from implementation instructions.
'The export should be fast and easy to use.' Two people can agree with that sentence, finish the work, and still disagree about whether it was met. An acceptance check closes that gap before handoff. It says what someone will be able to observe when the promise holds.
This guide converts promises into checks and separates them from instructions about how to build. It ends with three fictional examples and their counterexamples.
Pull out every promise
Read the brief and underline each sentence that commits the work to doing something for someone. Background, motivation and scope lines are not promises. Every promise gets at least one check. If a promise has no possible check, the promise itself is probably unclear.
Use given, action and result if it helps
One optional convention has three parts: given a starting state, when someone takes an action, then a result anyone can observe. Other formats work if they carry the same three pieces. Observable means a reviewer can confirm the result from the product or its output without asking the builder what they intended.
Keep checks apart from instructions
An acceptance check states what must be true. An implementation instruction states how to make it true. A quick test: if the team met the check by a different method, would you still accept the work? If yes, it is a check. If the sentence breaks when the method changes, it is an instruction.
Instructions are not banned. Genuine constraints, such as a required platform, can sit in their own labeled part of the brief. Mixing them into checks hides the outcome and blocks better solutions.
Three fictional examples
None of these comes from a real project or was approved by a client. Each counterexample fails for a stated reason: the first and third are judgments, and the second is an instruction.
| Promise | Counterexample | Acceptance check |
|---|---|---|
| Library members can renew a loan | Renewal should feel intuitive | Given a member with one loan due in three days and no holds on the title, when they choose Renew on that loan, then it shows a later due date and the old date no longer appears |
| Bakery orders placed after the cutoff are not taken for tomorrow | Disable the date picker with a script after 2 pm | Given the 14:00 cutoff has passed, when a customer chooses tomorrow for pickup, then the order cannot be submitted for that date and the page names the earliest available date |
| Unsubscribing stops the newsletter | Unsubscribe should work properly | Given a reader who used the unsubscribe link, when the next issue is sent, then that address is not on the send list |
Review the checks with the receiver
Before handoff, ask the person receiving the brief to say how they would show each check passing. If they cannot, rewrite the check. Record disagreements as open questions instead of settling them silently.
Reuse these questions for every brief:
Does each promise have a check?
Does each check name a state, an action and a result?
Could a reviewer observe the result without help?
Does any check dictate the method?
Is every open question written down?
Know what checks do not cover
A passing set shows that the listed promises hold, not that the work is good. Qualities such as tone resist simple checks and may need a reviewed sample instead. Dozens of checks drift into a specification. Checks also do not replace edge-case review or conversation.