Blog › By the MyBriefy team · October 24, 2026
Most website design projects that go over budget don't fail in the design stage. They fail before it, when nobody wrote down what the site is for, who approves it, or how many rounds of changes are included. A website design brief fixes that by getting those answers in writing before anyone opens Figma.
This guide covers what to put in a website design brief, which questions matter most, and how to get the client to fill it in properly. If you just want the questions, use our free website design brief template.
What is a website design brief?
A website design brief is a short document the client fills in (or you fill in with them) that sets out the goals, audience, scope, style and approval process for the design of a website. It's the reference point for every design decision and every "can we just add…" request that follows.
It's narrower than a full website brief. A design brief covers how the site should look and work for visitors, and what you'll hand over as designs. If you're also building the site, pair it with a website brief that covers features, content, SEO and hosting.
What to include in a website design brief
A good brief is short enough that the client finishes it and specific enough that two designers would come back with similar answers. These are the sections that earn their place:
- Purpose. Why the site is being designed or redesigned, in one or two sentences.
- Problems with the current site. What isn't working today. This is often more useful than the goals.
- Users and actions. Who visits, what they're trying to do, and the two or three actions that matter most (book a call, buy, sign up).
- Page list. The pages or templates to design. This is your scope line.
- Look and feel. Style words are a start, but links to sites they like and dislike, with a reason for each, do more.
- Brand assets. Guidelines, logo files, fonts and colors, and whether they're fixed or open to change.
- Accessibility and devices. For example WCAG 2.1 AA, and whether the design should be mobile-first.
- Deliverables. What you'll hand over: wireframes, high-fidelity mockups, a clickable prototype, a component library.
- Concepts and revisions. How many initial concepts and how many rounds of changes are included.
- Budget, deadline and approver. The numbers, the date, and the one person who signs off.
The questions that prevent the most rework
If you only get a handful of answers before kickoff, make it these:
- What should a visitor do on this site? Every layout decision depends on it.
- Which websites do you like, and why? "Clean and modern" means something different to everyone; a link with a reason doesn't.
- Which pages are in scope? Scope creep on design projects usually starts with one more page.
- How many concepts and revision rounds are included? This is what protects your margin.
- Who approves the designs? If the answer is a committee, plan for slower feedback and say so.
Ask for the approver's name, not their role. "The marketing team" can't give feedback by Thursday; a named person can.
How to get the client to fill it in
A brief only works if it comes back complete. A few habits make a big difference:
- Send it before the kickoff call, then use the call to go through the gaps rather than filling in the form together from scratch.
- Pre-fill what you already know from the sales conversation, so the client only answers what's missing.
- Hide the questions that don't apply. A long form with irrelevant questions gets skimmed.
- Give it a deadline tied to the project start date.
- Keep comments next to the answers, so a question about one answer doesn't turn into a long email thread.
Free website design brief template. 24 questions covering purpose, users, pages, style, accessibility, deliverables, revisions and sign-off. Copy them, or send the brief in MyBriefy so the client answers and approves it online.
See the templateCommon mistakes
- Starting mockups before the brand files and fonts arrive.
- Leaving accessibility until the end, when it changes colors, type sizes and components.
- Accepting "ASAP" as a deadline instead of a date, plus dates for client feedback.
- Not writing down what happens when the client asks for something outside the page list.
Once the brief is approved
Treat the approved brief as the source of truth. When a new request comes in, check it against the page list and the revision count before saying yes. If it's outside, it's a change: quote it, or trade it for something else in scope. That conversation is much easier when the client has approved the brief in writing.
In MyBriefy, the client fills in and approves the brief in a portal, and the approved version stays on their record next to the project, so you can point to it later. You can then turn it into tasks, a contract or an invoice when you need them.
