There's a moment in every design brief where I have to actively resist myself. You hear the problem and your brain immediately starts solving it. A cleaner dashboard. A better onboarding flow. A navigation restructure. The frame is forming before the other person finishes their sentence. I've learned to treat that moment as a warning sign.
It's not that fast intuition is useless. Experience is stored intuition, and that's real. But that initial solution frame is almost always responding to the surface of the problem. And the surface is usually wrong.
The problem with problems
Most briefs arrive pre-interpreted. Someone decided what the problem was, translated it into a design request, and handed you the translation. What they want from you is execution. But the translation is almost never perfect. When it's off, brilliant execution produces a beautiful failure.
I learned this on the Co-op Bank login redesign. The brief came as a visual problem: the login page was dated, didn't reflect the brand, needed a refresh. Any designer opening that brief would start sketching immediately.
But when I spent real time in the problem, studying drop-off data, listening to support call recordings, mapping the full journey around that screen, the visual story fell apart. Customers weren't abandoning because the UI was ugly. They were leaving because they couldn't recover their accounts without physically going to a branch. The login page wasn't unattractive. It was a wall.
The redesign that came out of that understanding was completely different from what a surface-level brief would have produced. Because we were solving the real problem, not the reported one.
Staying in the fog
When you first encounter a complex problem, everything is unclear. Constraints are fuzzy. Users are hypothetical. Goals are contested. Most people want to exit that fog fast. Clarity feels like progress.
But premature clarity is a trap. You get out of the fog by simplifying, and simplification is lossy. You leave behind the nuance that comes back in the third round of revisions, when someone says "but what about the user who..." and you realise you never accounted for that person.
The skill is staying in the fog long enough. Not forever — that's paralysis. But long enough for the real shape of the problem to emerge.
There's a concept in Zen called shoshin, beginner's mind. The willingness to not-know, to hold the question without rushing to an answer. It sounds counterintuitive in a profession where confidence is often mistaken for competence. But it's one of the most useful things I've found in this work.
What happens when you stay
Resist the pull toward solutions for a while and things start to reveal themselves.
You see what's actually being measured. Most problems have a visible symptom and a hidden metric. Understanding what success really means, not what the brief says but what it actually requires, changes everything about the design direction.
You discover which constraints are real and which are just assumed. Teams carry inherited beliefs about what engineering will allow, what the business will approve, what's possible. These are almost always more negotiable than people think. But only if you understand why they exist.
And you build empathy at the right level. Surface empathy — "users find this confusing" — produces surface solutions. Understanding what the confusion actually costs someone produces solutions that last.
A practice, not a principle
Before I open Figma, I write. Plain language, nothing formal. What is the problem as I understand it? What don't I know? Who is this person and what do they actually need, not what they're asking for, but what would genuinely help them?
I write until the writing shows me something I didn't know when I started. Then I read it back as a skeptic. Where am I making assumptions? Where am I filling gaps with my own preferences? Where does the logic actually break?
Only after that do I consider picking up a pen.
The blank canvas will always be there. The problem won't wait forever to be understood.