Free Website Audit: Discover what's holding your digital presence back
Short answer
A useful design brief defines the business problem, audience, desired change, evidence, constraints, deliverables, decision-maker and timing. It should explain why the work matters and what is already known while leaving room for the design team to explore solutions. A brief is ready when another team can understand the decision without a private meeting.
A design brief is a decision document, not a request for a certain colour, layout or trend. It gives the team enough context to solve the right problem and enough boundaries to work responsibly.
Owners and marketing leads often write briefs while juggling sales, product and operational knowledge. The answer is not a longer document. It is a document that separates facts, assumptions, constraints and decisions. Konzept’s design systems service can help when a brief needs to support a wider family of pages, components or product journeys.
What should a design brief answer first?
The brief should answer what needs to change, for whom and why now. Put those answers at the top so the team can test every later decision against them.
Write the problem in observable terms. For example, people may not understand which service fits them, staff may repeat the same explanation, or a product flow may stop at a particular decision. Avoid defining the problem as a solution such as make the page modern or add a dashboard.
State the business reason without promising an outcome you cannot prove. The work may support clearer qualification, a launch, a migration, a new market or a more maintainable interface. If the reason is uncertain, label it as a hypothesis and say what evidence would change your view.
How do you define the audience?
Define the audience by the situation and decision they face, not only by age, job title or industry. A procurement lead, founder and operations manager may all visit the same page with different questions.
Include what the audience already knows, what they need to decide, what may stop them and what action is available. Add language, market and accessibility needs when they affect the work. A company serving Bosnia and EU clients may need to decide whether content, proof and contact paths should differ by market.
If you have research, analytics or customer-service notes, summarise the relevant evidence and link to its internal location. If you do not have evidence, do not invent a persona. Mark the assumption so the team can validate it during discovery.
What constraints belong in the brief?
Constraints belong in the brief when they affect feasibility, quality or ownership. Include platform, integration, content, legal, accessibility, security, brand, language, deadline and team constraints.
Distinguish a fixed constraint from a preference. The CMS may be fixed for a migration. A preferred layout may change after testing. This distinction prevents a team from treating an early idea as a requirement and prevents stakeholders from being surprised by a necessary trade-off.
Use a table that makes the boundary visible:
| Brief element | Useful question |
|---|---|
| Fixed | What cannot change for this phase? |
| Flexible | What can the team explore? |
| Known | Which facts or decisions are already confirmed? |
| Unknown | Which assumptions need research or review? |
| Dependency | Who or what must be ready first? |
How should you describe deliverables?
Describe deliverables by the decisions and assets the team must produce, not by a vague request for a full redesign. A deliverable may be a journey map, content model, component set, prototype, page templates, design tokens, implementation guidance or a handover record.
Say what is out of scope. If the brief covers a service page family, say whether it includes copy, development, SEO, analytics and post-launch support. If the scope is still open, describe the decision the discovery phase must make.
The design systems page is useful when the work needs reusable rules rather than a single visual screen. A website migration guide can help when a redesign also changes URLs, content ownership or technical structure.
Who makes decisions and how will review work?
Name one accountable decision-maker and the people who provide specialist input. A group can contribute evidence, but the team needs one person who can resolve conflicting feedback.
Define review points before the work begins. Decide what is being reviewed at each stage, how feedback is collected, when it is due and what counts as approval. Review a wireframe for structure, a prototype for task clarity and a final system for implementation readiness. Do not ask every stakeholder to judge every detail at every stage.
Include access to content, analytics, product knowledge and technical constraints. Design cannot make a useful decision when the team cannot inspect the current journey or speak to the people who operate it.
How do you know the brief is ready?
The brief is ready when a capable team can describe the problem, audience, scope, decision process and next step without guessing. Read it as someone who was not in the kickoff meeting.
Check these questions:
- Can the team tell which problem matters most?
- Can it separate evidence from assumptions?
- Can it identify the owner and approval path?
- Can it see what is fixed, flexible and out of scope?
- Can it explain what will be delivered and handed over?
If the answers are unclear, shorten the brief by removing repetition and add the missing decision. When you want a second view before commissioning the work, book a call with the current brief and the questions your team cannot settle.
FAQ
How long should a design brief be?
It should be long enough to preserve the important context and short enough that the team will use it. A focused brief can fit on a few pages when the problem and scope are clear. A complex product or regulated service may need supporting documents, but the brief should still summarise the decision, audience, constraints, owner and deliverables in one place.
Should a design brief include a solution?
Include ideas as hypotheses, not as instructions, unless a real constraint requires a specific solution. A brief that demands a particular screen can hide the underlying problem and prevent better options. Explain what you have considered, why it may help and what remains open. Let the team test whether the proposed solution fits the audience and system.
Who should write the design brief?
The person who owns the business problem should lead it, with input from the people closest to customers, content, operations, technology and compliance. A designer can improve the brief, but should not have to reconstruct basic business context after work starts. Shared authorship is useful when one person remains accountable for the final version.