Most briefs I receive are not design briefs. They're business requests dressed up in design language — vague outcome statements, implicit constraints that nobody thought to make explicit, and a stated user need that is usually three layers removed from what users actually need. My job has always been to translate. What's changed is that I now have a collaborator that can help me do the translation faster and more rigorously.
The Problem with Briefs as They Arrive
A typical brief might read something like: 'We need to improve the onboarding experience for new enterprise customers. The current flow has too many steps and customers are dropping off. We want something simpler and faster.' That sounds clear. It isn't. It doesn't tell you what 'simpler' means to the customer versus the business. It doesn't tell you whether the drop-off is because there are too many steps or because the wrong steps are in the wrong order or because the value isn't being communicated early enough. And it doesn't tell you what constraints exist that will prevent the obvious solutions.
When you're working with multiple stakeholders, you also get multiple briefs that contradict each other in ways nobody has named. The product team wants fewer steps. The legal team has mandated three screens of consent. The sales team wants the product tour front and centre. Nobody has resolved these tensions — they've just handed them to design.
How I Feed Material to Claude
My starting prompt is almost always a request for contradiction-finding. I paste in the brief, meeting notes, and any relevant background, then ask: 'Identify every place where these requirements contradict each other or where a stated goal conflicts with a stated constraint. Be specific — point to the exact language.' This surfaces the tensions that would otherwise take another week of stakeholder meetings to uncover.
After that, I ask for a reframe: 'Based on what's here, what is the actual user problem this is trying to solve? Not the business problem — the user problem. Write it as a single sentence.' The output is rarely perfect but it gives me something to react to, and the reaction is usually more honest than what I'd produce if I were writing cold. I edit it, refine it, and share it with stakeholders as a conversation starter rather than a conclusion.
I also ask Claude to identify what's missing — assumptions that have been made but not stated, stakeholder perspectives that appear to be absent, user segments that the brief doesn't address. Requirements documents are often notable for what they leave out, and having a structured checklist of gaps is genuinely useful going into a scoping conversation.
What Good Prompts Look Like for This Work
The prompts that work best for requirements analysis are precise about what you want and how you want it structured. 'Summarise this' produces noise. 'List the top five tensions between stated business goals and user needs in this document, ranked by how likely each is to create a design constraint, with one sentence explaining each tension' produces something usable.
Context matters as much as the instruction. I tell Claude who the users are, what the business context is, and what the design team's constraints are before asking any analytical questions. An AI working without context will produce generic output. The more situated the prompt, the more useful the output.
I also ask for confidence levels. 'Which of these interpretations are you confident about based on what I've provided, and which are inferences that need validation?' This distinguishes what the brief actually says from what Claude is extrapolating, which matters when you're using the output to inform conversations with stakeholders.
What This Changes About the Design Process
The biggest impact isn't speed — it's that I go into scoping conversations better armed. When a stakeholder says 'we want it simpler', I can now come back with: 'Here are three interpretations of what simpler might mean in this context, and here's the trade-off each one creates for the other constraints you've named. Which of these is the version you're optimising for?' That's a more productive conversation than the one where I nod and go away to interpret it myself.
The AI doesn't make me a better designer. It makes me a more prepared one. And going into a design process prepared — with tensions named, assumptions surfaced, and the real problem identified — is most of what determines whether the work is good.
