How to write a website brief so the fix actually gets done

The short answer

To brief a website fix, write one change under six headings and put the test for done in writing before work starts. It matters because the common fixes are everywhere: WebAIM found 51% of the top million home pages had a form field with no label. Your developer has a queue. A brief they can act on without a meeting goes to the top of it.

What is a website brief?

A website brief is a written request that gives a developer or agency everything they need to scope, do and check a change without a meeting. A design brief describes a new site or page. A fix brief, the kind this article covers, describes one problem on an existing site and how you will know it is solved.

The difference matters for budget as well as speed. Gartner's 2026 CMO survey found 56% of CMOs say they lack the budget to deliver their strategy, with budgets flat at 7.8% of revenue. The survey covers mostly large North American and European companies, but the pressure is familiar in Australian mid-market teams too. When budget is tight, the fixes that get done are the ones that are easy to say yes to.

Why do website requests stall?

Website requests stall because the brief left the other person guessing. There are four ways it does that: it names a symptom instead of a location, prescribes a solution instead of a problem, sets no boundary, or has no agreed way to be finished. You can spot all four in your own sent items.

• The request is a symptom, not a location. "The contact page is not working" could be eleven different things in four different systems.
• The request is a solution. "Can we move the button up" skips the problem, so if moving the button does not help, nobody knows what to try next, and you have spent the budget.
• The request has no boundary. A developer who is not told what is out of scope will either do too little or quietly redesign something.
• The request has no way to be finished. With no agreed check, the task sits at 90% done forever, because "done" is a matter of opinion.

What should a website brief include?

A website brief should include six things: the evidence, exactly where, what should happen instead, what must not change, how you will both check it, and when and why then. Each heading answers a question the developer would otherwise ask you, and each answer saves a round of email.

1. The evidence

What you observed, in plain terms, with the proof attached. A screenshot, a screen recording, the URL, the device and the browser. If it happens only sometimes, say how often and under what conditions.

"On an iPhone 14 in Safari, the enquiry form on /contact submits and then shows a blank white page. Screen recording attached. Happens every time. Confirmed on two devices on 18 September."

That paragraph saves an hour of somebody trying to reproduce it. If you do not have a recording, a free session replay tool will usually have captured a real visitor hitting the same problem. Our Microsoft Clarity guide shows how to find and share one, and Hotjar alternatives covers the other options.

2. Exactly where

The full URL, and which element on it. If the same problem is on eleven pages, list them, or say what they have in common. The difference between "this page" and "every service page" is the difference between a one hour task and a one day task, and the person quoting needs to know which one they are quoting.

3. What should happen instead

Describe the outcome, not the implementation. "After submitting, the visitor should see a confirmation that their enquiry has been sent and that we reply within one business day." Let the person who knows the system choose how.

If you genuinely do have a design constraint, say so explicitly and say why, so it reads as a requirement rather than as an amateur instruction.

4. What must not change

This is the most skipped item and the most valuable one.

"Do not change the form fields, because they map to our CRM. Do not change the page address, because it is in a printed brochure. Do not touch the other service pages in this release."

Without this, careful people ask, and slow down. Careless people do not ask, and you find out later.

5. How we will both check it

Write the test before the work starts, in the plainest language you can manage. Anyone should be able to run it.

"On a phone, go to /contact, fill in the form with a test address, press Send. A confirmation message appears on the page. Within five minutes an email arrives at enquiries@. Repeat on a desktop."

If you cannot write this, the request is not ready, and that is useful to discover before anybody quotes.

6. When, and why then

A date with a reason attached is a priority. A date without one is a preference, and it will lose to the next request that has a reason.

"We need this before 12 October, because the campaign that drives most of the traffic to this page starts that week."

Which website fixes come up most often?

The fixes that come up most often are unlabelled form fields, low-contrast text, missing image descriptions, slow mobile pages and out-of-date plugins. They are common enough that most sites have at least one, which means a good brief for each is worth keeping as a reusable pattern.

On WordPress, the recurring ones are collected in common WordPress problems that quietly cost enquiries, and the WordPress audit checklist for marketing teams turns them into a list you can brief from. For forms specifically, contact form best practices gives you the "what should happen" line for most of them.

The Gartner martech figure is from 2023 and is the latest it has published. The point is not the exact number. Teams already own more capability than they use, so the bottleneck is rarely a missing tool. It is a request nobody could act on.

Why write it in the developer's units?

Developers and agencies plan in tasks, not in themes. One brief should describe one change that could be deployed on its own. Nine problems sent as nine short briefs get picked off; nine problems in one document get scheduled as a project.

The long document gets scheduled as a project, which means a quote, which means a meeting, which means November. Nine small items get picked off, and the first three are usually done in the time the meeting would have taken to arrange.

Say which order you want them in, and be prepared to have that order challenged on technical grounds. Two of your nine may share a root cause and be cheaper together, and only the developer can tell you that. If you are unsure how to order them, a CRO audit ranks problems by how close they sit to the moment someone decides to enquire.

A weak brief and a strong one

Weak. "Hi, the case studies on the homepage seem broken, can you take a look when you get a chance? Also while you are in there the homepage feels a bit slow."

Two problems in one message, no addresses, no evidence, no boundary, no check, no date, and "when you get a chance" is a permission slip to never start.

Strong.

• What: Three "View case study" buttons on the homepage return a 404.
• Where: The three cards in the "Our work" section of the homepage. The three broken addresses are listed in the attachment. The same three links also appear in the footer of ten other pages.
• Evidence: Screenshots attached. Reproduced on desktop Chrome and iPhone Safari on 18 September.
• What should happen: Each button goes to its case study page. If a case study no longer exists, the button should be removed rather than pointing at a missing page.
• Do not change: The layout of the cards, or anything else on the homepage, in this release.
• How we will check: Click all three buttons on desktop and on a phone. Each one opens a case study page that loads. No 404.
• When: Before 12 October, because the paid campaign for this page restarts that week and these are the links interested visitors click.

Same problem. One of those gets done this week. That example is real: a PostCliq audit of an Australian site on 20 September 2026 found those three broken buttons. PostCliq reports each finding with its evidence and location, which is most of a brief already, and a free audit of your site gives you a list in that shape.

What should you leave out of a website brief?

Leave out the business case, any diagnosis you are not sure of, and every second request. A developer needs to know what to change and how to check it, not your revenue model or your guess about caching. One brief, one change.

The business case, unless you are asking for a decision rather than for work. A brief that opens with three paragraphs of strategy buries the request.

The diagnosis you are not sure about. "I think it is a caching issue" from a non-technical requester sends people down the wrong path politely. Describe what you saw and let them diagnose.

The second request. It goes in its own brief.

What happens after it ships?

After it ships, run the check you wrote, yourself, on the device you specified, then confirm it or say precisely what still fails. Note the date it went live. That two-minute close is why your next brief gets picked up quickly.

People respond to requesters who close the loop, because those requesters make their work visible.

If the fix was supposed to change a number, note the date it went live somewhere you will find it later. You cannot attribute a change you cannot date. Do not expect every fix to move the number on its own. Optimizely's analysis of 127,000+ experiments found only about 12% produced a statistically significant win on their main metric. A/B testing for marketing teams explains when a fix is worth testing and when it is simply worth doing.

What to do next

1. Take the last website request you sent.
2. Rewrite it against the six headings above.
3. Split anything with two problems into two briefs.
4. Write the check first, then the rest.
5. After it ships, run the check yourself and reply with the result and the date.

It will be shorter than you expect and it will answer the questions you were about to be asked. If you want the headings as a page you can fill in, the website fix brief template is one page, free, and yours to edit. If the list is long enough that you are deciding whether to hire help, do you need a CRO agency or a tool sets out how Australian teams make that call, and the best CRO tools in 2026 covers what each tool answers.

Frequently asked questions

What is a website brief?

A website brief is a short written request that tells a developer or agency what to change on a website and how you will know it is done. A good one states the evidence, the exact page and element, the outcome wanted, what must not change, the test, and the deadline with its reason. It should fit on one page and describe one change.

What should a web design brief include?

For a new design, include the business goal, the audience, the pages, the content you will supply, the brand constraints, the integrations, the budget and the deadline. For a fix to an existing site, use six headings instead: evidence, location, desired outcome, what must not change, how you will check it, and when and why then. Both need a written definition of done.

How do I write a website brief?

Start with the check: write how anyone would confirm the change is done. Then add what you saw, with a screenshot or recording, the exact page and element, the outcome you want, what must stay untouched, and the date with the reason for it. Keep it to one change. If you have several problems, write several briefs and say which order you want them in.

Is there a free website brief template?

Yes. PostCliq's website fix brief template is a free one-page version of the six headings in this article: evidence, where, what should happen, what must not change, how we will check it, and when. You can copy it, edit it and reuse it for every request you send to a developer or agency.

How do I brief a web developer or agency?

Brief them in their units: one deployable change per request, with evidence, location, outcome, limits, a test and a dated reason. Leave out your diagnosis unless you are sure of it, and leave out the business case unless you need a decision. Ask them to challenge your order of priority, because two problems may share a cause and be cheaper to fix together.