Write a Design Brief Before Discovery Runs Off the Rails

15 minutes Claude.ai Opus 4.7 or Sonnet 4.6By Shadman Rahman

How it works

Step 1 of 6
Someone says 'redesign the checkout.' Full stop.
No constraints, no user context, no definition of done. Just a vague ask with implied urgency.
Step 2 of 6
You paste what you know into Claude.
The Slack message, the exec ask, the feedback from the last user test, whatever context you have. Raw is fine.
Step 3 of 6
Claude asks about users, constraints, and what success looks like.
Three questions that surface the decisions you need to make before you start sketching.
Step 4 of 6
Claude writes a structured design brief.
Problem context, user group, design goals, constraints, out of scope, and open questions. One document that captures the real ask.
Step 5 of 6
You refine until it captures the real ask.
Push back on anything that's wrong. Add the constraint you forgot. Remove the assumption Claude made.
Step 6 of 6
You go into discovery with shared framing.
Designer, PM, and engineering are looking at the same brief. No competing interpretations of what 'redesign the checkout' means.

The prompt

Paste this into Claude.ai with whatever context you have. A Slack message, a complaint from a user test, a note from a stakeholder meeting. It doesn't need to be polished.

Try this promptOpus 4.7 or Sonnet 4.6

I need to write a design brief for [project or feature name].

Here's the context I have so far: [paste the exec ask, Slack threads, user feedback, complaints, whatever you have]

Ask me 3 questions to sharpen the brief, then write one with these sections:

- Problem context (what's happening now that's making this a priority)
- Users we're designing for (who and what they're trying to do)
- Design goals (what a good solution should achieve — focus on outcomes, not solutions)
- Constraints (technical, time, brand, accessibility, anything that limits the solution space)
- Out of scope (explicitly ruled out, so we don't waste discovery time on it)
- Open questions (things we need to learn before we can design confidently)

Keep language concrete. If something in my context is vague, flag it instead of guessing.

What you get back

From Claude

Before I write the brief, three questions:

Who's the primary user for checkout? Your context mentions "users struggling with payment" but also "high drop-off from mobile." Are we prioritizing mobile users specifically, or is this for all channels?
What does "redesign" mean here — the full flow or a specific step? Checkout has 4+ steps: cart, address, payment, confirmation. Or is this a full-flow rethink?
Is there a deadline tied to a business event? Black Friday, a partnership launch, or a product milestone would change how much we can scope.

Assuming: all channels with mobile as primary constraint, full flow but address step has most drop-off, no hard deadline but Q3 is the target.

Checkout drop-off is 63%, above the 45% industry benchmark. Exit data shows the highest abandonment on the address step (41% of total drop-off) and at payment entry (29%). Mobile users account for 58% of traffic but only 34% of completions. The gap between mobile traffic and conversion is the clearest signal.

Users we're designing for

Primary: Mobile users completing a purchase for the first time. Secondary: returning users on any device.

Key behaviors from last research round: users don't trust forms that feel like they were designed for desktop, and they abandon when required fields aren't obvious.

Design goals

Reduce time to complete checkout on mobile by at least 30%
Increase address step completion rate from 59% to 75%
Reduce payment step abandonment from 29% to under 15%
Users should be able to complete checkout in under 2 minutes on a phone with one thumb

Constraints

Existing payment provider (Stripe) stays. No new integrations in this scope.
Accessibility: WCAG 2.1 AA minimum
Brand system applies. No new custom components without design system sign-off.
Engineering: 6-week build window maximum

Out of scope

Guest checkout vs. account creation flow (separate project)
International address formats (phase 2)
Buy-now-pay-later integration (flagged but not this cycle)

Open questions

Do we have session recording of where exactly users pause or go back on mobile?
Is autofill working on address fields? 40% of mobile abandonment on address could be a technical issue, not a UX one.
What's the legal requirement for the confirmation email? It affects how much we can simplify the confirmation step.

Variations

Same shape, different starting points.

For a brief that came from a support ticket, not a strategyOpus 4.7 or Sonnet 4.6

I need to write a design brief based on this pattern of user complaints: [paste support tickets, reviews, or user feedback]

Help me turn this bottom-up signal into a brief that frames the design problem properly. Don't just list the complaints as requirements. Synthesize what the underlying problem is, write a brief around it, and flag what we'd still need to validate before designing.

For redesigning something that already existsOpus 4.7 or Sonnet 4.6

I need to write a brief for redesigning [existing feature or flow].

Current state: [describe what exists now and what's wrong with it]
Business reason for redesigning now: [why this, why now]

Write a brief that includes: what's not working with the current design (and why it was probably fine when it was built), what a successful redesign looks like from the user's perspective, and what we should explicitly preserve from the current version so we don't break what's working.

For a feature that doesn't exist yetOpus 4.7 or Sonnet 4.6

I need to write a design brief for a net-new feature: [feature name and one-sentence description].

We have no existing design to reference. Here's what we know about the problem it solves: [describe the user problem and business context]

Write a brief that identifies: what we know about user needs in this space, what we'd need to research before designing, and what the riskiest assumptions we're making are. Flag anything that looks like a solution disguised as a requirement.

Tips and gotchas

Open questions are more valuable than premature answers. A design brief that says "we need to learn X before we can design confidently" is more useful than one that guesses. Claude will sometimes fill gaps with assumptions: check each one and replace with an open question if it's not actually decided.

Constraints are not the enemy. A brief with no constraints leads to a discovery phase that never ends. Constraints force creative decisions. If you don't have real constraints, list the most likely ones and ask Claude to flag which ones need confirmation.

Watch for solutions disguised as requirements. "The checkout button should be green" is a solution. "Users should see a clear primary action" is a requirement. If the brief is full of the former, ask Claude: "which of these requirements are actually pre-decided solutions? Rewrite them as outcomes instead."

Ready to try?

Copy and pasteOpus 4.7 or Sonnet 4.6

I need to write a design brief for [project or feature name].

Here's the context I have so far: [paste the exec ask, Slack threads, user feedback, complaints, whatever you have]

Ask me 3 questions to sharpen the brief, then write one with these sections:

- Problem context (what's happening now that's making this a priority)
- Users we're designing for (who and what they're trying to do)
- Design goals (what a good solution should achieve)
- Constraints (technical, time, brand, accessibility)
- Out of scope (explicitly ruled out)
- Open questions (things we need to learn before designing)

Keep language concrete. If something in my context is vague, flag it instead of guessing.

Someone says 'redesign the checkout.' Full stop.

You paste what you know into Claude.

Claude asks about users, constraints, and what success looks like.

Claude writes a structured design brief.

You refine until it captures the real ask.

You go into discovery with shared framing.

Workflows