Writing a design brief Claude can actually use

Why a brief that would satisfy a human designer can still underperform here

A brief written for a human designer often leans on shared context that gets filled in automatically by someone who's worked with your team, your product, and your visual language for a while — a level of implicit understanding a fresh prompt doesn't have access to at all. A brief that reads as complete to you, because you're filling gaps with context Claude doesn't have, can produce a result that technically follows the letter of the brief while missing what you actually meant, simply because the unstated assumptions behind the brief were never made explicit.

State the actual goal, not just the deliverable

"Design a settings page" describes an output, not a goal — it tells Claude what artifact to produce without saying what that artifact needs to accomplish for whoever ends up using it. "Design a settings page that lets an infrequent user find and change the two or three settings they actually care about without being overwhelmed by everything else available" is a goal, and a goal gives every subsequent design decision something concrete to be evaluated against — what to prioritise, what to de-emphasise, what to leave out — that a bare deliverable description doesn't provide.

Constraints belong in the brief, not discovered during review

Real constraints — technical limitations, brand requirements, accessibility requirements, existing patterns that need to be respected — need to be part of the brief itself, not left for review to catch after a design has already been produced without them in mind. A constraint discovered only during review means redoing work that could have been avoided if the constraint had simply been stated upfront; stating constraints in the brief costs a sentence and saves a full iteration cycle.

Including examples of what "good" looks like for this specific project

A brief benefits enormously from concrete reference points — existing designs from your own product that represent the visual language you want continued, or specific external examples that capture a quality you're after — rather than relying entirely on adjectives to communicate a visual target. "Clean and modern" means something different to every person and every project; a specific example narrows that gap in a way words alone struggle to.

Being explicit about what's flexible and what isn't

Not every element of a brief carries equal weight, and it's worth distinguishing hard requirements from areas where you genuinely want creative latitude — a brief that reads as uniformly rigid forecloses useful exploration on the parts that were actually meant to be flexible, while a brief that reads as uniformly loose risks losing the requirements that actually mattered. Marking which parts are fixed and which are open invites better exploration exactly where you wanted it, without sacrificing the constraints that genuinely needed to hold.

Anticipating the questions a good brief should already answer

Before finalising a brief, it's worth checking it against the questions a thoughtful collaborator would actually ask before starting — who is this for, what should they be able to do that they can't today, what does success look like, what's explicitly out of scope. A brief that already answers these doesn't need a clarifying round before real work can start; one that doesn't will generate exactly those questions anyway, just later and at the cost of a delay that a bit more upfront specificity would have avoided entirely.

Treating the brief as a living document during the project

A brief written once at the start of a project and never revisited stops reflecting reality the moment anything about the project's requirements shifts. Updating the brief as understanding evolves, rather than letting it silently diverge from what's actually being built, keeps it useful as an ongoing reference rather than a snapshot of assumptions that stopped being accurate partway through.