How to Write a Website Brief Your Designer Can Build From

A website brief is one or two pages which tell your designer what the website is for, who it is for, which pages it needs, which words and photos already exist, what it should look like with a few examples, and what has to keep working after launch, together with the date, the budget and the person who signs it off. I build what a brief lists, including the items marked optional, which I show as variants, so I think it’s really worth knowing that the brief is the scope. Whatever it leaves out mostly reaches the design late, as a change, and a change after the layout is agreed costs more than a line in the brief would have.

This post goes through each part of a website brief, what I would write in it, and the few things which make a brief harder to build from.

What a website brief is for

The brief is the document which the designer measures every decision against, so when a reviewer later asks whether something is part of the job, the answer is in the brief. On one visual system review, two additions which went beyond the reviewer’s list, a motion timings table and a set of icon rules, came off the client’s board and moved into the developer notes, because they answered questions which nobody had asked. The same rule works in your favour, since anything you list is something the designer has agreed to deliver.

Nielsen Norman Group’s article on stakeholder interviews recommends that these conversations open a project, so the team agrees on the business goals and the measures of success before anyone designs a screen, and a written brief is the short version of that conversation which you can send before the first call.

What to put in a website brief

1. What the website is for

Write one main goal in a sentence, such as booked consultations, quote requests or online orders, and how you will know that it works, for example the number of enquiries a month. One goal decides what the home page leads with and which button sits in the header, while three goals of equal weight mostly end up as three buttons which compete with each other.

2. Who it is for

Describe the people who will use the site and the two or three things each of them comes to do, such as checking a price, finding the nearest location or reading reviews before they book. The GOV.UK Service Manual tells its teams to start by learning user needs and to treat every idea which does not come from users as an assumption, and a list of tasks in your customers’ words is the most useful part of that for a designer.

3. The pages

List the pages which you expect, with the page count, since the count sets most of the time and the budget. A five page company site and a twenty page site with a location page for each branch are different jobs, and I would rather know about the branches on the first day than find them in the second round. If you are not sure, list what each page has to answer and let the designer group it into pages.

4. The words you already have

Attach the copy which exists, even as a rough document, and say which parts are final. I design with the words from the content document as they are written, so the headings and buttons are sized to your text and not to placeholder text, which Nielsen Norman Group’s piece on content strategy supports when it says that content should be part of a project from the very beginning. My post on website copy before design goes into what happens when the words arrive after the layout.

5. The look, with examples

Add your logo and brand files, then three to five websites which you like, with one sentence for each on what you like about it, such as the photography, the calm layout or how the prices are shown. Nielsen Norman Group’s article on competitive usability evaluations makes the point that your project benefits from the work which other teams have already done, and the sentence beside each link tells the designer which part to learn from, so nobody copies the whole page.

If you already have a direction board from an earlier round, attach the file itself. On a tour company redesign, the first design system was built from screenshots of the direction board and came out with navy tints and 2px corners which the board did not have, and the board’s own layers held the real values, neutral greys, 4px corners and 20px cards with a soft shadow, so the system was rebuilt from those numbers.

6. What has to keep working

List every existing page which people find through Google, every form and where it sends its messages, and every tool which connects to the site, such as a booking system, a newsletter or a shop. Google’s documentation on site moves with URL changes recommends permanent redirects from each old address to its new one, and that only happens when someone has the list. When this website moved off its page builder, eleven indexed addresses were written into the plan as pages which had to keep resolving, and all eleven still do.

7. Accessibility and privacy

Say which accessibility standard the site has to meet, which is WCAG 2.2 AA for most businesses, since the W3C’s guide to planning and implementing accessibility advises putting the criteria into requests for quotations and contracts. If the site will have forms, note what they collect, so the privacy notice and the consent lines can be written alongside the forms.

8. Date, budget and who decides

Give the launch date and why it matters, a budget range, and the name of the one person who signs off each round. A range lets the designer suggest what fits inside it, and one person who decides keeps the feedback in one list, while three reviewers who each send their own notes mostly send three versions of the same page back.

Describe the problem and leave the design open

The part of a brief which helps a designer most is a plain description of what is wrong today, such as visitors calling to ask about prices, or the booking page being hard to find on a phone. A line which names the fix instead, such as a bigger logo or a slider on the home page, gives the designer one answer to check and hides the question behind it, so I would write the problem and add the idea underneath as a suggestion. The designer’s proposal is then the answer to your problems, and you can compare proposals from different designers line by line against the same list.

I would also send the brief before the first call, so the call can go into the details. My posts on questions to ask a web designer and the website handover checklist cover what to ask on that call and what you should hold at launch, and my about page says how I work with a brief.

Frequently asked questions

How long should a website brief be?

One or two pages for a company website, plus the copy and brand files as attachments. Every part in the table above fits in a few lines, and a longer brief mostly repeats itself.

What should a website brief include?

The goal, the audience and their tasks, the pages, the existing words and brand files, a few reference sites with a reason for each, what has to keep working, the accessibility level, and the date, budget and person who signs off.

Do I need a sitemap before I write the brief?

A rough list of pages is enough, and the designer can turn it into a sitemap in the first round. What matters is that every page you expect is on the list, since the count sets the time and the budget.

Should I put my budget in a website brief?

Yes, as a range, since it lets the designer tell you what fits inside it, and two proposals for the same range are much easier to compare than two proposals which each guessed a different budget.

What is the difference between a website brief and a proposal?

You write the brief and the designer writes the proposal, which answers it with the approach, the pages, the timeline and the price, so a clear brief is what makes proposals from different designers comparable.