How to Write a Design Brief: A Founder's Guide

You are about to spend five figures and weeks of company attention on a new website or brand. A successful engagement starts with both sides agreeing on what the project has to accomplish before anyone opens a design file.

That agreement is the brief. When you treat it as just a list of pages, feedback starts sounding like taste instead of judgment, and an eight week project can become fourteen.

This is what a studio needs from you before the work starts, including the parts founders most often leave out.

What a brief is for

A brief defines the goals, audience, scope, and deliverables of a project before work starts. Its job is not to describe the deliverable, but to give both sides something to point at when a decision is contested.

"Clean and modern" is fine as a conversation opener, but useless as a standard. A good brief makes clear what the work needs to achieve and how you'll know whether it did.

It also protects you when scope changes. Once deliverables are written down, two more pages become a scope discussion rather than an argument about what was implied.

Who should write it, and when

The founder or internal project lead writes the first version, because that first draft is mostly business knowledge nobody outside the company has yet.

That does not mean writing it alone, or writing it well the first time. The brief is one document with three moments:

• Before you talk to studios. A rough first version. Situation, objective, audience, rough scope, budget, dates. Thirty minutes of work, and it is allowed to have gaps.

• During discovery. The studio pushes on it. This is where it gets technically accurate, where scope becomes real, and where you find out which of your assumptions were wrong.

• Before design starts. Locked and agreed by both sides. This is the version that gets pointed at in week five when someone wants something rebuilt.

Most founders skip that first step and go straight to proposals, which means the studio often ends up deciding what the project is really about.

Design brief evolution

Start with the problem

Most founder briefs describe an artifact. Nine pages, dark theme, animated hero, something like Linear. That is a solution, and someone already picked it, usually you, usually in a hurry.

Hand a studio a solution and their job becomes execution. You get exactly what you asked for, which is a problem if what you asked for was wrong. Compare:

Design brief comparison

Same company, two completely different projects.

None of this means the deliverable list disappears. It still belongs in the brief. The important part is that it comes out of the problem you're trying to solve, rather than being decided before you've figured that out.

What to include

1. Overview

A few sentences on the company, the stage, and why this project is happening now. A raise, a repositioning, a launch, a site that stopped matching the company. It tells a studio what the project is really for, and it is often the difference between a redesign and a rebuild.

2. The objective

An objective is something you could check ninety days after launch.

A CFO landing cold on pricing can tell what deployment costs without contacting sales. An outbound prospect understands the category within one screen. A candidate can tell you are past the risky stage.

Not every objective is a conversion metric, and pretending otherwise makes founders invent numbers nobody believes. If you are pre-revenue and the site exists to make a seed-stage company legible to candidates and investors, write that. It is legitimate and it changes the work.

3. The audience

Two things get missed constantly. The first is the split between user and buyer, which in B2B are usually different people with different anxieties. Say which one the site is for.

The second is everyone else who reads it: investors in diligence, candidates before interviews, partners deciding whether to integrate. If the site is doing recruiting work, that page has to be scoped rather than assumed.

4. Scope and exclusions

A good brief should be just as clear about what is out of scope.

The items silently assumed into scope are always the same: copywriting, illustration, photography, blog templates, migrating existing posts, docs and changelog, CRM and form integrations, post-launch changes.

Also say who owns the file after handoff and whether your team can publish changes without an engineer. That answer drives the platform decision more than any aesthetic preference, and it gets expensive to discover later.

5. Timeline

If the launch is tied to something, say what and when. A conference, a funding announcement, a product release, or a board meeting all change how a studio sequences the work, and a fixed date usually means something in scope has to move.

Same for technical constraints. An existing CMS you are keeping, a docs site on another platform, a marketing stack that has to stay connected, an engineering team with no capacity to help. These are cheap to state and expensive to discover late.

6. Copy ownership

Copy is one of the most common reasons projects stall.

A B2B website is an argument laid out visually. If nobody has written the argument, there is nothing to lay out, and the design work stops while everyone waits. Decide before kickoff whether you write it, the studio writes it, or you hire a writer, and put your dates in the timeline next to theirs.

7. Budget

Say the number, or at least the range.

Studios scope the depth of research, exploration, and iteration around the budget, so two different numbers produce two genuinely different projects. Withholding it does not get you a lower price, it gets you a proposal built on a guess.

If you have no reference point for your stage, we published what SaaS websites actually cost by funding stage.

8. Decisions

Name one person with final sign-off, then handle the invisible stakeholders. If a co-founder has strong opinions, if a board member will weigh in, if an investor wants a look, get them into kickoff or agree upfront that their input is advisory.

Say how feedback gets given, too. One rule does most of the work: feedback references the objective, not taste. "I don't like the font" is unusable. "This reads consumer and our buyer is an enterprise security team" is usable, because it points at a standard both sides agreed to. Then agree on the logistics: how many rounds, where comments go, and when feedback is due.

9. References

Three to five sites, each with one sentence on what specifically you are pointing at. Not "I like this" but "I like the way they handle the pricing comparison".

Negative references are just as useful, so include one or two you dislike and explain why.

Be careful pulling from a completely different niche, as every structure imports assumptions about the buying cycle. For closer references, we broke down SaaS websites worth studying and what each does well.

Where AI briefs fall apart

Many founders now paste their site into an LLM and get a complete brief back in thirty seconds. The output looks professional, which is exactly the problem.

An AI brief fills every field, so nothing signals where you actually lack clarity. A human brief with three sections marked "not sure yet" is more useful, because those gaps become the first conversation with the studio.

Where it does earn its place: cleaning up your own messy notes into structure, summarizing a sales call transcript, and generating the list of questions you should be able to answer.

What to leave out

• Layout instructions. Say what the section must accomplish, not where the logo goes.

• Personas with hobbies. A job title with real purchase context beats a fictional profile.

• Adjectives with no reference. Clean, modern, premium and bold mean four things to four people.

• Feature lists from the roadmap. The site sells an outcome, not a backlog.

Start writing yours

Use the checklist below as your starting point. Nine items, one page, written before you talk to anyone. It is fine for two or three of them to say "not sure yet," since those become the first thing worth discussing.

Design brief checklist

The point of the brief is not to constrain the work, it is to give the studio something specific to work toward and both sides something to judge the result against.

FAQ

What is a design brief?

A document defining the objective, audience, scope, budget, and decision process for a design project before work begins. It is the shared reference point both sides return to when a decision is contested.

How long should a design brief be?

One to two pages for most projects. A short brief carrying the real business situation beats ten pages of personas and adjectives.

What should a design brief include?

Overview, objective, audience, scope with explicit exclusions, timeline and constraints, copy ownership, budget, sign-off process, and references with reasons attached.

Can AI write a design brief?

It can structure one from material you supply, such as your own notes or a call transcript. It cannot supply the material. AI briefs read fluently and fill every field, which hides the gaps a studio needs to see.

Should I share my budget with a design studio?

Yes, and in the discovery call rather than after the proposal. Studios scope research, exploration, and iteration around the budget, so withholding it produces a proposal built on a guess.

What if the brief changes mid-project?

Small adjustments are normal. Large ones usually mean discovery was too thin, and should be handled as a documented change to scope, timeline, and cost.