How to Write a Design Brief (A Founder's Template for Hiring a Designer)

Here is how to write a design brief: put nine things on one page — the problem you are solving, who it is for, your goals and how you will measure success, the scope and screens, your brand, references, constraints, timeline, and a budget range. A good brief is not paperwork; it is the document that lets a designer quote you accurately, start fast, and hand off work your engineers can actually build.

Most founders overthink this. You do not need a research deck or a 20-page PRD. You need a shared, honest picture of what you want and why. Below is exactly what to include in a design brief, a template you can copy-paste, the mistakes that quietly waste money, and how a tight brief pays for itself before the first pixel is drawn.

What a design brief actually is (and what it is not)

A design brief is a short written document that tells a designer what you want built, for whom, and against what constraints. That is it. It is not a creative spec that dictates the solution — if you already knew the exact layout, you would not need a designer. The brief describes the problem and the boundaries; the designer owns the solution.

Think of the difference between “build me a login screen that looks like Linear” and “users drop off before they finish signup — here is who they are, here is what we have tried, here is our stack.” The first hands over a guess. The second hands over a problem, and a good designer will often solve it in a way you had not considered. Learning how to write a design brief that describes intent instead of prescribing pixels is the single biggest lever you have on the quality of what comes back.

What to include in a design brief: the nine sections

Here is what to include in a design brief, in the order that makes sense to read. None of these need to be long — one honest sentence usually beats a paragraph of filler.

1. The problem

Start with the problem, not the feature. “We need a pricing page” is a feature. “Prospects reach pricing and leave without talking to us” is a problem — and it opens up more than one way to fix it. Write two or three sentences on what is actually going wrong or what opportunity you are chasing.

2. The audience

Who is this for? Not “everyone.” Be specific: the role, the context they are in, how technical they are, whether they are on mobile at 11pm or a desktop at work. A dashboard for finance analysts and an onboarding flow for first-time consumers are different crafts. If you have a rough sense of your primary user, say so; if you do not, say that too, because it changes the approach.

3. Goals and success metrics

What does “this worked” look like in numbers? More completed signups, a shorter path to first value, fewer support tickets, a demo that closes investors. You do not need analytics-grade precision — you need a direction and a way to know later whether the design moved it. This is also the section that keeps everyone honest when opinions clash: you defer to the goal, not to taste.

4. Scope and screens

List the actual screens or surfaces. “Marketing site: home, pricing, one product page, contact” is a scope. “A website” is not. For an app, name the flows — signup, empty state, the main working screen, settings. Also name the states designers are routinely asked to add for free later: loading, error, empty, and the success case. Listing them up front is the difference between a quote that holds and one that balloons. This is the level of detail that also makes a clean Figma handoff your developers can actually build from possible instead of a pile of pretty static frames.

5. Brand and visual direction

Point to what exists: a logo, colors, fonts, a prior site, a deck. If you have a brand guide, attach it. If you have nothing, say the vibe in plain words — “calm and trustworthy, closer to a bank than a toy” — and let the designer propose direction. Do not leave this blank and then react; that is how you burn a round of revisions discovering you hate the color blue.

6. References

Three to five links to products you admire, with one line each on why. “I like Stripe’s docs because the layout feels effortless” tells a designer far more than a bare URL. Include one or two anti-references too — things you do not want — because knowing what you reject narrows the search fast.

7. Constraints

The unglamorous section that saves the most money. Your tech stack (React? Webflow? WordPress?), your existing component library, accessibility requirements, browsers or devices you must support, content you do or do not have yet, legal or compliance rules. A designer who knows you are shipping on a specific framework designs within it — instead of handing over something beautiful that your engineers quietly rebuild.

8. Timeline

When do you need it, and is that a hard launch date or a hope? Say what is driving it — a demo day, a funding milestone, a marketing push. Real timelines let a designer tell you honestly what fits and what has to be phased. Working across time zones, I run on GMT+6, which means US clients often get overnight turnarounds; either way, an honest date beats a fake-urgent one.

9. Budget range

Name a range. This is the part founders resist most, and the resistance costs them. A budget is not a number a designer maximizes against you — it is the constraint that decides whether you get a focused MVP or a full system, one polished flow or ten rough ones. A few thousand dollars and a five-figure engagement are different projects, and a good designer will tell you honestly what is realistic in each. Withholding it just means we both guess, and guessing wastes the first call.

A design brief template you can copy-paste

Here is a design brief template you can paste into a doc or an email and fill in. Bullet points are fine — polish is not the point, clarity is.

1. Project: [one line — what this is]
2. The problem: [what is going wrong / the opportunity]
3. Who it is for: [primary user, their context, how technical]
4. Goal & success metric: [what changes if this works]
5. Scope / screens: [list them; note states you need]
6. Brand: [links or files, or the feeling in words]
7. References: [3–5 links + why + 1–2 anti-references]
8. Constraints: [stack, accessibility, content status, compliance]
9. Timeline: [date + hard or soft + what is driving it]
10. Budget range: [an honest band]
11. Open questions: [anything you are unsure about — genuinely useful to a designer]

That last line matters. A brief that admits what you have not figured out yet is more useful than one that fakes certainty. Naming your open questions invites the designer to solve them with you instead of guessing and billing you for the guess.

Common mistakes that quietly cost you money

Prescribing the solution instead of the problem

When a brief specifies the exact layout, you have hired a pair of hands, not a designer. You pay senior rates for execution and lose the thinking you were actually buying. Describe the outcome; leave room for the craft.

Hiding the budget

The most common one, and the most expensive. Without a range, a designer either over-scopes and prices you out, or under-scopes and you are disappointed. A range is a gift to both sides.

Skipping success metrics

With no agreed measure of success, revisions become a tug-of-war of opinions and every round costs you time and money. A metric turns “I do not love it” into “does this move the goal?”

Forgetting the boring constraints

Leaving out the tech stack or content status is how you end up with a design that cannot ship as-is. The unglamorous section is the one that protects your timeline.

Writing a novel

The opposite failure. A 15-page brief buries the three things that matter. Keep it to a page. If it does not fit on a page, you are probably still figuring out the project — which is fine, but say that instead of padding.

Why knowing how to write a design brief saves you money

A vague brief is the most expensive kind. It feels cheaper because you wrote it in five minutes, but you pay the bill later — in extra revision rounds, in a designer scoping wide to cover their uncertainty, in rework when engineers hit something the design ignored, and in weeks of delay while everyone re-aligns on what was meant.

A tight brief compresses all of that. It lets a designer give you a firm, honest quote instead of a padded one. It kills whole rounds of revision because the goal and the constraints were agreed before anyone opened Figma. And it produces work that hands off cleanly, so your build does not stall. On my own projects, a clear brief is what makes a fixed written quote and a same-week start possible — the certainty comes directly from yours.

If your project is a website launch, the same discipline extends past design into shipping. My free website launch checklist covers the pre-launch items that briefs routinely miss, and if you are hiring for a product specifically, this guide on how to hire a UI/UX designer for SaaS walks through vetting and working with the person you brief.

Do you need a brief before you have talked to a designer?

No — and this is worth saying plainly. You do not have to arrive with a perfect brief. A good designer will help you write one; a first call is often exactly where the fuzzy problem gets sharpened into these nine sections. What you do need is honesty about the four hardest ones: the real problem, the actual constraints, the true timeline, and a budget range you can live with. Bring those in rough form and the rest gets built together.

If you have a project in mind, send me whatever you have — even three bullet points — and tell me about your project. I reply within 24 hours, will help you shape the brief if it is still forming, and send back a fixed written quote so you know exactly what you are getting before anything starts.