Reading a Brief Before You Design Anything

UI/UX · ~7 min read

A brief arrives. It is three paragraphs long, mentions "modernising the experience", and includes a deadline. The temptation is to open a design tool immediately and start pushing rectangles. Resist it. The first two hours you spend reading, questioning and reframing a brief will save you two weeks of rework, because most design failures are brief-reading failures wearing nice clothes.

Separate the problem from the proposed solution

Almost every brief is written by someone who has already decided what they want built. They describe a solution — "add a dashboard", "redesign the sign-up flow", "make it feel premium" — when what you actually need is the problem underneath it. Your first job is translation.

Take each request and ask "why" until you hit something measurable. If the ask is "add a dashboard", the underlying problem might be "support agents cannot see which accounts are at risk, so they miss churn signals". That reframing changes everything: a dashboard may not be the answer at all. A digest email, a sortable list, or an alert threshold might solve it faster and cheaper.

• Stated ask: what the brief literally requests.
• Business goal: the number the organisation is trying to move (revenue, retention, support cost, activation rate).
• User goal: the job the person is actually trying to complete.
• Success signal: how you will know it worked, in observable terms.

When these four do not line up, that misalignment is the most valuable thing you can surface in your first week — not a mock-up.

Hunt for constraints, they are your real brief

A brief without constraints is not a brief, it is a wish. Constraints are what turn an open-ended problem into something designable. Dig them out early and write them down in plain language.

Put a number on each where you can. "Fast" is useless; "first usable prototype in ten working days" tells you whether to draft three flows or one.

Interrogate the audience

Design decisions are only good relative to a person. A flow that delights a first-time visitor can infuriate a power user who runs it two hundred times a day. Before choosing anything, get concrete about who is on the other side of the screen.

• Who exactly? Age, context of use, device, and — most underrated — their level of patience.
• Where are they? A warehouse floor on a dim handheld, or a quiet desk with two monitors?
• How often? Once, monthly, or continuously as part of their job?
• What do they already know? Domain jargon they expect versus terms they would have to learn.

Frequency is the single most useful dimension. Daily-use tools reward density, keyboard shortcuts and information-rich screens. Occasional-use flows reward clarity, obvious signposting and generous whitespace. Choosing wrong here produces a product that feels either patronising or overwhelming.

Write your own one-page reframe

Before touching a canvas, produce a single page that captures what you understand. This becomes the shared source of truth and the thing you will be held to. It should fit on one screen and contain, in order:

1. The problem statement in one sentence, no jargon.
2. The primary user and their job to be done.
3. Three constraints with numbers where possible.
4. Definition of done — what observable change signals success.
5. Open questions — the things you are still guessing about.

If a stakeholder reads this and says "that is not what I meant", you have just saved yourself a fortnight for the price of an afternoon. That is the whole point.

Turn unknowns into a research plan

Your open questions are a to-do list. Rank them by how much they would change your design if answered. The few that would change everything deserve attention now; the rest can wait.

• Answer with evidence where it exists: analytics, support tickets, search logs, session recordings.
• Answer with conversation where it does not: five interviews beat fifty survey responses for behavioural questions.
• Answer by prototyping when the question is about a specific interaction and no prior art exists.

Only after this do you draw. Now your rough layouts are targeted at a defined problem, which is why they will actually be useful.

Decide what you are not doing

Scope is defined as much by exclusion as inclusion. A brief that lists only what to build will balloon, because every reviewer adds "and while you are in there...". Argue for an explicit out-of-scope list in your reframe, and get it agreed in writing.

Write it as plain denials: "this project will not touch billing screens", "we are not designing the mobile app in this phase", "no changes to the onboarding emails". Each line you agree is a line nobody can quietly add later.

• Must: the smallest thing that solves the problem.
• Should: valuable, if time allows.
• Could: worth noting for a later phase.
• Won't: explicitly excluded, and why.

That four-part split — fixed, flexible, optional, excluded — turns a vague wish into a plan you can defend. When a late request arrives, you point at the list rather than at your memory, and the conversation becomes about priority rather than personality.

A brief-reading checklist

Read the brief, then run through these questions before you design:

• What is the measurable business outcome?
• Who is the primary user and how often will they use this?
• What are the top three constraints, with numbers?
• What is explicitly out of scope?
• Who signs off, and who else will comment late?
• What would make this project a failure?

That last question is quietly powerful. People find it easier to describe failure than success, and the answer usually reveals the real fear driving the project. Design against the fear, and you have a brief worth designing to.