How to Write a Design Brief: A Freelancer’s Template That Actually Prevents Scope Creep

A good design brief is a short document (1–3 pages) that defines the goal of the project, who it’s for, what success looks like, what’s in scope, what’s not, and how decisions get made. Write it before the contract is signed, get the client to approve it in writing, and reference it every time someone asks for "just one more small thing." If you do nothing else this year to protect your sanity as a freelance web designer, install this one habit.

Most freelancers either skip the brief entirely or treat it as a formality. Then three weeks into the project the client says "actually we also need a booking system, and can you redo the homepage in dark mode?" and suddenly the fixed-price project that was supposed to take 40 hours is 110 hours and you’re emotionally exhausted. The brief is the cheapest insurance policy you can buy. It costs you about two hours of work and saves you, on average, between 30% and 60% of the project’s eventual scope creep.

This guide walks through exactly what to put in a design brief, gives you a copy-pasteable template, and shows how to use it as your scope-creep firewall for the rest of the project.

Why most freelancers skip the brief (and what it costs them)

The freelancer’s version of the design brief usually looks like this: a Slack thread, a 90-minute kickoff call where everyone took separate notes, a Google Doc the client started but never finished, and a signed contract that says "modern, clean website, around 5 pages."

Three weeks in:

• The client expected an e-commerce checkout. You quoted for a portfolio site.
• The client expected the new site to import all the old blog posts. You assumed they’d copy them by hand.
• The client expected three rounds of design revisions per page. You assumed two rounds total.
• The client expected the site to be in three languages. You’ve never built multilingual.

Each of these is solvable individually. Together, they turn a 40-hour project into a months-long slog. And here’s the painful part: in 90% of these cases, the client is not being malicious. They genuinely thought they had communicated all of this. They genuinely thought a "modern, clean website" automatically included e-commerce, content migration, and Spanish.

The brief is the document where you and the client agree, in writing, on what the words actually mean. Skipping it doesn’t save time. It just delays the moment when you discover you have a problem.

The 11 sections every freelance design brief should include

Use this as a template. Copy it, adapt the wording to your style, and send it as the first deliverable on every project before you start the design work.

Section  ·  What it answers  ·  How long

1. Project summary  ·  What are we building, in one paragraph?  ·  3–5 sentences

2. Business goals  ·  What does the client want this site to do for their business?  ·  3–5 bullets

3. Target audience  ·  Who visits this site and what are they trying to do?  ·  1–2 paragraphs or 1–3 personas

4. Success metrics  ·  How will we know if this worked?  ·  3–5 measurable bullets

5. Scope (in)  ·  Exactly what’s included  ·  Bulleted list

6. Scope (out)  ·  Exactly what’s NOT included  ·  Bulleted list

7. Sitemap and page list  ·  How many pages, what are they called  ·  Tree or table

8. Tone, brand, references  ·  Visual and verbal direction  ·  Mood board, 3–5 reference sites

9. Tech and integrations  ·  Platform, CMS, third-party tools  ·  Bulleted list with versions

10. Process and revisions  ·  How decisions get made, how many revision rounds  ·  Numbered process + revision count

11. Timeline and milestones  ·  Key dates, dependencies, payment triggers  ·  Table or list

Step-by-step: how to fill out each section

1. Project summary

The project summary is the elevator pitch of the project. If a stranger read only this paragraph, they should understand what you’re building, for whom, and why. Three to five sentences is plenty.

A good summary names the client, the type of site, the primary user, and the primary outcome. Example: "Acme Yoga is launching a new website to replace their outdated WordPress site. The primary user is a working professional in Berlin looking for a yoga studio near them. The site’s primary job is to convert visitors into trial-class bookings via a clear schedule page and a one-step booking form."

If you can’t write this paragraph after the kickoff call, you don’t understand the project well enough yet. Go ask more questions.

2. Business goals

Business goals are the why behind the project. They are not features. "Add a booking form" is not a goal. "Increase trial-class signups by 30% in the first six months" is a goal.

Get three to five clear, business-language goals from the client. If they say "I want a beautiful site," dig deeper: beautiful for what? To attract more enterprise clients? To re-position from cheap to premium? To convince investors the company has its act together? Each of those leads to wildly different design decisions.

3. Target audience

Generic audience descriptions ("everyone interested in yoga") are useless. Push for specificity. The best briefs have one to three lightweight personas: a name, an age, what they do for work, what brings them to the site, what would make them bounce.

If the client struggles with this, ask: "Tell me about the last three customers who actually paid. What did they have in common?" That gives you real data instead of the client’s aspirational version of their audience.

4. Success metrics

How will both of you know, in six months, whether this project was a win? This section should have measurable answers. Examples:

• 30% increase in trial-class bookings within 6 months
• Bounce rate on the homepage under 50%
• Page load time under 2 seconds on mobile
• 5+ qualified inbound leads per month from the contact form
• Lighthouse performance score of 90+

If the client refuses to commit to numbers, that’s a yellow flag. It usually means they don’t know how to measure success themselves, which means they will measure success based on whether the site "feels right" to their cousin who is "really into design." That’s the situation you want to avoid.

5. Scope (in)

This is the most important section in the entire brief. Be ruthlessly specific. Don’t write "homepage." Write "homepage with hero, services overview (3 services), 2 testimonials, contact CTA, footer."

A good scope-in section reads like an itemized invoice. The client should be able to skim it and immediately spot anything missing. That’s the point.

6. Scope (out)

Equally important: what is explicitly not included. This is where you protect yourself from the "oh I assumed that was part of it" conversation three weeks from now.

Common things to put in scope-out:

• Content writing (you design around their copy; they provide it)
• Stock photography or paid illustrations (or specify a budget)
• SEO beyond basic on-page setup
• Email marketing setup (Mailchimp, Klaviyo, etc.)
• E-commerce (if not in scope)
• Multi-language setup
• Migration of existing content from old site
• Hosting setup or domain configuration
• Custom illustrations or icon design
• Post-launch maintenance (separate package)

Don’t worry that this section feels rude. It feels rude to you because you wrote it. To the client, it just looks like clarity, which they will appreciate when they realise you’re a professional who has done this before.

7. Sitemap and page list

A simple tree showing every page on the site, including subpages. For a freelance project, a numbered list usually does the job:

1. Home
2. About
3. Services (parent)

• Service A
• Service B
• Service C

1. Case studies (parent)

• Individual case study template (5 cases at launch)

1. Blog (parent)

• Article template

1. Contact

This list directly maps to the design and development effort. If it grows from 6 pages to 12 pages mid-project, that’s a scope change with cost and time implications, and you can point to the brief to make that conversation easy.

8. Tone, brand, references

Three to five reference sites the client likes, with one sentence each on what they like about them. Three to five sites they don’t like, with one sentence each on why. A mood board if you have time. A note on tone of voice (playful, technical, premium, friendly, etc.).

This section eliminates 80% of subjective design arguments. If the client signs off on "we want to feel like Linear or Stripe — minimal, confident, lots of whitespace," they cannot reasonably reject your first design for being too minimal. They already approved that direction.

9. Tech and integrations

Be specific:

• CMS: Webflow / WordPress / Framer / Sanity / etc.
• Hosting: Webflow Cloud / Cloudways / Vercel / etc.
• Booking: Calendly / Cal.com / native form
• Email: Mailchimp / ConvertKit / native form to inbox
• Analytics: Plausible / Google Analytics
• Payments: Stripe / PayPal / not applicable
• Browser support: latest 2 versions of major browsers

Anything you don’t name here is a potential surprise. If the client suddenly says "we need to integrate with Salesforce," that’s clearly out of scope.

10. Process and revisions

Spell out exactly how the project will run, in plain language:

1. Wireframes for all pages, delivered together. One round of revisions.
2. Visual design for homepage and one inner page. Two rounds of revisions.
3. Visual design rolled out across all remaining pages. One round of light revisions.
4. Build phase. One round of QA revisions on the staging site.
5. Launch.

State the revision count clearly. "Two rounds of revisions per design phase" is a sentence that has saved more freelancers from financial ruin than any other.

Also state how feedback gets given. This is where dotts comes in: instead of WhatsApp screenshots and scattered emails, all feedback goes through a single shared link with pinned comments. If the feedback isn’t in dotts (or your tool of choice), it doesn’t exist. Put that in the brief.

11. Timeline and milestones

A simple table:

Milestone  ·  Date  ·  Payment trigger

Brief signed, 50% deposit  ·  Week 0  ·  $X invoiced

Wireframes approved  ·  Week 2  ·  —

Visual design approved  ·  Week 5  ·  —

Site built on staging  ·  Week 8  ·  —

Site launched  ·  Week 10  ·  Final 50% invoiced

Tie milestones to client actions where possible: "design approval expected within 5 business days of delivery; if delayed, the timeline shifts by the same number of days." This puts the responsibility for keeping things moving on both sides, not just you.

Real-world example: Maja’s salon site

Maja is a freelance Webflow designer in Stockholm. She was hired to build a new website for a hair salon. The kickoff call was friendly and lasted 90 minutes. She quoted $3,500 for "a 5-page modern Webflow site, two rounds of revisions, four-week timeline." Contract signed.

Three weeks in:

• The owner had decided she wanted online booking (Maja had assumed they’d use Calendly externally; the owner wanted Fresha embedded).
• The owner wanted a gallery of every stylist (not in scope).
• The owner wanted the site in Swedish and English (not discussed at all).
• Two of the three "rounds of revisions" had been a single Slack message saying "make it pop more" with no specifics.

Total project: 11 weeks, 95 hours, $3,500. Maja made roughly $37/hour on a project she had quoted at $87/hour.

After that experience, Maja built a 2-page brief template using the 11 sections above. She now sends it to every prospective client before quoting. About 20% of prospects ghost her at this stage — which she now considers a feature, not a bug, because those are the clients who would have caused 80% of her scope creep. The clients who do go through the brief process pay her on time, give her clear feedback, and refer her to other people who treat her work like work.

The brief did not require new skills. It required treating the start of a project as the most important phase, not a formality.

How to actually use the brief during the project

Writing the brief is half the work. The other half is referring back to it when things drift.

When the client says "small request, can we add a team page?" you don’t have to say no. You say: "Happy to add it. Looking at the brief, the team page wasn’t in scope, so it’d be an extra $X and would push the launch date to Y. Want me to send a quick change order?" That sentence — said calmly, without apology — is one of the highest-leverage things you can do as a freelancer.

The brief also helps when feedback gets vague. "It needs to be more premium" is hard to action. But if the brief says "the site should feel like Linear or Stripe — minimal, confident, lots of whitespace," you can say: "Got it. The brief calls out Linear and Stripe as references. Looking at the current homepage versus those, the difference is mostly typography weight and spacing. Want me to push in that direction in the next round?" Now you have a productive conversation instead of a guessing game.

Finally, the brief makes hand-off and sign-off easy. At launch, you check the success metrics, the scope-in list, and the deliverables — all defined in the brief — and confirm them as done. No surprises, no last-minute "but I thought we were also doing X."

Bottom line

A design brief is not a bureaucratic document. It’s a 1–3 page agreement that defines what success looks like, what’s in scope, and how decisions get made. Write one for every project, get the client to sign off, and refer back to it whenever scope drifts. It’s the single highest-leverage habit you can adopt as a freelance web designer in 2026.

FAQ

What is a design brief in web design?

A design brief is a short written document that defines the goals, audience, scope, tone, technology, process, and timeline of a web design project. For freelance web designers, the design brief is the agreement between you and the client about what is being built and how decisions will be made. It’s typically 1–3 pages long and signed off before any design work begins.

Who should write the design brief, the client or the designer?

The freelance designer should write the design brief. The client provides the raw information through a kickoff call and a discovery questionnaire, but the designer turns it into a structured document. This is partly because most clients have never written one before and partly because writing it forces the designer to confirm they understood everything correctly. The client then reviews and signs off.

How long should a freelance design brief be?

For most freelance web design projects, the design brief should be 1–3 pages, or roughly 800–1,500 words. Longer briefs tend to go unread. Shorter briefs miss critical sections that come back to bite you later. The 11-section template in this article fits comfortably in 2 pages for most projects.

What’s the difference between a design brief and a contract?

The contract is the legal agreement: payment terms, IP ownership, kill fees, cancellation, liability. The design brief is the working document: what we’re building, for whom, with what scope. Both are necessary. The contract protects the relationship legally; the brief prevents the misunderstandings that make legal protection necessary in the first place.

Can I use the same design brief template for every client?

Yes, the structure stays the same. The 11 sections in this article work for any small-to-medium web design project. What changes is the content inside each section. Build the template once, then duplicate and fill it in for each new project. After three or four projects you’ll start refining your own version with the questions that matter most to your niche.

How do I get the client to actually fill out the brief?

Don’t ask the client to fill it out cold. Run a 60–90 minute kickoff call, take notes, write the brief yourself, then send it for review. Most clients will edit a draft happily but freeze when handed a blank template. Frame the review as: "I’ve put together what I heard — please correct anything that’s wrong and add anything I missed."

What if the client refuses to sign off on the brief?

Don’t start the design work. A client who won’t commit to scope is a client who will change scope endlessly. Politely say: "I want to make sure we’re aligned before I start. Once you’ve signed off on the brief, I can begin." If they push back hard, that’s information about how the rest of the project will go.

How does the brief help prevent scope creep?

The brief defines what’s in scope and what’s out of scope in writing, both signed by you and the client. When a "small request" comes in mid-project, you can reference the brief and say: "That’s outside what we agreed — here’s what it would cost and how it would shift the timeline." This isn’t confrontational; it’s the cleanest way to handle change requests professionally without resentment building up on either side.

Brief done? Now collect feedback like a pro. [Try dotts free →](https://dotts.se)