How to write a one-page project brief that makes the next step clear.

1. Name a person, a situation, and a job to finish.

Write who needs help, when the difficulty occurs, and what the person is trying to accomplish. For example: a first-time volunteer needs to identify an available role before contacting the team. That sentence is more useful than we need an improved portal because it leaves room to discover whether a portal is needed at all.

GOV.UK's discovery guidance recommends understanding the problem and questioning a preselected solution before committing to build. Apply that distinction to your brief: keep the user's task on one line and your proposed response on another. Include people who may need a different format or support route. Do not define the audience only as the people most convenient for your team to recruit.

2. Put evidence, assumptions, and unknowns on separate lines.

Evidence might be a dated support request, a source-linked interview finding, or an observed difficulty with the current version. Record what the source actually supports. A request for a printable sheet supports investigating that format; it does not prove that every visitor wants print or that a sheet will improve the outcome you care about.

Write assumptions explicitly. We assume the role list can be kept current is operationally important, not embarrassing. Then assign a person to check the unknowns that could change the approach. If nobody knows who owns the information, that unanswered question may be the first piece of work. A polished brief is not permission to convert an untested assumption into a public claim.

3. Define the smallest complete promise and its boundaries.

Describe what a person will be able to do with the delivery. Then state the minimum contents or behaviour needed for that promise to be real. A role sheet might need available options, the date checked, a clear way to confirm a place, and an alternative contact method. A beautiful title without usable information is not a complete delivery.

Put exclusions beside inclusions. For this version, perhaps no accounts, automated matching, public directory of volunteers, or collection of personal stories. An exclusion should protect focus without quietly excluding people: no account needed is different from no assisted option offered. If an essential access need cannot be met, record the gap and resolve it before calling the delivery ready for those users.

4. Assign ownership, constraints, and a real handoff.

Name one person responsible for the delivery and another, if needed, who can approve its factual accuracy or operational use. State the time and resources actually available, the review date, and dependencies that could block release. Use an explicit unknown rather than inventing a budget or deadline to make the document look finished.

Agree how the delivery will stay useful after the first handoff. Who updates changed information? What happens if that person is unavailable? Where can a reader report a mistake? A brief for a small resource does not need a large governance system, but it does need someone who accepts the maintenance task. Otherwise a successful launch can become an unreliable promise a week later.

5. Read a worked example with a deliberately limited claim.

This is a hypothetical example, not a SIX33 project result. A community team wants first-time volunteers to choose a suitable role before the next session. Its evidence is a source-linked finding from a small interview round: some participants described needing extra contact to understand which roles were available. The team still does not know whether unclear wording, stale information, or another issue caused the difficulty.

The first delivery is one dated, mobile-readable and printable role list with an accurate confirmation route. Accounts and automated matching are out of scope. A named coordinator checks the information before sharing and owns updates. The release gate is that the information is checked, the contact route works, and the required formats are reviewed. Passing that gate establishes delivery readiness, not improved volunteering outcomes.

A separate pilot then observes whether people can select a suitable role and identify the next step without assistance. The brief points to that test rather than declaring a success threshold after seeing results. If people still need help, the next decision is to investigate the remaining barrier. Neither publishing a sheet nor receiving praise is counted as a life changed.

6. End with the next decision, not an endless feature list.

Distinguish a delivery check from a learning check. Delivery checks ask whether the agreed work exists and functions. Learning checks ask whether the intended person can use it or whether a proposed explanation deserves more investigation. A longer-term outcome claim needs an appropriate method and follow-up beyond either checklist.

Before beginning, ask collaborators to restate the promise and the exclusions in their own words. If they describe different projects, fix the brief first. Put a version and date on the agreed document. When new evidence changes the scope, keep the reason beside the revision rather than silently rewriting the original intention. The goal is not to freeze learning; it is to make changed decisions visible.

Keep a list of attractive extras outside the brief. Revisit them only if they serve the task and fit the next decision. You can have a large vision and still give today's work a clear edge. A brief earns its space when another person can take responsibility for a complete, useful step without needing to guess what you meant.