What Is a Design Brief and How to Write One

Most design projects that go wrong do not fail in Figma. They fail before the first screen is drawn, when the client and the design team start work with different pictures in their heads. The client imagines a bold redesign, the designer hears “refresh the homepage”. The marketing lead needs more leads, the CEO wants the site to “look premium”, and nobody writes down which one matters more.

A design brief is the document that prevents this. So, what is a design brief? It is a short, structured description of a design project: why it exists, who it is for, what has to be delivered, what constraints apply and how success will be measured. It is written before work starts, agreed by everyone who will approve the result, and used as the reference point for every decision after that.

This guide explains what to include in a brief, how a brief differs from a creative brief and a technical specification, what changes for websites, apps and branding projects, and how to prepare one step by step. At the end you will find a design brief template you can copy. We use briefs like this at the start of every UI/UX design project, so the structure below comes from real client work.

What a design brief is and why projects need one

If you need a short design brief definition: it is the agreed description of a design task, written in plain language, that tells the team what problem to solve and how to judge the solution. It is not a mood board, not a list of favorite colors and not a contract, although it borrows a little from each.

A good design brief does three jobs.

It creates a shared understanding of the task. Everyone involved, from the founder to the person who will update the website every week, reads the same description of goals, audience and scope. Disagreements surface on day one, when they are cheap, instead of during the third round of revisions.

It protects the project from scope creep. Scope creep is the slow growth of a project through small additions: one more page, one more language, one more user role, “while you’re at it, could you also…” Each addition looks harmless, but together they break timelines and budgets. A brief fixes the project scope in writing, so any change becomes a visible decision rather than a quiet drift.

It is the basis for an estimate. No agency can give a reliable timeline or price without understanding scope, constraints and expectations. The more complete the brief, the more accurate the estimate, and the fewer unpleasant surprises later.

A brief also gives stakeholders a clear point to sign off. When the brief is approved, the team knows who makes decisions and what was agreed.

People new to commissioning design often ask what a design brief is worth if the agency will ask questions anyway. The answer is speed and quality. Without a brief, the first two or three meetings are spent collecting basic information that could have been written down in an hour. With a brief, those meetings go straight to the interesting part: discussing options, risks and priorities. We regularly see projects where a well-prepared brief shortens the start of work by one to two weeks, simply because nobody has to chase missing answers.

There is also a less obvious benefit. Writing a brief forces the client team to agree internally before the agency gets involved. Often the most valuable outcome of the exercise is not the document itself but the conversation it triggers between marketing, sales and leadership about what the project is really for.

Design brief vs creative brief vs technical specification

These three documents are often confused, and on some projects one person writes all of them. They serve different purposes.

Creative brief. Used mainly in advertising and marketing campaigns. It focuses on the message: the single idea to communicate, the audience, the tone, the channels and the call to action. It answers “what do we want people to think and feel?”

Design brief. Used for design work on a product, website, app or brand. It focuses on the problem the design must solve, the users, the scope of deliverables and the constraints. It answers “what do we need to design, for whom, and how will we know it works?”

Technical specification (SRS). Used for development. A software requirements specification describes functions, data, integrations, performance and security requirements in enough detail for developers to build and test. It answers “how exactly should the system behave?”

There is also the statement of work (SOW), a contractual document that lists deliverables, timelines, payment terms and acceptance criteria. On many projects the SOW is based on the brief and the specification.

In practice, a design brief often comes first, the discovery phase turns it into a more detailed scope and, for complex products, into a technical specification. We describe how this transition works in our article on the discovery phase in software development.

What to include in a design brief

This is the core of the document. Each block below lists the questions a client should answer. You do not need long essays. Clear answers of two or three sentences per question are usually enough.

Company and project background

Designers need context to make good decisions. A brief that starts with “We need a new website” leaves them guessing.

Answer these questions:

• What does your company do, who are your customers and how do you make money? (business model)

• How do you want to be perceived compared to competitors? (brand positioning)

• What exists today: a current website or product, its strengths and what is not working?

Include links to the current site or app, analytics access if possible and any previous research. The more the team knows about the starting point, the less time they spend rediscovering it.

Goals and success metrics

This is the block most often filled with vague wishes. “Modern design” and “better user experience” are not goals. Business goals are.

Answer these questions:

• What business goals should the project support? For example, more qualified leads, higher online sales, fewer support requests, entry to a new market.

• Which KPIs will show success, and what are the current values? Conversion rate, number of demo requests, average order value, activation rate.

• What would make you say “this project worked” six months after launch?

A useful filter is SMART goals: specific, measurable, achievable, relevant and time-bound. “Increase demo requests from the website by 30 % within six months of launch” is a SMART goal. “Make the website more attractive” is not.

Target audience

Design is always for someone. Without a clear audience, the team designs for itself or for the client’s personal taste.

Answer these questions:

• Who are the main user groups, and which one matters most for this project?

• What jobs are they trying to get done when they come to your site or app? (jobs to be done, JTBD)

• What are their main user pain points today, and what do they compare you with?

If you have personas from previous research, attach them. If you do not, a few sentences about each group are still far better than nothing. The design team can turn them into proper personas during discovery.

Scope and deliverables

This block defines what will actually be produced. It is the main defense against scope creep.

Answer these questions:

• Which pages or screens are in scope? A draft sitemap for a website or a list of key screens for an app is ideal.

• Which user flows matter most? For example, request a quote, book a demo, place an order, sign up.

• Which design assets do you expect to receive? Wireframes, high-fidelity mockups, a clickable prototype, a UI kit or design system, icons, illustrations, animations.

Be explicit about what is not in scope too. “Blog templates are out of scope for phase one” saves weeks of misunderstanding.

Brand and visual references

Visual preferences are subjective, so the brief should make them as concrete as possible.

Answer these questions:

• Do you have brand guidelines (logo, colors, fonts, imagery rules)? Are they fixed or open to change?

• Are there websites or apps you like, and what exactly do you like about each? Collect them in a moodboard if you can.

• Which competitor references should you look different from, and why?

Lists of likes and dislikes are surprisingly useful. “We like how this site uses whitespace, we dislike stock photos of people shaking hands” gives the designer more direction than “clean and modern”.

Content and technical constraints

Design does not exist in a vacuum. It must work with real content and real technology.

Answer these questions:

• Who will provide content: texts, photos, videos, product data? When will it be ready?

• Which CMS will the website use, or which platforms does the product target (web, iOS, Android)?

• Which integrations are required: CRM, payment systems, booking tools, analytics?

• Are there accessibility requirements, for example compliance with WCAG?

Content is the constraint most often forgotten. Designing without real content leads to layouts that break when actual texts arrive. If you are unsure whether to prepare design or content first, read our article on what comes first, design or content.

Budget, timeline and approval process

Many clients prefer not to mention a budget, hoping to get a better offer. In practice, a budget range helps the agency propose a realistic scope instead of a “dream version” that has to be cut later.

Answer these questions:

• What is the budget range, and is there flexibility?

• Are there fixed dates: a product launch, a trade show, a marketing campaign? What are the key milestones?

• Who are the decision-makers, who gives feedback, and how many feedback rounds are planned for each stage?

The approval process deserves special attention. A project with one clear decision-maker moves several times faster than a project where five people give conflicting comments on every screen. For more on how agencies turn a brief into an estimate, see our project estimation guide.

Design brief examples by project type

The structure above works for most projects, but each type of project needs a few extra details. Below is a short design brief example for each of the three most common types.

Website design brief

A web design brief should add:

• Sitemap. Even a draft list of pages with their hierarchy helps estimate scope and plan navigation.

• CMS. Which system will power the site (WordPress, Webflow, a custom CMS), and who will edit content after launch.

• SEO requirements. Which pages bring traffic today and must keep their URLs, which keywords matter, whether there are multiple language versions.

• Content ownership. Who writes and approves texts, who provides images, who will maintain the site.

For a redesign, add analytics data for the current site: top landing pages, main traffic sources and conversion points. A website design brief without this data often leads to a beautiful site that loses search traffic.

Mobile app design brief

A mobile app brief should add:

• Platform guidelines. Will the app follow iOS Human Interface Guidelines and Material Design closely, or use a fully custom interface on both platforms?

• Onboarding. What should a new user understand and do in the first minute?

• Key user flows. The three to five tasks that define success, for example sign up, complete a profile, make the first booking.

• Device features. Camera, location, notifications, offline mode, biometrics.

For a UX design brief on an existing app, include app store reviews and support tickets. They are free user research.

Branding brief

A branding brief, or a logo design brief for a smaller project, should add:

• Logo. Is it a new logo or a refresh? Where will it be used: website, app icon, packaging, signage, merchandise?

• Visual identity. Which elements are needed beyond the logo: color palette, typography, graphic elements, photo style, templates.

• Tone of voice. How should the brand sound in texts? Formal or friendly, expert or playful?

• Brand architecture. Are there sub-brands, products or services that need their own identity within one system?

A graphic design brief for campaign materials or print usually follows the same logic but with a narrower scope. If you are planning a full identity project, our branding services page shows how we structure this work.

How to prepare a design brief step by step

Knowing how to write a design brief is less about writing skills and more about collecting the right information from the right people. Here is the process we recommend.

Step 1. Collect internal requirements. Before contacting an agency, run short stakeholder interviews inside your company. Ask the sales team what customers struggle with, the support team what they hear every day, the marketing team what they need from the website, and leadership what success looks like. Write the answers down.

Step 2. Run a competitor analysis. List three to five competitors and note what they do well and badly. This gives the brief concrete references and helps you describe how you want to be different.

Step 3. Fill in a brief questionnaire. Use the blocks from this article, or the agency’s own brief questionnaire. Answer every question, even with “we don’t know yet”. An honest “unknown” is more useful than an invented answer.

Step 4. Hold a discovery workshop. For anything larger than a simple landing page, a working session with the design team is the most effective way to finish the brief. In two to four hours, the team asks follow-up questions, challenges assumptions and turns open points into decisions. On complex projects, this grows into a full discovery phase with research, prototyping and a detailed scope.

Step 5. Review and get sign-off. Share the final brief with all decision-makers and collect explicit approval. From this point, any change to goals or scope is a conscious decision that may affect timeline and budget.

If you are wondering how to create a design brief quickly for a small project, steps 3 and 5 are the minimum. Steps 1, 2 and 4 add depth when the stakes are higher.

How long does the whole process take? For a landing page or a small corporate site, a brief can be ready in two or three days. For a larger website, a customer portal or a mobile app, plan one to two weeks, including internal interviews and a workshop with the design team. That time is well spent: it is much shorter than the delays caused by unclear goals in the middle of a project.

One practical tip: keep the brief in a shared document rather than an email thread. Comments, versions and decisions stay in one place, and new people joining the project can get up to speed in fifteen minutes instead of digging through months of correspondence.

Who should take part. A brief written by one person usually reflects one point of view. Involve the people who will judge the result: the decision-maker, marketing, sales or customer support who hear what clients ask, and someone who knows the technical constraints. A one-hour session where these people answer the brief questions together often saves weeks of conflicting feedback later.

Common design brief mistakes

Most problems we see in briefs fall into a few patterns. Each one costs time, money or both.

Vague goals. “We want a modern website” gives no direction and no way to judge the result. The design team makes guesses, the client rejects them, and the project loops through revisions.

Missing success criteria. Without measurable criteria, approval becomes a matter of taste. A project can be “finished” and still fail to move any business metric.

Design by committee. Five stakeholders, five opinions, no final decision-maker. Feedback contradicts itself, and each round adds new requests. The fix is simple: name one person who has the final word, and collect feedback from others before it reaches the design team.

No content plan. The design is approved with placeholder text, then real content arrives late and does not fit. Layouts are reworked, launch slips by weeks.

Too much solution, too little problem. “Add a chatbot, a 3D animation and a dark mode” describes features, not needs. A good brief explains the problem and lets the team propose the best solution.

Hidden constraints. The CMS, a mandatory integration or a fixed launch date appears halfway through the project. Each one can invalidate work already done.

All of these are cheap to fix during the brief and expensive to fix later.

A quick self-check before you send the brief: could a designer who has never heard of your company read it and explain back, in two minutes, what the project is for, who it serves, what must be delivered and how success will be judged? If the answer is yes, the brief is ready. If the designer would need to ask more than a handful of basic questions, the brief needs another pass.

Design brief template

Here is a design brief template you can copy into a document and fill in. It follows the structure described above. The examples are illustrative.

Use it as a checklist as well: if a row is empty, that is a question to answer before work starts. The same format works for internal projects too, when one team in a company commissions design work from another.