Write a brief that makes a usable digital service possible

Why a short, testable brief matters

A brief is not a contract specification, it’s a decision filter. A short, testable brief helps everyone (you, your designer, your developer) choose what to build first and what to defer. Official UK guidance for public services emphasises writing focused briefs for procurement and audits, and asks teams to identify the user journeys, page types and components that matter most for evaluation. Use this guidance to avoid long, ambiguous lists of ‘features’ and instead state which tasks users must complete. (See sources 1 and 2.) 1 2

Focus on tasks and journeys, not features

Turn abstract goals into specific user tasks: what must the person do on a critical visit? For example: “Find eligibility information and submit an application” is clearer than “improve sign‑up”. The GOV.UK service manual recommends listing the user journeys, tasks and patterns you want assessed when you commission audits or suppliers, that same approach keeps your brief actionable. List 3, 5 priority journeys and the success condition for each (what counts as ‘done’ for that journey). (See source 1.) 1

Make accessibility and standards explicit

Make accessibility and standards non‑negotiable in the brief. Government guidance requires tests against Web Content Accessibility Guidelines (WCAG) and suggests sampling representative page templates for audits. If your business values inclusivity (and legal compliance), specify which WCAG level you expect, which templates you’ll include in testing, and whether you expect assistive‑technology testing. Citing standards and sample pages in the brief gives suppliers a clear scope for estimates and reduces later rework. (See sources 1 and 3.) 1 3

Plan for iterative delivery and measurable validation

Ask for the smallest deliverable that validates a hypothesis, not the ‘complete’ product. The government procurement framework and service design guidance favour agile delivery and emphasise starting with user needs and iterating. Translate your top hypothesis into a testable output: a prototype, a working form, or a public beta page. Define the metrics you’ll use (task completion rate, number of errors, support queries) and how you’ll collect them (usability tests, analytics, support logs). That keeps decisions evidence‑led, not opinion‑led. (See source 2.) 2

Concrete steps to write the brief

1) One‑page purpose: Write a one‑paragraph summary (30, 70 words) that explains the user, the top task and the success condition. 2) Priority journeys: List 3 priority user journeys and what success looks like for each. 3) Constraints and standards: State required standards (WCAG level, browsers, integrations) and any constraints (budget band, timeline). 4) What to deliver first: Specify the smallest deliverable that will answer the riskiest question. 5) Acceptance & validation: Describe how you’ll validate the deliverable (basic usability test plan, metrics). 6) Communication: Say who the decision‑makers are and how clarifications will be handled. These short, concrete blocks make the brief quick to read and easy for suppliers to price and respond to. (See sources 1 and 2.) 1 2

Try this small task

Task (30, 60 minutes): Pick a real page on your website. Write the brief’s one‑page purpose and list one priority journey for that page (user, task, success condition). Share it with a colleague and ask: if we built only that journey, would it change what users do? Use the answer to decide whether the journey is truly a priority. This quick exercise exposes assumptions and gives you something testable to show a supplier or designer. 2

Closing note, what this guidance is and isn’t

Suggestions above are practical steps derived from official public guidance and service design practice; they are not legal or procurement advice for every situation. The GOV.UK material shows how public teams write briefs and require accessibility testing; W3C and service design references show why standards matter when planning what to test. Use the steps as a checklist to tighten your brief before you commission design, development or an accessibility audit. (See sources 1 and 3.) 1 3

Sources

Checked 2026-10-19.

• Getting an accessibility audit, Service Manual, GOV.UK
• Digital Outcomes and Specialists framework agreement, GOV.UK (framework guidance on writing a brief)
• Krems/Scribe, Share-PSI EC Project (W3C)