How to write a website project brief on one page

A website project brief is one page that says what the business does, who the site is for and what a visitor should do. It also lists the pages you expect, what you already have, what must be kept, your constraints and who writes the copy. Leave the design and technical solution to the people quoting.

Every website design and development project with us starts with a written proposal. A brief like this is the fastest way to get one that fits, with fewer questions back and forth.

The one-page template

Copy these eight lines into a document and answer each in a sentence or two. Write "Not decided" where that is true.

1. The business. What you sell, to whom, and where, in two sentences a stranger could repeat. Leave out the history.
2. Who the site is for. The main visitor (a customer, a buyer, a candidate, a supplier), and the second if there is one.
3. One thing to do. Call, book, order or request a quote, in one verb. A second action is allowed, but it ranks second.
4. Pages we expect. A plain list, with a few words on each. A starting list, not a sitemap.
5. What we have. Logo, colours, photos, product list, text, the domain, hosting and analytics, and who holds each login.
6. What must be kept. Pages that bring enquiries, forms and where they send, addresses other sites link to, and tracking.
7. Constraints. Dates with a reason, systems the site must work with, and who approves.
8. Copy. Who writes it, and who provides images. Decide it now, because it shapes the timeline.

The lines that need the most thought

Lines 2 and 3 do the most work. Google's guidance on helpful, people-first content asks whether a site has a primary purpose and an intended audience. Your brief answers both before anyone designs a page.

"Make the site better" is not a visitor action. "Neighbours should send a cake order enquiry" is, and everything from the menu to the contact form can be judged by whether it helps.

Line 6 matters most when you already have a site. Google recommends building the list of addresses from several sources, not from memory, and our website migration checklist covers the rest of what to keep.

Line 5 is where projects stall quietly, because nobody knows who holds the logins. ICANN Lookup shows the domain's registrar. For the rest, see what to do first when your developer leaves, and get Search Console owner access before a developer goes.

Why one page is enough

The company reading your brief needs your facts and decisions, not a specification: working out the solution is the job it is quoting for. A longer document hides the three or four things that decide the project, and often locks in solutions chosen before anyone asked a question.

Who writes the copy, and why it decides the launch date

Copy is the words on every page. The build can run ahead of them on placeholder text, but a page cannot go live until real words and images are on it and approved. A bakery with a finished design and a Menu page with no menu waits on one document and the person who owns it.

That is why the brief names the writer. We agree it before we start, along with who provides images, which pages are in scope and what we need from you.

Whichever you choose, you own your content. Photos affect the date as much as words, so name who supplies them in the same line.

Constraints, not a wish list

A constraint is a fact that limits the project and that the people quoting cannot guess. Constraints go in the brief; wishes belong in the conversation that follows, where they can be weighed against each other.

• Dates with a reason. "Before the festival season" is useful. "As soon as possible" is not.
• Systems it must work with. Payments, booking, accounting, email, WhatsApp or a customer list the business already uses.
• Who approves. One person who can decide, and anyone else who must see it first.
• Rules you work under. Languages the site needs, legal pages you already have, accessibility needs.
• What cannot change. A logo file, a brand colour, an address printed on packaging.

Keep each line to a fact. If the dates, systems or approvers are not settled, say so.

What to leave out: design solutions and long competitor lists

Describe the problem and leave the answer open. "A slider on the home page" is a solution. "A visitor on a phone should find the opening hours without scrolling" is a problem, and there may be a better answer than the one you pictured.

• Design instructions. Colours you must keep go under constraints. Anything else waits for the design stage.
• A platform you chose in advance. If your team must be able to edit the site in a particular tool, that is a constraint, so say it. Otherwise let the people quoting recommend one.
• Long competitor lists. Two or three sites you like, with one line each on why, tell us more than ten links.
• Feature lists. A long feature list invites a quote for every feature on it. The one thing a visitor should do is a better starting point.

What happens next

Send the page. We reply within 24 hours with a few questions or a time for a call, online or by phone, in your working hours. Then you get a written proposal: what is included, what is not, the timeline with milestones, what we need from you, and the price. Nothing starts until you have agreed to it in writing.

Larger or less defined projects start with Discovery & Scope instead. It is a short, paid engagement that ends in a written scope, a plan with milestones, an estimate and the risks. You own the document and can take it to anyone. How we work describes both.

Next step: fill in the eight lines, mark what isn't decided, and send us the page. We'll reply with questions or a time for a call.

Reviewed and edited by Online Scope before publishing. Something out of date? Tell us at info@onlinescope.in. How we write the Blog.