01 / THE BRIEF
Write a brief that can be checked
Connect a small user goal to explicit boundaries, concrete examples and a review record that preserves open questions.
A request such as “make the reading list better” leaves nearly every important choice open. One reader imagines a shorter page; another imagines an export; a third expects an account that remembers everything. All three can agree with the sentence and build different things.
A useful brief makes those differences discussable before implementation. It can fit on one page: a goal, a role, the boundaries, a few examples and the questions that still need an answer. Use the worksheet to keep those parts together.
Separate the task from its presentation
Start with the person and the task they are trying to complete. GOV.UK’s user-story guidance connects the actor, the thing they need and the reason for it. That relationship is more useful than filling a template with words that merely restate the proposed interface.
In our fictional example, a reader wants to keep a copy of a reading list that remains usable away from the page. “Add a green export button” describes one interface decision. “Keep an offline copy of the list” names the outcome that decision is supposed to serve. Put the latter in the goal field; discuss the button when choosing an implementation.
Use a role rather than a private name. “A reader preparing a personal reading list” is enough for this example. If two roles have different permissions or needs, separate their cases instead of hiding the distinction inside a general label such as user.
Write the smallest honest boundary
A brief should say what this change includes and what a reader should not infer from it. The fictional reading-list change offers a plain-text download. It does not promise synchronization, shared editing, a PDF layout or recovery after the tab closes. Those exclusions keep discussion attached to a finishable task.
Distinguish a requirement from a convenient assumption. “Up to 20 entries” is an invented working limit in this example. Until someone supplies its real reason, label it as an assumption. A number can make a sentence more testable while still being the wrong product decision.
Record the environment only when it affects the agreement. A downloaded text file should be checked in the chosen viewer; an interaction that depends on a network connection should say so. Do not list every browser version in the opening sentence if those details belong in the later test record.
Turn one promise into one example
Choose a concrete starting state. In the example, the list contains two titles in a known order. State the action: the reader saves the list and opens the downloaded file. State the expected observation: both titles appear once each, in that same order.
This case is small enough for two people to discuss. It also reveals missing decisions. Are notes included? Are line breaks preserved? What filename is acceptable? Keep unresolved answers in the questions section; do not quietly fill them in because the form has room.
If the example starts describing a second independent action, split it. Reordering a list and exporting it may deserve separate cases, with one combined case only if their interaction is an actual risk. A short brief can refer to several small cases without becoming one long script.
Preserve evidence and assumptions separately
GOV.UK’s research guidance treats suggestions that have not come from users as assumptions to investigate. Apply that distinction to the brief: a stakeholder’s preference, a documented limitation and an observed user problem are different kinds of input.
A compact evidence note can say “source: support issue category; observation: people need a local copy; unresolved: preferred format.” You do not need to place private messages, account identifiers or participant names in the brief. Link to an appropriately controlled evidence location when the team needs the details.
Our invented reading-list scenario has no research evidence. It is useful for explaining a method because the conditions are explicit. It should never be used as proof that real readers asked for this feature.
Sources: GOV.UK Service Manual: Learning about users and their needs
Review the agreement before implementation
Ask someone to describe the expected result using only the brief. If they have to guess a limit, a permission or what counts as success, add the missing decision or keep the question visibly open. Agreement on the words is not the same as evidence that the change is valuable.
Save the reviewed version and the reason for the decision. A later change to the requirement should identify which cases need another look. Leave test status blank or marked not run until a real observation exists; drafting an expected result cannot produce a passing test.
Use the Acceptance Criteria Builder to create the working copy. Continue with observable outcomes and failure and boundary cases before treating the brief as ready to build.