When I'm interviewing a UX designer - or anyone who claims to own product or design direction - there's one thing I'm looking for above everything else.

It's not their portfolio. It's not their tools. It's not how many years they've spent in the industry.

It's how they respond to a problem that arrives pre-packaged as a solution.

Because that's how most problems arrive. A stakeholder walks in with a feature request that's really a guess. A business head copies a competitor's approach and calls it strategy. A PM writes a brief that describes a solution - "we need a chatbot," "we need a loyalty programme," "we need to redesign the settings page" - without ever articulating the problem the solution is supposed to address.

And then a designer takes that brief, opens Figma, and builds exactly what they were asked to build. Beautiful screens. Clean flows. Polished deliverables.

And nobody questions whether the thing they just built was the right thing to build.

That's the pattern I see most often. Not bad designers doing bad work. Good designers doing good work on the wrong problem. They solved exactly what they were asked to solve. And that's the problem.

The Difference Between a Need and a Problem

This distinction is simple to explain and remarkably hard to practise.

A user says: "I need to be able to raise a support ticket."

The designer who treats this as a requirement builds a support ticket system. Delivered. Shipped. Done.

The designer who treats this as a symptom asks: why does the user need a support ticket? Because they reached a point in the product where they didn't know what to do. They were stuck. The system offered no guidance, no recovery path, no way forward. The support ticket isn't the need - it's the escape hatch for a failure that happened upstream in the experience.

When you dig underneath any stated need, you almost always find a situational response to a deeper problem. "I need to track my expenses" is a response to the problem of financial uncertainty. "I need a dashboard" is a response to the problem of not understanding what's happening in the system. "I need a home" is a response to the problems of shelter, security, and belonging.

There are rarely pure needs that aren't, at their root, responses to problems. The designer who accepts the need at face value builds the feature. The designer who finds the problem underneath redesigns the experience so the feature was never necessary.

Einstein reportedly said: "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions" [1]. Most design teams invert this ratio entirely. They spend five minutes understanding the brief and fifty-five minutes executing it. Then they wonder why the solution didn't move the metrics.

A person looking at a complex whiteboard filled with sticky notes and diagrams, representing the process of digging deeper into problems before jumping to solutions

The "What's Underneath" Practice

Let me show you how this works with a real example.

A stakeholder says: "We need a chatbot."

Layer 1 - Why?"Users can't get answers quickly."

Layer 2 - Why can't they?"Our help documentation is disorganised and hard to search."

Layer 3 - Why is it disorganised?"Nobody's updated it in eighteen months. It was written for V1 of the product and we're now on V3."

Layer 4 - Why hasn't anyone updated it?"Nobody owns it. There's no content strategy. Support writes articles reactively when tickets spike, but there's no systematic approach."

Layer 5 - What's the actual problem?"We have an eighteen-month information debt. Users are generating support tickets for questions that should be answerable through the product itself. The chatbot request is a band-aid for a content and information architecture problem that's been compounding for a year and a half."

The stakeholder asked for a chatbot. The real problem is an information gap that's been growing since V1 shipped. Solving the real problem might not require a chatbot at all - it might require a content strategy, an information architecture overhaul, and contextual help embedded in the product.

The chatbot would have cost six months of development time and addressed the symptom. The real solution might cost two months and eliminate the cause. This is what problem-finding looks like. It's not a creative exercise. It's a disciplined act of not accepting the first problem definition you encounter.

What Makes a Problem Worth Solving

Not every problem deserves your time. Resources are finite. Sprints are short. Stakeholder attention is shorter. A problem worth investing in meets four criteria - and the depth of evidence you need for each depends on the stakes.

1. The Problem - The Gap

There must be a specific, articulable gap between the current state and the desired state. Not a topic. Not a direction. A problem.

"We need to improve settings" is not a problem statement. It's a wish. "First-time users take an average of 4.2 minutes to locate settings, with 23% abandoning the task entirely" is a problem statement. The gap is measurable. The failure is specific. The scope is bounded. For a sprint-level decision, a single clear sentence is enough: "Users can't find the settings page." For a strategic initiative, you need the problem framed, bounded, and distinguished from its symptoms - because at that scale, solving the wrong problem costs months.

2. Who It Affects - The Population

A problem without a defined population is an abstraction. "Users are confused" helps nobody. Which users? How many? What segment? What's their context? "New users in the first week" is a start. "35% of new enterprise customers - approximately 1,200 accounts per quarter - who onboard without a dedicated customer success manager" is a problem you can act on. The more precisely you define who's affected, the more precisely you can design the solution.

3. Evidence It's Real

A problem without evidence is an opinion. Opinions are starting points, not foundations.

At minimum, a named hunch is acceptable if you're honest about its basis: "Based on three support tickets and my observation of the last onboarding session, I believe this is a significant problem." That's honest. It's also the kind of statement that earns you the right to investigate further.

At full depth, the evidence is triangulated - data, observation, and user voice working together. Support tickets show the pattern (data). Observed sessions show the behaviour (observation). User interviews confirm the experience (voice). Any one of these alone can mislead you. Together, they create confidence that the problem is real and worth solving.

4. Cost of Inaction - What's Lost If Unsolved

This is the component most designers skip - and it's the one that determines whether your problem gets prioritised or buried.

Every problem competes with every other problem for attention and resources. The cost of inaction is what wins that competition. "If we don't fix this, users will continue to struggle" is not a cost. It's a sentiment. "The 23% task abandonment rate on settings correlates with a 15% higher churn rate in the first 30 days. At current acquisition costs of ₹12,000 per enterprise customer, this represents approximately ₹21.6 lakh in lost revenue per quarter" is a cost. That number changes conversations. That number gets budget. When all four components are present - a specific gap, a defined population, triangulated evidence, and a quantified cost of inaction - you have a problem worth solving. When any of the four is missing, you're either solving the wrong problem, solving a non-problem, or unable to justify the investment.

A team in a meeting room having a challenging discussion, representing the discomfort of questioning assumptions and finding the right problems to solve

Getting Comfortable With Discomfort

Here's the part nobody prepares you for: finding good problems requires making people uncomfortable.

"Why are we building this?" makes a VP uncomfortable. "What evidence do we have that users want this?" makes a PM defensive. "What happens if we don't do this at all?" makes an entire roadmap feel shaky. "Who decided this was the priority, and based on what?" can silence a room.

These are not confrontational questions. They're necessary questions. And the designers who find the best problems are the ones who ask them anyway - with genuine curiosity, not hostility - and sit in the resulting discomfort without backing down.

Because here's what happens when nobody asks: the team builds what was asked. The stakeholder is happy - not because the product improved, but because nobody questioned their judgment. The feature ships. The metrics don't move. Everyone wonders why.

And the designer? The designer solved exactly what they were asked to solve. They did a beautiful job on the wrong problem. And in six months, the feature gets quietly deprecated and nobody talks about it again.

The alternative is uncomfortable. The alternative requires asking questions that challenge people in positions of power - people who might be wrong but aren't used to being told so. The alternative requires a designer who sees their job not as executing briefs but as ensuring the right problem is being solved, even when the right problem isn't the one anybody wanted to hear about. We explored what this leadership posture demands - and what happens to design leaders who avoid it - in Design Leadership Is in Turmoil. And No One's Talking About It. The fighters are the ones who ask the hard questions. The skimmers are the ones who take the brief and deliver the screens.

Not All Problems Are Created Equal

One more thing worth understanding: some problems resist everything I've described above.

In 1973, Horst Rittel and Melvin Webber coined the term "wicked problems" - problems that have no definitive formulation, no clear stopping point, and no right or wrong solutions [2]. Wicked problems change shape as you work on them. Every attempt to solve them creates new problems. And they involve stakeholders with fundamentally different perspectives on what the problem even is.

Healthcare access in rural India is a wicked problem. Designing an equitable hiring platform is a wicked problem. Creating a financial product that serves both the digitally fluent and the digitally excluded is a wicked problem.

The 4-component framework above still applies - you still need to define the gap, the population, the evidence, and the cost. But with wicked problems, you also need humility: the acceptance that your solution will be partial, iterative, and will likely create new problems of its own. The designer who approaches a wicked problem with the confidence of solving a checkout flow will fail. The designer who approaches it with the discipline of the framework and the humility of knowing it's unsolvable will make progress.

Want to build the problem-finding instinct that separates senior designers from everyone else? Our free training shows you how →

Leaders Find Problems. Executors Wait for Briefs.

A good leader - in design, in product, in business - does not wait for needs to be dictated to them. They sense problems. They surface them. They frame them in ways that create action and urgency. They find the problems that are complex enough to matter, solvable enough to justify investment, and valuable enough that solving them makes real money.

And there is a way to develop this capability. It's not innate. It's practised. It's built through deliberately asking "what's underneath this?" a thousand times until it becomes instinct. It's built through learning to frame problems in the language of business impact - not "users are frustrated" but "frustration at this stage costs us ₹21 lakh per quarter." It's built through the courage to challenge comfortable assumptions and the credibility to be heard when you do.

That's what our Tide program is built to develop - not just design skills, but the problem-finding instinct that separates designers who shape direction from designers who execute it.

And for the mechanics of it - the structured process of setting direction, defining the right problem, and scoring whether your problem definition is solid enough to build on - that's what Konfom is launching this month. A confidence engine that assesses your problem framing across these same four dimensions and tells you whether your direction is strong enough to move forward or whether it needs more work. Not a tool that finds the problem for you. A tool that tells you whether you've found one worth solving.

If you're a designer who's been executing well but struggling to break into the level where you define what gets built - where you shape the problem, not just the solution - book a strategy call. Problem-finding is learnable. And it's the skill that changes everything that comes after it.

Sources & References

[1] Einstein, A. (attributed). Widely cited in problem-solving and design thinking literature. Core insight: problem definition deserves the majority of time and effort, not solution execution.
[2] Rittel, H.W.J. & Webber, M.M. (1973). "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 155-169. Introduced the concept of "wicked problems."
[3] Toptal. (2026). "How to Frame Design Problem Statements." https://www.toptal.com/designers/product-design/design-problem-statement
[4] Interaction Design Foundation. (2026). "What is a UX Problem Statement?" https://ixdf.org/literature/topics/problem-statements

About the Author

Shaik Murad is Co-founder and Head of Product & Design at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,000+ designers.

- Murad, Co-founder & Head of Product & Design, Xperience Wave