How to Write a Website Design Brief That Prevents Guesswork

A website brief doesn't need to be a polished document with technical language. It needs to explain what the business does, what visitors should accomplish, and which decisions the project cannot leave to guesswork. A clear two-page brief can be more useful than a large presentation full of mood images and no operational requirements.

The brief is also a tool for comparing proposals. When every supplier sees the same information, you can ask better questions about scope and cost. It doesn't replace discovery, but it gives discovery a sensible starting point.

Explain the business in plain language

Describe your services, who they help, and any important limitations. Avoid relying on a slogan. A person unfamiliar with the business should be able to understand what you provide and what a suitable customer looks like. Include genuine differences you can support with evidence.

Mention practical context: a new business, an existing site that no longer fits, a changed service offering, or an expansion into a different audience. Explain why the project is happening now. That prevents a designer from treating a service launch as merely a visual refresh or assuming that all old content should disappear.

Name the audience and its questions

Choose the primary audience rather than declaring that the website is for everyone. A prospective customer, returning client, job applicant, and employee may need different information. Decide which journey is most important for the first release and which others need support.

List the questions that audience asks before acting. For a service company, those might include whether a job is covered, where the team works, what information is needed for an enquiry, and what happens afterward. Real questions from your staff are more useful than a list of broad marketing adjectives.

Define a complete customer journey

Write the desired sequence in ordinary language. For example: a visitor finds a service, understands whether it fits, views a relevant example, and submits enough information for staff to respond. Then describe the handoff. Who receives the request, what should the confirmation say, and how will the business follow up?

This is an illustrative brief structure, not a performance promise. A button labeled “get started” doesn't define what starting means. Our website design benefits article explains how clear journeys connect design decisions to useful business outcomes.

Inventory the content you have and the content you need

List current pages, articles, images, documents, and recordings. Identify what is accurate, what needs revision, and who can approve it. Mark material you have permission to use. If content is missing, decide whether your team or the supplier will prepare it.

Include the existing URLs that matter. A redesign can accidentally lose useful service pages or article links when the brief only lists new navigation labels. Record what must survive and where a changed page should go. The website launch checklist explains how content and URL decisions affect the final release.

Describe functionality through tasks

Instead of “we need a booking system,” explain who books, what availability means, whether payment is involved, and how cancellations work. For a form, describe required information, permissions, routing, and confirmation. For a private area, describe who can access which records.

Name the existing tools and account owners that a feature must connect with. Avoid assuming an integration is possible until the relevant interface and authorized access are checked. Specify important exceptions such as a failed submission or unavailable service. These details allow a supplier to estimate a complete flow rather than just the visible screens.

State accessibility and device expectations

Include the devices your audience uses and any known accessibility needs. Ask for keyboard-friendly controls, meaningful headings, labeled forms, and suitable media alternatives. These requirements belong in the scope before implementation, not as a request added after the layout is finished.

The website accessibility checklist is a practical starting point. It isn't a substitute for specialist evaluation or advice about applicable obligations. If the site serves a particular regulated or sensitive audience, explain that context so appropriate review can be planned.

Use visual references to explain preferences

A few references can help communicate the kind of layout or tone you prefer. Say what you like about each one: readable typography, clear service navigation, a restrained color palette, or a particular way of presenting examples. Otherwise, a supplier may copy an element you didn't intend to request.

Also list dislikes and constraints. Perhaps large autoplay media would be difficult for your audience, or the business needs to maintain content without frequent design work. Separate a must-have brand rule from an exploratory preference. The brief should guide decisions, not require imitation of another business's entire website.

Set approval and ownership responsibilities

Name the person who provides consolidated feedback and the person who has final approval. List who supplies copy, images, legal policies, and integration access. Delays often begin when each party assumes the other owns a task. An agreed responsibility list is more useful than an optimistic deadline alone.

Clarify ownership of the domain, hosting, connected accounts, and content. Define the maintenance plan and how updates will be requested. Discuss export and handover before signing the agreement. The website cost guide explains why these ongoing responsibilities affect proposal comparisons.

Choose meaningful success measures

Use measures related to the task: suitable enquiries, completed bookings, fewer repeated questions, or clearer access to information. Establish a baseline where possible. Page views may be useful context but don't show whether the site helped the intended customer.

Don't turn the brief into a guaranteed ranking or revenue target. Search competition, demand, advertising, and sales follow-up also affect results. State what the project can control and what it will observe. A supplier should be able to explain how the proposed work supports the goal without promising an outcome it cannot ensure.

A copyable brief outline

• Business and reason for the project.
• Primary audience and its recurring questions.
• Main customer journey and staff handoff.
• Existing content, URLs, and missing material.
• Required workflows, integrations, and exceptions.
• Accessibility, devices, and media requirements.
• Brand rules and explained visual references.
• Launch scope, later ideas, and dependencies.
• Approval, account ownership, and maintenance responsibilities.
• Success measures and any available baseline.

Answer what you know and mark what needs discovery. You don't have to invent technical answers to make the brief look complete.

Common website brief questions

Do I need to specify the technology?

Not necessarily. Describe the task and constraints first. A supplier can recommend technology and explain why it fits. If you must use an existing system, state that requirement and who controls it.

Should the brief include the budget?

A realistic budget or spending constraint can help prioritize scope. Ask the supplier to explain what is achievable and what would be deferred. A vague budget combined with unlimited requirements makes useful comparison difficult.

Can the brief change during the project?

Yes, but record important changes and their effect on cost, timing, and responsibilities. Discovery may reveal a better approach; an unrecorded change can create confusion at approval.

Bring a clear starting point to the discussion

Explore MyPocket website design or share your website brief. The most useful brief is the one that lets both sides understand the job and identify the questions still worth answering.