Write a design brief that leaves room to solve the problem
Define a studio-service project through purpose, task, constraints, evidence, deliverables, decisions, and review conditions while distinguishing requirements from a predetermined solution and unsupported audience assumptions.
Provide direction without prescribing every answer
A design brief gives a project enough direction to begin without pretending every answer is already known. For a studio-service improvement, it should explain the problem, the people and circumstances in scope, and the practical boundaries. A list of desired screens is useful only after the team understands what those screens need to accomplish.
Separate requirements, preferences, and questions
Separate confirmed requirements from preferences and open questions. Identify operational constraints, available evidence, decision owners, and expected deliverables. State how the work will be reviewed without inventing performance results in advance. Include access and content needs early so they do not become optional additions after the visual direction is settled. Choose a level of detail that supports the current decision without turning preparation into a substitute for action. Too little detail leaves collaborators inventing the missing conditions; too much can make an uncertain proposal look settled. State the boundaries and name the questions outside them. If another discipline owns an important condition, involve that person early instead of treating the design document as permission to invent an operational answer.
Brief a preparation-information project
Draft a brief for improving workshop preparation information. Describe the intended task, current uncertainty, service owners, and possible outputs such as a content model and prototype. List the information the team still needs about materials, access arrangements, and update responsibility. Keep a proposed app or page structure as an option unless it is a real constraint. Keep a brief record of the conditions used for the exercise: the task, information available, roles involved, and artifact version. This makes a later revision easier to compare without relying on memory. Capture questions in the moment, but resist converting every comment into a requirement. Afterward, decide which questions concern the method, which concern the proposed product, and which require an operational owner before work can continue.
Replace vague ambitions with decisions
If the brief says modern and engaging but names no task, ask what a person should be able to do differently. If it includes unsupported demographic claims, replace them with known circumstances or research questions. If every requirement is mandatory, discuss priorities and dependencies before the designer tries to satisfy incompatible expectations. When the activity produces ambiguity, identify whether the problem lies in the question, the material, the facilitation, or an unresolved product decision. Changing the visual format alone may leave the same uncertainty intact. Return to the purpose and repair the relevant part. Record the change and its reason so collaborators can distinguish a clearer method from a genuinely different interpretation of the underlying evidence.
Agree authorization and review conditions
Review the brief with everyone responsible for approving or delivering the work. Confirm what decisions it authorizes and what must return for review. Keep changes to scope and assumptions traceable as the project develops. A useful brief makes the starting conditions clear while preserving room for evidence and design exploration to improve the proposed approach.
Worked decision
Separate the required outcome, reliable preparation information, from an optional solution, a dedicated app. The brief can authorize exploration without predetermining its form.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
