The brief is never the problem
A brief is a solution somebody already chose. Five field studies on Indian farms, all of them ending somewhere other than where the brief pointed, and the four habits that get you from the stated problem to the real one.
A storm flattens a rice field. The crop is still there, just lying against the soil instead of standing up. The obvious brief writes itself: the farmer needs a better sickle.
I spent a morning watching him instead. He was not struggling to cut. Every bundle went the same way. Bend, find the crop, grab, lift it clear of the mud, cut, move, bend again. A few steps later, the same seven movements.
The blade was fine. He was spending the day lifting, not cutting.
The problem was not the cut. It was the lift. That sentence is the entire project, and it is not in the brief.
A brief is a solution somebody already chose
This is the useful way to read any request that lands on your desk.
"We need a better sickle" is not a problem statement. It is a solution, arrived at by somebody who has already done some thinking, compressed that thinking into a noun, and handed you the noun. The thinking is the part you need and the part that got thrown away.
The same is true of "we need a dashboard", "we need to redesign onboarding" and "we need an AI feature". Each is a reasonable answer to a question nobody has written down.
Your first job is to recover the question. Not because clients are wrong, they usually are not, but because the compression is lossy, and what falls out is exactly the constraint that decides whether the solution works.
Watch the work, do not ask about it
People are unreliable narrators of their own habits. Not dishonest, just compressed in the same way the brief was. Ask someone to describe their process and you get the version that makes sense in a sentence, with every workaround sanded off, because the workarounds stopped feeling like workarounds years ago.
So I watch. And I watch the thing that actually happens rather than the thing that gets talked about.
The pattern that has paid off most often is looking for the movement that repeats. Anything a person does hundreds of times a day has been optimised by them already, which means whatever is left is a real constraint, not a habit they could drop. It is also where the cost is, because a two-second annoyance repeated four hundred times is not a two-second annoyance.
Follow one thing all the way through
The other habit worth stealing: pick one unit and follow it end to end, instead of studying the system as a whole.
One tomato. One defect. One bundle. One invoice.
Systems look reasonable when you describe them at the level of stages. They stop looking reasonable when you trace a single item through every stage and count what happens to it.
On a vegetable farm I followed one crate. Harvest, temporary basket, the farmer's hands, a larger crate, the transport cart. Five stages, and the produce was lifted and poured at nearly every one, across a distance of twenty metres. Described as a workflow that sounds fine. Traced as one crate it is absurd.
The farmer was not transporting produce. He was transporting containers.
A variant that works in software: ask someone to show you the last thing they submitted, then find out what happened to it. If they cannot answer without leaving the tool and asking a colleague, you have found something real, and it is almost never the thing the brief was about.
Five fields, the same shape of mistake
I ran five of these studies on Indian farms. What is striking is not that the briefs were wrong. It is that they were wrong in the same direction every time.
| The obvious brief | What was actually happening |
|---|---|
| Build a better sickle | Every bundle began on the ground, so the job was lifting, not cutting |
| Help the picker carry more | The picked fruit was being handled three times before it left the field |
| Grade the ginger so the planter accepts it | The planter was demanding uniformity from a crop that does not grow uniform |
| Get a better cart for the twenty metres | The distance was fine. Changing containers five times was not |
| Make the sorting faster | Heavy, light, long and small material already moved differently. Nobody was using that |
Each real problem sits one level underneath the stated one. Each brief is a solution aimed at the visible symptom. And in each case the useful design followed immediately once the framing moved, because the hard part had already been done.
That is the argument for the research. Not thoroughness for its own sake. Framing is leverage, and it is cheaper to find than the alternative, which is building the wrong thing well.
What it costs, and when not to bother
This is not free and it is not always right.
It costs days, sometimes a week, before anything visual exists. On a project with a fixed and modest budget that is a real trade, and a client who expected screens on Friday will feel it.
Skip it when the problem genuinely is the surface. A marketing page, a visual refresh, a brand direction, a screen whose flow is already settled and whose job is to look credible. Reframing is wasted effort when the frame is correct.
Do it when the stakes are in the workflow rather than the interface. Anything people use daily, anything with a handoff between two roles, anything where somebody has already built a workaround. Workarounds are the reliable signal. They are a user telling you where the product failed, in the only language available to them.
How to tell if it is happening on your project
If you are hiring for this and want to know whether you are getting it, the tell is not in the deliverables. It is in what comes back in week one.
A designer doing this work returns with a restated problem, and the restatement is slightly uncomfortable, because it implies the last three months of roadmap were aimed at the wrong thing. That discomfort is the product.
A designer who is not doing it returns with screens that match your brief exactly. Which feels much better, and is worth much less, because you already knew what was in the brief. You wrote it.
The five studies above are written up in full, each one from the first observation through to the tool that came out of it. They are here, with the PDFs.