Start with the decision, not the deliverable
A useful design brief gives a team something to decide against. It explains the situation, identifies the people affected and states what a successful result needs to make possible. A list of deliverables belongs in the brief, but it should follow that explanation. Otherwise a team can produce every requested file while leaving the original problem untouched.
Take a small arts venue planning to redesign its event pages. The initial request might be for a more contemporary look. That leaves almost every important question unanswered. Who uses the pages? What are they trying to find? What happens when they cannot find it? A better brief starts with the observation that visitors call the venue because they cannot tell which events are suitable for children or what access arrangements are available.
Gather the material before the meeting
Ask the client for a few real examples: a current page, a typical enquiry, an event with complicated information and the process used to publish updates. Avoid building the brief around an ideal sample. A long title, a cancelled event and an event with several booking options will tell the designer more about the work the system needs to handle.
Invite the people who create and maintain the information, not only the person commissioning the design. A programmer may understand content limitations that the communications lead has never seen. A front-of-house colleague may know which questions recur every week. The briefing conversation becomes more productive when those perspectives meet around actual materials.
Separate observations from interpretations
Write down what the team knows and how it knows it. 'Visitors cannot find access information' is different from 'access information appeared in twelve recent phone enquiries.' The second statement has an identifiable source. The first is an interpretation that may be right, but still needs examination. Keep both visible so later research can test the interpretation rather than quietly treating it as fact.
The Design Council's Double Diamond describes a distinction between discovering a situation and defining the challenge. In a brief, that means recording what is still open alongside what the team has agreed. The document can be specific without pretending every uncertainty has been resolved.
Name an audience and a task
'Everyone' is rarely useful as a primary audience for a particular page. For the venue example, choose a person planning a first family visit. Their task is to find an appropriate event, understand the practical details and reach the booking step. Other audiences still matter, but this definition gives the design team a concrete journey to work through.
Describe the circumstances as well as the person. They may be comparing dates on a phone while travelling. They may need to check whether a companion can use the venue comfortably. The brief should contain enough context to make these needs visible without inventing an elaborate fictional biography. Use details that change a design decision, such as screen size, time pressure or information required before booking.
Define success in observable terms
For a prototype, success might mean that participants can identify an appropriate event, locate access details and explain what happens after booking. That is a workable test. 'The design feels more engaging' can still be a creative ambition, but it is not a complete acceptance criterion. Agree on the tasks that must work and the evidence the team will collect.
Do not set a numerical business target without a way to measure it or a reason to attribute change to this work. If the venue wants fewer calls, first establish which calls relate to the pages and whether staff record them consistently. A brief can include a measurement plan as an output. That is more useful than a confident target based on no baseline.
State the constraints that matter
List the publishing system, required content, access requirements, approval process and any production limits. Explain why each constraint exists when that context would help the designer. A fixed event database is different from a preference for the current page layout. One may be a technical boundary for the project; the other may be open to reconsideration.
Include maintenance. Who will add events? How much time do they have? Which fields can they edit? A beautiful page that depends on a designer rebuilding it every week may be unsuitable for a small team. The brief should make routine use part of the design problem, with a handover exercise that asks staff to publish a realistic event.
Agree on scope and responsibility
Now list the deliverables. For this example, they might include a revised event page template, content guidance, a prototype and a record of user testing. Name who supplies photographs, approves copy and implements the design. State which related pages are outside the current project and how new requests will be considered. These details reduce the chance that an unspoken assumption becomes a late disagreement.
Set review points around decisions. An early review might agree on the information hierarchy. A later one could compare two approaches to the event summary. The final review would check the selected direction against the tasks and constraints already recorded. This is easier to manage than asking stakeholders for general feedback on a nearly finished design.
Write a short version people will use
A brief should be readable in one sitting. Put the problem, audience, desired task and constraints near the top. Move supporting material into clearly named references. Use ordinary language and give examples where a term could mean different things to different people. 'Accessible' needs an agreed meaning and evaluation plan; 'simple' needs a description of what becomes easier.
End the document with open questions and their owners. Perhaps the venue still needs to decide who updates cancellation messages. That question should not disappear inside a meeting note. Assign it to someone and set the point at which the answer is needed. A brief is a working agreement that helps the team proceed with a shared understanding.
Test the brief with someone outside the room
Before design starts, give the brief to a colleague who missed the discussions. Ask them to explain the problem, the audience and the next decision in their own words. If they describe only the requested visual style, the document may be missing the reason for the work. If they cannot tell who approves the result, the responsibilities need another pass.
A studio using MissionDesign as its identity could make this clarity part of its everyday practice. The brief becomes an early example of the studio's judgment: specific enough to guide work, honest about unanswered questions and practical enough to use during a difficult review. The finished design then has a clear story behind it, from the first observation to the last decision.