You receive a message that sounds straightforward:
Can you make bulk role assignment easier before the next admin release? Support says it is confusing. We probably need a modal and better labels. Could you show us mocks next Friday?
But what exactly has been agreed?
The message does not confirm the user problem, the intended outcome, the scope, the strength of the evidence, the constraints, the decision owner, or what the Friday review is supposed to decide. Starting immediately may feel responsive, but it could also turn an untested solution into the assignment before the team has aligned on the work.
A useful design brief closes that gap. It translates the request without silently upgrading assumptions into facts. It makes uncertainty reviewable and gives the right people a clear opportunity to confirm or correct the work before design effort compounds.
Why a clear-sounding request may still be risky
Vague requests are not always vague in their wording. Some are specific about the wrong things.
“Add a modal” is specific about a treatment. “Show mocks Friday” is specific about a date. Neither statement explains the underlying problem or the decision the work needs to support.
Before designing against a request, look for seven elements:
- Problem and reason: What needs to change, and why?
- Desired outcome: What should become easier, clearer, safer, or more effective?
- Users and context: Who experiences the problem, and when?
- Evidence and uncertainty: What is supported, assumed, or unknown?
- Proposed solution: What treatment has been suggested, approved, or validated?
- Scope and constraints: What is in, out, fixed, restricted, or dependent?
- Decision and follow-through: Who can confirm the work, what is next, and what happens afterward?
If several of these are missing, the request may be ready to clarify, but it is not yet ready to execute.
Separate the problem from the proposed solution
Solution-first requests are normal. Stakeholders often communicate through the most concrete idea available to them. The proposed solution is still valuable input, but it should not automatically become the problem statement.
Proposed solution: Add a confirmation modal and revise the labels in the bulk role-assignment flow.
Working problem: Enterprise administrators may not understand which members are selected, what role will be applied, or whether the change was saved.
The second statement creates room to examine the actual experience. It also uses “may” because the available evidence has not yet been described. Once the team reviews support signals, research, analytics, or other relevant sources, the problem statement can become more precise.
Three questions help prevent premature solution lock-in:
- What observed condition is the proposed solution intended to change?
- What evidence supports that condition?
- If the proposed treatment were removed from the request, would the underlying problem still be clear?
If the answer to the third question is no, clarification should come before design exploration.
Label what you know before you make it sound complete
A polished brief can hide weak inputs. Use simple evidence labels to keep the draft honest:
| Label | Use it when |
|---|---|
| Confirmed | The statement is explicitly supported by a supplied source or documented human confirmation. |
| Assumption | The team believes the statement may be true, but it has not been verified. |
| Inference | The statement is a reasoned interpretation of the available inputs. |
| Unknown | Important information is missing, unclear, or conflicting. |
For example, “Support received 18 tickets mentioning selection or save-state confusion” may be confirmed by a support summary. “The issue affects most enterprise administrators” is not confirmed by that number alone. It would need separate evidence.
A brief should preserve the limits of each source instead of blending every input into one confident narrative.
Use the BRIEF check
The BRIEF check is a fast way to diagnose whether a request contains enough context for a useful next step.
B: Boundary
What is in scope, out of scope, constrained, or still open? Include technical, accessibility, policy, content, timing, and staffing boundaries when relevant.
R: Reason
What problem or outcome is driving the request? Keep the reason separate from the requested feature, screen, or treatment.
I: Information
What evidence exists? What is confirmed, assumed, inferred, or unknown? Which source supports each material claim?
E: Executive decision
Who can confirm the scope, priority, and readiness of the work? “Executive” refers to decision authority, not necessarily a senior title. Confirm the person with the team rather than inferring authority from an org chart.
F: Follow-through
What decision comes next? What artifact is needed to support it? What happens after confirmation, and who owns that action?
Take one recent request and write one sentence for each letter. If you cannot answer a letter without guessing, turn that gap into a confirmation question.
Build a minimum viable design brief
The goal is not to create the longest brief. It is to create the smallest artifact that lets the right people understand, correct, and confirm the work.
Use this structure:
- Request playback: Restate what was requested without changing its meaning.
- Working problem and desired outcome: Describe the condition to investigate and the change the requestor wants.
- Users and context: Identify who is affected and when the problem occurs.
- Evidence basis: List the relevant sources, what they support, and what they do not support.
- Proposed solution: Preserve the requested treatment as a proposal unless it has been approved.
- Scope and constraints: Separate what is included, excluded, fixed, and unresolved.
- Deliverable and decision: Name what will be produced, what decision it supports, who owns that decision, and when it is needed.
- Assumptions and open questions: Make uncertainty visible and prioritize the questions that block progress.
- Recommended next step: Ask for a specific confirmation, correction, or decision.
The brief should be easy to review in a few minutes. If the team needs a separate workshop to understand what the document is asking, the brief is probably carrying too much information or too little decision clarity.
Composite example: From Slack request to reviewable brief
Example note: The following company, people, product, dates, and evidence are fictional. The scenario is a composite created to demonstrate the method, not a customer result.
Maya, a senior product designer, receives this message from Aaron, a product manager:
Can you make bulk role assignment easier before the October admin release? Support keeps hearing it is confusing. Engineering has time next sprint. Priya wants a cleaner flow, probably a modal and better labels. Could we see mocks next Friday?
Maya applies the BRIEF check.
| Check | What the request provides | What still needs confirmation |
|---|---|---|
| Boundary | October release and possible engineering capacity | In-scope moments, out-of-scope system changes, technical and accessibility constraints |
| Reason | “Easier” and “confusing” | The observed problem, affected users, and desired outcome |
| Information | A general support signal | The source, strength, limits, and any research or product evidence |
| Executive decision | Priya is mentioned | Whether Priya is the decision owner and who reviews design quality and feasibility |
| Follow-through | Mocks next Friday | The decision expected Friday, appropriate fidelity, and what follows the review |
Draft design brief
Status: Ready for confirmation
Working title: Clarify bulk role assignment
Requestor: Aaron, Product Manager
Decision owner: Unknown
Request playback
The team is requesting design support to make bulk role assignment easier before the October admin release. The request proposes a modal and revised labels, with mocks requested for next Friday.
Working problem and outcome
Enterprise administrators may lack clarity about who is selected, what role will be applied, or whether the change was saved. The intended outcome is a bulk assignment experience that administrators can understand and complete with confidence. Both statements require confirmation against the available evidence.
Evidence basis
A general support signal was mentioned, but the source, volume, time period, and limits were not supplied. No user research or analytics were included with the request.
Proposed solution
A modal and revised labels are possible directions. They are not yet confirmed requirements or validated solutions.
Scope and constraints
The October release is a stated timing boundary. The affected steps, excluded system changes, existing patterns, engineering constraints, and accessibility requirements are unknown.
Deliverable and decision
“Mocks next Friday” is requested. The expected fidelity, reviewer, and decision the review should enable are unknown.
Questions that block execution
- What user behavior or support evidence defines the problem?
- Which parts of the flow are in scope, and what is explicitly excluded?
- What decision must the Friday review enable?
- Who owns that decision?
- What technical, accessibility, content, localization, or timing constraints must the work preserve?
Recommended next step
Confirm the problem, scope, Friday decision, decision owner, and constraints before committing to a design direction.
Human-reviewed confirmation message
Hi Aaron, I played the request back in a short brief so I can work against the right outcome. My current read is that enterprise admins may need clearer feedback about who is selected, what role will be applied, and whether the change saved. I have kept the modal and label changes as possible directions rather than confirmed requirements. Before I begin, could you help confirm the evidence behind the problem, what is in and out of scope, the decision we need next Friday, the expected fidelity, and who owns that decision? I will update the brief with those answers and flag any remaining constraints before moving into concepts.
The draft is ready for confirmation because it gives the accountable people something specific to correct.
Know when the request must remain blocked
Some gaps can be resolved with a short conversation. Others are stop conditions.
Imagine a request to paste identifiable customer transcripts, unreleased security findings, or other restricted material into an AI tool that the employer has not approved. The requestor also asks the designer to skip the required privacy, security, research, or accessibility process to meet a deadline.
That request remains blocked. The designer should not enter the information, use the brief as a workaround, or let a generated artifact imply that required review occurred. The next step is to move the work into the approved environment and involve the accountable specialists.
A concise blocked status should name:
- The condition preventing responsible progress
- The person or function needed to resolve it
- The minimum safe next step
- What work, if any, can continue without crossing the boundary
Use a human confirmation gate
Every draft should have a readiness state that describes the actual work condition:
| State | Meaning |
|---|---|
| Blocked | A critical conflict, policy issue, missing owner, missing problem, or missing evidence prevents responsible progress. |
| Ready for confirmation | The draft is coherent enough for stakeholder review, but one or more people still need to confirm it. |
| Ready to begin | A human reviewed the brief, the decision owner confirmed it, and the minimum start conditions are documented. |
An AI-generated draft cannot move itself to Ready to begin. That status requires a human decision and a record of the confirmation.
Where AI can help, and where it must stop
AI may help organize supplied information, identify contradictions, separate evidence from assumptions, draft clarification questions, and format a confirmation message. It can reduce the friction of creating the first reviewable artifact.
It must not:
- Invent evidence, users, requirements, dates, owners, metrics, or agreement
- Treat a stakeholder preference as a validated user need
- Infer decision authority from a title
- Declare the work approved or ready based on its own confidence
- Receive restricted information in an unapproved environment
- Replace user research, accessibility review, privacy review, security review, legal review, or accountable product and design judgment
Keep access to the original sources and verify every material claim before sharing the brief. The designer remains accountable for the framing, evidence boundaries, professional judgment, and final readiness decision.
Turn the method into a repeatable workflow
The BRIEF check can help you diagnose a request quickly. A repeatable system becomes more useful when the work is high-stakes, the source material is fragmented, or the same clarification work keeps appearing across projects.
Workflow 1 inside DesignMinder™ adds the required-input template, copy-paste prompt, source labels, defined brief structure, readiness states, human-review checklist, failure conditions, and a completed example from raw request through human approval.
It is part of the DesignMinder AI Operations Starter Kit for Designers, a six-workflow system for the work around design. It is designed to help you turn unclear inputs into reviewable artifacts without giving up professional judgment.
Get the Complete Request-to-Design-Brief Workflow
Explore the DesignMinder™ Workflow
Founding Edition: $49.99. Digital product for individual use. ChatGPT access is not included. Review the product page for the complete package, license, and refund terms.
Frequently asked questions
What is a UX design brief?
A UX design brief is a shared working artifact that describes the problem or opportunity, desired outcome, users, evidence, scope, constraints, deliverables, decision rights, timing, risks, and open questions for a design effort. Its purpose is to make the work reviewable before the team commits significant effort.
How long should a design brief be?
Use the shortest format that allows the accountable people to understand, correct, and confirm the work. For a bounded request, a concise brief that can be reviewed in a few minutes may be enough. More complex work may require linked evidence or supporting records rather than a longer central document.
What if the stakeholder has already requested a specific solution?
Preserve the requested solution as input, but separate it from the working problem unless the treatment has been formally approved. Ask what condition the solution is intended to change and what evidence supports that framing.
Can AI write a design brief for me?
AI can organize supplied inputs, identify gaps, and draft a reviewable brief. It cannot verify facts it was not given, establish decision rights, approve the work, or replace the designer and accountable stakeholders. A human must review the draft against the original sources and confirm readiness.
When should a design request remain blocked?
Keep the request blocked when a critical problem, owner, evidence source, policy requirement, or specialist review is missing, or when progressing would require using restricted information in an unapproved environment. Name the blocking condition and the safe next step instead of filling the gap with an assumption.