Most design problems are thinking problems first.
The screen is the last thing you should touch. Before that, there's the question of whether you understand the problem clearly enough, whether you've considered the failure modes, whether you're working on the right thing at all.
Mental models aren't processes you follow — they're lenses that help you get to better questions faster. Here are the ones I use most.
Upstream thinking
Before solving a problem, ask whether you can make it disappear by solving something upstream of it.
If users keep getting confused at a specific step in onboarding, the obvious solution is to make that step clearer. The upstream question is: why is that step in onboarding at all? Sometimes the bigger question eliminates the smaller one.
A useful way to practice this: when you're handed a design problem, ask "what question would make this question obsolete?" You won't always find one. But when you do, it saves weeks of work on the wrong thing.
Inversion
Instead of asking "how do I make this design succeed?" ask "what would make this design fail?"
Inversion is useful because failures are often more imaginable than successes. You can picture the confused user, the abandoned flow, the misread button. Working backwards from failure gives you specific things to avoid — which is usually more actionable than optimizing toward a vague ideal.
Before a design review, I ask myself: if this design fails for one single reason, what will it be? That question reliably surfaces the most fragile assumption in the design. Fix that, and everything else is more defensible.
The clean slate exercise
Periodically, ask yourself: if I were starting with a completely blank slate tomorrow, would I still make the same choices?
Design decisions compound. What made sense six months ago — when the product had fewer features, different users, different constraints — might not make sense now. The clean slate question cuts through the inertia of existing decisions and forces you to evaluate them fresh.
Apply it to anything: the navigation structure, the component pattern, the way a form is ordered. If you'd make the same choice from scratch, that's reassuring. If you wouldn't, that's a signal worth investigating.
5 Whys
When you have a design problem, ask why five times before you start designing.
"Users are dropping off at the pricing page." — Why? "They can't understand the difference between plans." — Why? "The plan features are described using internal jargon." — Why? "The copy was written by product for an internal audience and never simplified." — Why?
By the fourth or fifth why, you're often looking at a completely different problem than you started with. And frequently, the solution is different too. In this case, the fix might not be a design change at all — it's a copywriting problem.
The 5 Whys forces you to not fix the symptom when the cause is still there.
Jakob's Law
Users spend most of their time on other products. This means they arrive at your product with expectations formed everywhere else.
Jakob's Law sounds obvious, but designers break it constantly — usually in the name of creativity. A checkout flow that's "inventive" confuses users because it doesn't match what they've learned from Amazon and Flipkart. A navigation pattern that's "original" requires users to forget everything they know about navigating apps.
Novelty is worth the cost when it creates genuine value. Most of the time, it doesn't. Leverage the patterns that already exist; your job is to apply them well, not replace them.
Final review prompts
When I'm doing a final pass on a design, I've stopped just looking at whether it feels done. I ask myself a fixed set of questions:
- If this design fails for one reason, what will it be?
- If I had a magic wand, what would I change?
- What might confuse a user who's never seen this before?
- What's the simplest improvement I could make right now?
- How could I simplify this without losing what makes it work?
- How could I make this easier to build without compromising quality?
This takes ten minutes. It almost always surfaces at least one thing worth fixing before handoff.
None of these are processes. You don't follow them step by step. They're habits of thought — ways of looking at a design problem that reveal things a direct approach might miss.
Design judgment is mostly the ability to ask the right question at the right moment. The more lenses you have, the fewer times you end up at the end of a sprint having solved the wrong thing.
Credits & further reading
- Upstream thinking — the framing of "solving problems before they form by going upstream" is explored at length in Upstream by Dan Heath (Crown, 2020). The question "what question would make this question obsolete?" comes directly from that line of thinking.
- Inversion — associated with Charlie Munger, who credited it to the mathematician Carl Jacobi ("invert, always invert"). Applied to product design: thinking about what makes a design fail is often more productive than optimizing toward a vague ideal of success.
- 5 Whys — developed by Sakichi Toyoda at Toyota in the 1930s as part of the Toyota Production System. Popularized in the startup world by Eric Ries in The Lean Startup. Simple to understand, genuinely hard to practice consistently.
- Jakob's Law — originally stated by Jakob Nielsen (NN Group). Formalized and named by Jon Yablonski in Laws of UX (MIT Press, 2020) — a short, practical book on the psychological principles behind good interface design. Worth reading once to build the vocabulary, then keeping on your desk.
- The clean slate exercise and the final review prompt set come from notes I made while going through a framework called The Effective Product Designer — a compilation of tools for improving design judgment beyond craft skills.
- 10k Designers (Abhinav Chikkara) — the mental models session in their curriculum was where I first encountered several of these in a design context rather than a general productivity context.