Most freelance design projects do not go sideways because the designer lacks talent. They go sideways because the project started with a one-paragraph email and a vague promise that “we’ll figure out the details later.”
A design brief is the document that stops that from happening. It is the shared source of truth between you and your freelance designer, and it is the single cheapest insurance policy you can buy against scope creep, missed deadlines and revision round number seven.
This guide breaks down exactly how to write a design brief that a freelance UX or product designer can actually work from. You will get the nine sections that matter, what to put in each one, and short filled-in examples for two very common project types: a mobile app and a marketing landing page.
What Is a Design Brief?
A design brief is a short written document (usually one to four pages) that explains what you are building, who it is for, why it matters to the business, and what constraints the designer has to work within. It is written by the client, ideally with input from the designer, before any design work begins.
A good design brief answers three questions before a single pixel is drawn:
- Where are we going? The business goal and the user outcome.
- What are we delivering? The exact list of screens, pages, files and formats.
- How will we know it worked? The success metrics and the definition of done.
Design Brief vs Creative Brief vs Proposal
These three documents get mixed up constantly. Here is the difference:
| Document | Written by | Main purpose |
|---|---|---|
| Design brief | Client (with designer input) | Define the problem, users, scope and constraints of a specific design project |
| Creative brief | Marketing team or agency | Define the message, tone and channels for a campaign |
| Proposal / SOW | Designer | Price the work, set payment terms and lock the legal scope |
The order matters. The brief comes first. A designer who quotes without a brief is guessing, and a guess is how you end up with a change request halfway through.
The 9 Sections Every Usable Design Brief Needs
Below is the structure I ask every client to fill in before we start. You do not need beautiful prose. Bullet points are fine. What matters is that the information exists in one place.
1. Business Context and Goals
Start with the business, not the design. A freelance designer who understands your revenue model will make hundreds of small decisions in your favour without asking you every time.
Include:
- What your company does, in two sentences
- How you make money (subscription, one-off sales, leads, ads)
- The business problem driving this project
- What happens if you do nothing
Mobile app example: “We run a subscription habit-tracking app for amateur runners. 62% of new users churn within 14 days, and our onboarding is the suspected cause. Every 5% improvement in day-14 retention is worth roughly 40,000 EUR in annual recurring revenue.”
Landing page example: “We sell invoicing software to freelancers at 12 EUR per month. Our current homepage converts paid traffic at 1.1%. We need a dedicated landing page for our Google Ads campaign because sending ad traffic to a general homepage is burning budget.” Getting this right on every build is what separates a competent design studio from the rest.
2. Project Scope and Deliverables
This is the section that kills scope creep. Be brutally specific about quantity and format, and equally specific about what is not included.
Include:
- Number of screens or pages
- Breakpoints needed (mobile, tablet, desktop)
- File formats and handoff method (Figma file, prototype, spec sheet, exported assets)
- Number of revision rounds included
- An explicit “out of scope” list
Mobile app example: “In scope: 8 screens covering onboarding (splash, goal selection, notification permission, first run setup) and the first-session dashboard. Deliverables: Figma file with components, one clickable prototype, iOS and Android specs. Two revision rounds. Out of scope: settings, billing, Apple Watch, illustration creation, development.”
Landing page example: “In scope: one long-form landing page, desktop and mobile, plus a thank-you page. Deliverables: Figma file, exported images, a written spec for our Webflow developer. Two revision rounds. Out of scope: copywriting, blog templates, email templates, Webflow build.”
3. Target Users
“Everyone” is not a target user. The designer needs to know who is on the other side of the screen, what they already know, and what device they are holding.
Include:
- Primary user segment and a secondary one if it exists
- Their level of technical comfort
- Device and context of use (commuting, at a desk, outdoors, in a hurry)
- What triggers them to look for a solution
- Existing research: interviews, support tickets, session recordings, survey data
Mobile app example: “Primary: runners aged 28 to 45 training for their first half marathon. Comfortable with apps but impatient during setup. They open the app on a phone, often one-handed, right before or after a run. Trigger: they signed up for a race and feel unprepared. We have 12 user interviews in a shared doc.”
Landing page example: “Primary: solo freelancers in design and consulting who currently invoice with spreadsheets or Word. They arrive from a Google search like ‘simple invoicing software’, mostly on desktop during working hours. Main objection: fear of migration effort and hidden fees.”
4. Competitors, References and Anti-References
Showing is faster than describing. This section prevents the classic “that is not what I had in mind” moment at the first presentation.
Include:
- Three to five direct competitors
- Three references you like, with a sentence explaining why (layout? tone? density? colour?)
- Two or three anti-references: things you actively dislike
The “why” is the important part. “I like Linear” is useless. “I like how Linear uses a lot of white space and never more than two font weights” is directly actionable.
5. Content Readiness
This is the section most clients skip and the one that causes the most delays. Design cannot be finished around content that does not exist yet.
Include:
- Is the copy written, drafted or not started?
- Who owns copywriting and by what date?
- Do you have real photography, or will we use stock?
- Do you have real data to populate app screens, or placeholders?
- Legal or compliance text that must appear
Mobile app example: “Onboarding microcopy is drafted but not final. Our marketing lead delivers final strings by 28 September. No custom illustration budget, so we use an icon library.”
Landing page example: “Copy is not written. We would like the designer to work from a wireframe with placeholder headlines, then we insert final copy before the second revision round. We have 14 real customer photos and 6 written testimonials with permission to publish.”
A warning: if you hand over lorem ipsum and then paste in copy that is three times longer, you have just created a redesign, not a revision. Agree in the brief on approximate word counts for key blocks.
6. Brand and Design Assets
List what already exists so the designer is not recreating it or, worse, ignoring it.
Include:
- Logo files (vector, please)
- Brand guidelines or a colour and typography list
- Licensed fonts and who holds the licence
- Existing design system or component library and its condition
- How much creative freedom the designer has (extend the brand, or stay strictly inside it)
7. Technical Constraints
Design that cannot be built is expensive decoration. Tell the designer what the engineering reality is before they draw it.
Include:
- Platform and tech stack (native iOS/Android, React Native, WordPress, Webflow, Shopify, custom)
- Themes, templates or page builders you are locked into
- Accessibility requirements (WCAG level, contrast, font size minimums)
- Performance limits (page weight, image budgets)
- Third-party tools that must be embedded (booking widgets, chat, analytics, payment)
- Browser and OS support
- Who will build it, and are they available to answer questions?
Mobile app example: “Built in React Native. We follow platform-native patterns for navigation. Minimum iOS 16 and Android 11. Dark mode is required at launch. Accessibility target is WCAG 2.2 AA including 44px minimum touch targets.”
Landing page example: “Built in Webflow by an in-house developer. No custom JavaScript animations beyond Webflow interactions. Must embed a HubSpot form and a Calendly widget. Target Lighthouse performance score above 85 on mobile.”
8. Timeline, Budget and Decision Makers
Budget ranges are not a negotiation trick. A designer scopes different solutions for 3,000 EUR and 15,000 EUR, and neither of you benefits from three weeks of guessing.
Include:
- Budget range, or at least an approved ceiling
- Hard deadline and what it is tied to (funding round, trade show, campaign launch, seasonal peak)
- Key milestone dates
- Your feedback turnaround commitment (48 hours is a reasonable standard)
- The single named person who gives final approval
That last point is worth repeating. Consolidated feedback from one decision maker is the difference between two revision rounds and six. If five stakeholders send contradictory notes directly to the designer, the project stalls and the invoice grows.
9. Success Metrics and Definition of Done
Close the brief with measurable outcomes. This turns subjective taste debates into evidence-based decisions.
Include:
- One or two primary metrics with a current baseline and a target
- Secondary metrics worth watching
- How and when you will measure
- The concrete definition of “done” for the design phase
Mobile app example: “Primary: onboarding completion rate from 54% to 75% within 60 days of release. Secondary: day-14 retention, time to first logged run. Done means: all 8 screens approved, prototype tested with 5 users, handoff call with engineering completed.”
Landing page example: “Primary: paid-traffic conversion rate from 1.1% to 2.5% within 6 weeks. Secondary: scroll depth past the pricing block, form abandonment rate. Done means: desktop and mobile designs approved, spec document delivered, developer questions answered within the first build week.”
Quick Reference: The 9 Sections at a Glance
| # | Section | The question it answers | Risk if missing |
|---|---|---|---|
| 1 | Business context and goals | Why does this project exist? | Pretty design that moves no numbers |
| 2 | Scope and deliverables | What exactly gets delivered? | Scope creep and budget overruns |
| 3 | Target users | Who is this for? | Design based on internal opinions |
| 4 | References and anti-references | What does good look like to you? | A wasted first concept round |
| 5 | Content readiness | Do we have the copy and images? | Project frozen waiting on text |
| 6 | Brand assets | What already exists? | Off-brand output and rework |
| 7 | Technical constraints | What can actually be built? | Designs the developer cannot ship |
| 8 | Timeline, budget, approver | Who decides and by when? | Endless contradictory feedback |
| 9 | Success metrics | How do we know it worked? | Approval based on personal taste |
How to Write a Design Brief in Practice: A 6-Step Process
- Block 90 minutes. Not five minutes before a kickoff call. A real brief takes one focused session.
- Draft sections 1, 3 and 9 first. Goals, users and metrics are the hardest and most valuable. Everything else follows from them.
- Gather your evidence. Pull analytics screenshots, support tickets, past campaign results and any user research you already own. Link them, do not summarise them from memory.
- Write the “out of scope” list before the “in scope” list. It forces honesty about what you are really buying.
- Send it to your designer before the kickoff call. The call then becomes a challenge session instead of an interrogation.
- Let the designer amend it. A good freelancer will push back on unrealistic timelines or vague metrics. Fold their edits in, then both parties sign off on version 2. That signed version is what the proposal references.
Five Mistakes That Guarantee Extra Revision Rounds
- Describing solutions instead of problems. “We need a carousel” is a solution. “Users do not see our three main product categories” is a problem, and it may have a better answer than a carousel.
- Hiding the budget. It does not get you a better price. It gets you a proposal for the wrong project.
- Leaving the approver undefined. If the founder’s opinion can overrule everything at any moment, say so in the brief and include them in reviews from round one.
- Treating the brief as decoration. If nobody references it when a mid-project request appears, it was never a brief. When a new idea comes up, the honest response is: “That is not in the brief. Should we add it to scope, with the time and cost that implies, or park it for phase two?”
- Skipping content readiness. I have seen more deadlines missed by unwritten copy than by any design bottleneck.
Copy-Paste Design Brief Checklist
Paste this into a document and fill it in. If you can answer everything here, you are ready to brief any freelance designer with confidence. It is argued more carefully on adobe.com.
- Project name and one-line summary:
- Business model and revenue impact:
- Problem we are solving:
- In scope (screens, pages, breakpoints, files):
- Out of scope:
- Revision rounds included:
- Primary user, device and context:
- Existing research links:
- 3 references (and why) + 2 anti-references:
- Copy status and owner + deadline:
- Images, video, real data availability:
- Brand assets and guidelines links:
- Platform, stack, accessibility and performance requirements:
- Third-party embeds:
- Budget range:
- Hard deadline and what depends on it:
- Final approver (one name):
- Feedback turnaround commitment:
- Primary metric: baseline, target, measurement date:
- Definition of done:
Frequently Asked Questions
What is a design brief example?
A design brief example is a filled-in version of the document above. For instance: “Redesign the onboarding flow of our running app (8 screens, Figma, two revision rounds) to raise onboarding completion from 54% to 75%, for first-time half-marathon runners aged 28 to 45, built in React Native, delivered by 30 October, approved by the Head of Product, budget 7,000 to 9,000 EUR.” That single paragraph already contains goal, scope, user, constraint, deadline, approver and metric.
What are the 7 main specifications of a design brief?
Most short-form templates condense down to seven: project purpose, target audience, scope and deliverables, brand and design requirements, technical constraints, budget and timeline, and success criteria. The nine-section structure in this article splits out content readiness and reference examples, because those two are where freelance projects most often lose time.
How long should a design brief be?
One to four pages. A landing page brief can comfortably fit on one page. A multi-screen product or app brief usually needs three or four. If it is longer than five pages, move the supporting research into linked appendices so the brief stays readable.
Who writes the design brief, the client or the designer?
The client writes the first draft because the client owns the business context. The designer then reviews it, asks questions, and proposes edits to scope, timeline and metrics. The final version is a joint document that both parties agree on before the contract is signed.
Can I use a design brief generator or AI to write it?
An AI tool can produce a clean structure and prompt you with the right questions, which saves time. It cannot supply your churn rate, your users’ objections, your font licences or your developer’s constraints. Use it as a formatting assistant, not as a substitute for the facts only you have.
Does a design brief really prevent scope creep?
It does not prevent new ideas from appearing, and it should not. What it does is make every new idea visible as a decision: add it to scope with agreed time and cost, or move it to phase two. Without a brief, that same idea silently absorbs hours nobody planned or paid for.
Ready to Brief Your Next Project?
A strong design brief usually takes an afternoon to write and routinely saves weeks of back and forth. If you would like a second pair of eyes on yours before you start hiring, send it over. I will tell you honestly which sections are solid, which are too vague to quote from, and what a realistic scope looks like for your budget. Starting a design brief covers this in more depth.