Thinking

The Brief Is Rarely the Whole Problem

Process·May 1, 2026·2 min read

It asked me to improve the reporting flow, which sounded perfectly clear right up until I looked at the reporting flow.

The flow was fine. The problem was that people didn’t trust the numbers inside it and had no idea what to do with them. You can redesign that screen as many times as you like and nobody will trust those numbers one bit more. They’ll just distrust them in a nicer font.

To be fair, whoever wrote it wasn’t doing anything wrong. That’s just how briefs get made. Someone sees a number drop and has a theory about why, and the theory becomes the brief. Nobody goes back to check it, because everyone’s busy, so by the time it reaches a designer, a hunch from a meeting has turned into a Jira ticket with a due date.

A brief loses information at every stepFrom what someone noticed to the brief you’re handed
Observation
Something is noticed: a metric, a complaint, a gap
Interpretation
Filtered through the observer's frame of reference
Mental model error
Constraints
Assumptions about scope, time, and feasibility applied
Assumed, not verified
Brief
A described solution to an interpreted problem
May answer the wrong question
Something gets lost at every step, so by the time the brief arrives the original observation is a few translations away.

So now I ask one annoying question before I touch Figma: is this even the right problem? In real life it looks a lot less heroic than it sounds.

Mostly it’s me asking where a claim came from. "Users find this confusing." Which users? Can I watch one being confused? Sometimes there’s a recording. Sometimes it turns out someone’s cousin said it at a family lunch.

Do

Each finding links to what was seen

Research findings

Finding

Users find the reporting flow confusing.

Usability test of the reporting flow · 8 participants · 4 to 6 March 2026

Seen in 3 of 8 sessions

  • Participant 2 · 14:32 in the recording

    "Is this total for March, or for the whole year?"

  • Participant 5 · 08:15 in the recording

    Went back to the date filter twice before reading the total.

  • Participant 7 · 21:47 in the recording

    "I’d have to check the dates in the export before I sent this to anyone."

The other 5 read the totals without hesitating.

The claim led to the study, the 3 sessions where it happened and the time in each recording.

Illustrative example

Don’t

The claim has no source

Ticket

REP-214 · Improve the reporting flow

Priority
High
Due
28 March

Description

Users find the reporting flow confusing.

Raised in the Q1 planning meeting.

No study, sessions or recordings are linked.

The claim led to a planning meeting. Nothing shows who was confused, or how many.

Illustrative example

The rest is checking whether the business problem and the user problem are still holding hands. Usually they are. Sometimes they break up without telling anyone.

Please don’t become the designer who interrogates every brief like it’s a suspect, though. Plenty of briefs are great. Ask, listen, and if it holds up, get to work.

In the reporting project, it finally clicked in the third user session. A user read the dashboard, understood it, and then just sat there. They were waiting for some sign that the numbers were worth acting on, and the product never gave them one. I remember being relieved and a bit annoyed, because now I knew, and it was my problem.

They needed help deciding. A prettier report would have let them wait in style.

For me, that’s most of the jump to senior. At some point, checking the question becomes part of your job. You won’t always win that conversation, and sometimes nobody will invite you to it. Ask anyway. A slightly awkward meeting beats six weeks of gorgeous work on the wrong thing.

The same bad brief gets three different outcomesWhat changes at each level
LevelPrimary moveFocusWith a bad brief
JuniorSolves the problem they're givenExecutionExecutes a bad brief correctly
Mid-levelSolves the problem wellCraftExecutes a bad brief excellently
SeniorAsks if it's the right problem firstFramingCatches the brief's errors before they ship
What changes with seniority is who owns the problem definition, and craft stays roughly where it was.