The brief that specifies features before anyone has looked at the problem is the one that produces a site nobody uses. Two governments publish the alternative.
Most website briefs are a list of pages and features written before anybody has examined the problem, and they produce exactly what they describe: a site that matches the document and not the need. The alternative is not a longer brief. It is a different sequence, and two governments publish it in full, for free, with the phases named and the research cadence specified.
The UK Government Service Manual is the more useful of the two for this purpose, because it says the thing most agency proposals cannot afford to say: “You should not start building your service in discovery.”
That sentence is the whole argument. Everything below is how to act on it.
Interrogate the solution you were handed
The most valuable page in that guidance addresses the situation you are actually in, which is that somebody has already decided what to build.
The instruction. “At the start of your discovery, you might be presented with a pre-defined solution or told you’re building a specific thing. Before you start your research, you’ll need to interrogate that solution and reframe it as a problem to be solved.”
And the worked example is worth quoting in full. “For example, a problem is not: ‘We need to build an interactive map to show people where our contact centres are’. It’s probably something like: ‘How can we make it easier for people to find their nearest contact centre if they need to book a face-to-face appointment?’”
Notice what changes between those two sentences. The first has one acceptable answer. The second has several, and one of them might be a phone number in the footer.
The reframing also has a negative half. “Break down assumptions and ask lots of questions. Reframing the problem also includes agreeing what is not part of the problem.” Agreeing what is out of scope is the part that saves the budget.
Why this matters commercially. A brief listing eighteen page templates commits you to eighteen page templates. A brief stating four problems commits you to solving four problems, and lets the supplier propose the cheapest way to do it.
And the service standard reinforces the point. “Focusing on the user and the problem they’re trying to solve, rather than a particular solution, often means that you learn unexpected things about their needs. The real problem might not be the one you originally thought needed solving.”
The value of a named phase model is that each phase has an exit condition, which is what a brief is actually missing.
Discovery. “Before you commit to building a service, you need to understand the problem that needs to be solved.” It ends “when you’ve decided whether or not you want to move on to alpha”, on two tests: whether “there’s a viable service you could build” and whether “it’s cost effective to pursue the problem.”
With a duration and a prohibition. “There’s no set time period for a discovery, but around 4 to 8 weeks is typical.” And: “You should not start building your service in discovery.”
Alpha. “Alpha is where you try out different solutions to the problems you learnt about during discovery.” It is not public, it “tends to last between 6 and 8 weeks”, and the expectation is blunt: “Expect to throw away any code, and lots of the ideas you test, at the end of alpha.”
Beta, in two halves. “The beta phase is where you take your best idea from alpha and start building it for real.” Private beta first, with “a limited number of people”, then public beta once “you’re confident you can run it at scale.”
Live. “The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements.” With a note most website projects never plan for: “This does not necessarily mean having an agile team on the service 100% of the time.”
And a fifth outcome that no agency proposal contains. “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do. In fact, you’ll be saving time and money that could be better spent elsewhere.”
Which is the test of whether your brief is honest. If stopping after the research phase is not a permitted outcome, the research is decoration.
The guidance gives numbers, which is unusual and useful, because the numbers are smaller than most people assume for qualitative work and much larger for quantitative.
Per round, for qualitative work. “You’ll usually need between 4 and 8 participants for each round using methods like experience mapping, contextual research, in-depth interviews or usability testing.”
And the structural advice that matters more than the number. “If you need more participants to get clear findings, do more rounds rather than one big round. That way you can adjust after each round.”
On cadence. “Aim to do at least one round of research every 2 weeks.”
On who watches. “Everyone should observe at least 2 hours of research every 6 weeks.” That is a project management instruction disguised as a research instruction, and it is the one that changes decisions.
And the contrast that stops people misusing the small number. “For methods like surveys, A/B testing and benchmarking, you will need hundreds of participants to produce clear findings.” Four to eight people finds problems. It does not measure anything.
One accessibility baseline the same guidance gives. “Bear in mind that, in the UK, 1 in 5 people report a permanent disability.” The figure is British, and it belongs in the recruitment brief rather than in a compliance appendix.
The same government publishes design principles, and several of them are better written than anything in a commercial brief. Note there are now eleven, not ten: a sustainability principle was added in April 2025.
On where to start. “Service design starts with identifying user needs. If you don’t know what the user needs are, you won’t build the right thing. Do research, analyse data, talk to users. Don’t make assumptions. Have empathy for users, and remember that what they ask for isn’t always what they need.”
On scope, and this one belongs in every brief. “We should concentrate on the irreducible core.”
On evidence. “Let data drive decision-making, not hunches or guesswork. Keep doing that after taking your service live … Analytics should be built-in, always on and easy to read.”
On effort, and it is the honest one. “Making something look simple is easy. Making something simple to use is much harder … Don’t take ‘It’s always been that way’ for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do.”
On risk. “Iteration reduces risk. It makes big failures unlikely and turns small failures into lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again.”
And on consistency, which is the principle that governs a design system. “We should use the same language and the same design patterns wherever possible … This isn’t a straitjacket or a rule book. Every circumstance is different.”
The problems, framed as questions. Three to six of them, each phrased so that more than one answer is possible. If a line names a component, rewrite it.
What is explicitly out of scope. The half of the reframing exercise everyone skips, and the one that stops the project growing.
The evidence you already hold, and its gaps. Analytics, support tickets, sales objections, search queries. Name what you do not know, because that is what the research phase is for.
A research plan with numbers. How many rounds, how many participants each, over what period, and who from your side will observe. Four to eight per round, more rounds rather than bigger ones.
Decision points, not milestones. A date at which continuing is a decision rather than a formality, with the two questions attached: is there a viable thing to build, and is it cost effective to pursue.
The constraints that are real. Technology you cannot change, legal obligations, brand assets that are fixed, integrations that must survive. These belong in the brief because they narrow the solution space legitimately.
And what you will measure afterwards. Named, with a current baseline where one exists. A brief without a baseline cannot produce a verdict later.
Take the brief you have and mark every line that names a page, a component or a feature. Rewrite each one as a question with more than one possible answer. What survives is the actual scope, and it is usually a third of the length.
Then add the two sections nobody includes: what is explicitly out of scope, and what you will measure afterwards with today’s number written down.
Put a real decision point after the research, with the two published tests attached. If your procurement process cannot accommodate stopping there, say so out loud, because it means the research is theatre and you should skip it and save the money.
And book the research sessions before the design starts. Four to eight people, a round every two weeks, with the people who will approve the work in the room for two hours of it.
Not before the problem is understood. The UK Government Service Manual states plainly: 'You should not start building your service in discovery.' A brief that fixes features first fixes them against assumptions.
How long should the research phase take?
The published guidance says there is no set period but around 4 to 8 weeks is typical, and adds that the purpose of the discovery should dictate its length.
How many people do I need for usability testing?
Between 4 and 8 participants per round for qualitative methods, with the recommendation to run more rounds rather than one large one. Surveys and A/B tests need hundreds.
Is it acceptable to stop a project after the research phase?
The guidance says so directly: 'It's not a failure to stop at the end of the discovery phase if your research shows that's the best thing to do.'