The brief before the build

Good design starts before anything is built, written or launched. It starts with how we frame the problem.

A problem statement is the brief the team works from. A vague one lets the team design for a generic user in ideal conditions. A specific one pushes toward actual users, real constraints and the moments where support matters most. That is the difference between a solution that works in a demo and one that works in a classroom.

Here it is in three moves: before you write, while you write, and after.

1 · Before writingTrace the problem to something your team can influence

Not every problem can be solved from where you sit. Before writing the brief, trace the issue backwards. Use the 5 Whys: ask “why does this happen?” and keep going until you find a link your team can reasonably change.

Example, hypothetical · a national teaching-resource library

Starting problemTeachers do not use the resource library.
Why?Teachers search but cannot find relevant resources.
Why?Resources are not tagged accurately, so search results feel irrelevant.
Why?The tagging interface asks contributors to choose from dozens of tag categories, with no guidance on which ones matter for finding things.
← The product can change this.
Why?There is no content governance defining which tags are required, which are optional, or what good tagging looks like.

Stop at the tagging interface and there is a clear product brief: simplify the experience, reduce required fields, and guide contributors toward the tags that matter for search.

There may still be wider issues, such as content governance or contributor training. Flag those to the people who own them. The brief should focus on the part your team can change, and make the related dependencies visible.

If you trace the chain and your team owns no link in it, the issue may need to go to policy, process or training owners first.

2 · While writingTell one small story: situation, goal, obstacle, so what

A good problem statement tells one small story. A specific user, in a specific situation, trying to achieve something, blocked by what the product does today, with consequences if it isn’t fixed.

SSituation

Who is the user, and where and when does this happen?

Avoid broad labels such as “teachers” or “students”. Be specific about level, context, time pressure, device and confidence with technology.

GGoal

What are they trying to achieve?

The outcome, not the immediate task. The goal is what changes if it works: “intervening early enough to change the result before the deadline”.

OObstacle

What currently stops them?

Name the wall they are hitting. “Teachers need a dashboard…” is a solution wearing an obstacle costume.

WSo what

What is lost if this stays unsolved?

Lost learning time, delayed intervention, abandoned workflows, extra support requests, repeated workarounds.

Anchor each part in evidence where you can: user feedback, interviews, classroom observations, support tickets, or colleagues who work closely with schools.

The same problem, before and after

“Teachers need a way to track which students have completed their assignments.”

Understandable, but too broad. It doesn’t tell the team when the problem happens, which constraint matters, or what kind of response would help. And “need a way to track” is already halfway to a solution.

SituationTeachers managing 3–5 classes of 35–40 students each, usually checking assignment progress during 10-minute breaks between lessons, on a school laptop.

GoalIntervene with students who haven’t started an assignment, early enough to change the outcome before the deadline.

ObstacleThe current flow means clicking into each class to see who has started. Across 3–5 classes, that takes longer than a 10-minute break allows.

So whatTeachers either spend their break clicking through classes, or skip the check and find out about non-submissions after the deadline, when it’s too late to step in.

The revised version tells the team something the first could not: this needs to be fast, scannable and useful across several classes at once. A detailed analytics dashboard may not be the right first move. A simple summary view probably is.

Every detail in a brief should change what the team does next. If it doesn’t, it’s decoration.

3 · After writingTest the brief with five checks before it reaches the room

Before you bring a problem statement into discussion, run it past these. Tick them off against a real brief.

Five checks

Trace. Have we traced the issue to something our team can influence? Evidence. Can we point to where each claim came from? Obstacle. Have we named what is stopping the user, rather than the solution we want? Cost. Have we said what is lost if the issue isn’t solved? Usefulness. Would each detail change what the team does next? If not, it may be decorative.

Take this with you

Trace the problem back until you hit a link your team can change. Brief that link, and flag the rest to the people who own it.
Write one small story: a specific person, a goal that is an outcome, a wall rather than a wish, and a cost.
If your obstacle names a feature, you have written a solution in disguise.

A vague brief doesn’t save time. It moves the arguing to after the build.

Try this week

Rewrite one brief you are working on now, in four lines.

Run the 5 Whys on its problem. Circle the link your team owns.
Write Situation, Goal, Obstacle and So what, one line each.
Strike out every word in the Obstacle that names a feature. Rewrite it as the wall the user hits.
Show the four lines to a colleague and ask what they would build. If they describe your solution, the brief is leading them there. If they describe something better, keep listening.

To mull over

Think of the last feature you shipped. Which of the four parts would its original brief have been missing?
When the link your team can change isn’t the most important link in the chain, is the brief still worth writing?
Who in your organisation owns the links you keep tracing past?