How to brief a web partner in one page
A good brief is short, specific and written before the first call. The nine headings that fit on one page and produce comparable proposals instead of guesswork.
The short answer
A good brief fits on one page, is written before the first call, and describes the problem rather than the solution. It lets every partner you approach propose against the same facts, which makes proposals comparable, and it starts the first conversation at the real questions instead of the basics. Nine headings do the job. Skipping the brief means three exploratory calls and receive three proposals for three different projects.
The nine headings
| Heading | What to write | Example |
|---|---|---|
| 1. Who you are | Two sentences: what the business does, for whom, how big | Physiotherapy practice, three locations, twelve staff |
| 2. The problem | What is not working or missing, in business terms | Patients call to book; the phone is busy; we lose them to competitors with online booking |
| 3. The users | Who will use the result, and on what device | Patients aged 30 to 70, mostly on phones; front desk staff on desktop |
| 4. Success | How you will know it worked, measurably where possible | Half of bookings online within six months; fewer missed calls |
| 5. What exists | Current site, systems, content, accounts, what must be kept | WordPress site from 2019; practice software with an API; logo and photos exist |
| 6. Must be included | Pages, functions, integrations, by name | Online booking connected to the practice software; per-location pages; contact forms |
| 7. Out of scope | What you are not asking for now | Patient portal; app; rebrand |
| 8. Constraints | Legal, accessibility, language, brand, technical | Dutch and English; accessibility to WCAG 2.2 AA; health data stays in the EU |
| 9. Timing and budget range | When it must exist and the range you have in mind | Live before the autumn; range stated |
Writing it well
- Start with the problem, not the website. If the sentence begins with “we need a new website”, ask why, and write that instead.
- Name the users and their devices. Half of every design decision follows from it.
- Make success measurable where you can. A number, a behaviour, a cost that goes down.
- List what exists honestly, including the content that does not yet exist. Missing content is the most common cause of delay.
- Put the out-of-scope list in writing. It prevents the proposals from expanding to fill the budget.
- State the range. It sizes the answer.
What happens next
Send the same brief to two or three partners. Expect questions back; the quality of the questions tells you a lot. Ask for proposals structured under the same headings as the brief, plus the sections a good proposal always has: scope out, ownership, after launch. Then compare on the same page.
What this means for you
One page, nine headings, written before the first call. It costs an hour and saves weeks of exploratory conversations and incomparable proposals. Describe the problem and the outcome, list what exists and what is out, state the constraints and the range. The partners worth hiring will thank you for it, and their proposals will show you which ones they are.
Frequently asked questions
Why should we state a budget range? Will they not just quote the top of it?
A serious partner uses the range to propose the right size of solution, not to fill it. Without a range, you get three proposals for three different projects and cannot compare them. If you fear padding, ask each partner what they would leave out at the bottom of the range and add at the top.
We do not know what we need technically. Can we still write a brief?
That is exactly when a brief is most useful. Describe the problem, the users and what success looks like, and leave the technical answer to the proposals. A brief that specifies technology you do not understand constrains the answer for no reason.
How detailed should the list of what must be included be?
Specific enough to compare proposals, short enough to fit the page. Pages and functions by name, integrations by system, content by who supplies it. Detail beyond that belongs in the discovery phase, not the brief.