Problem Statements

Definitions

User
A person who is trying to solve a problem and is looking for a product or service to help them solve it.
User experience
The journey that the user takes with that product or service.
Problem statement
A concise description of the problem that needs to be solved, and it summarizes who the user is, what they need from a design, and why.
Pain points
Any UX issue or friction that frustrates the user and blocks them from getting what they need. Minimizing pain points keeps users happy and encourages them to keep interacting with the product.
Value proposition
Why your user would or should use the product or service that you’re designing.

Goals

1
Problem we are solving must be clear
2
Problem needs to be worth solving
3
User's goals must be clear and therein lies the need to define what constitutes success for the user

Questions to Ask

?
Is there a problem statement? What is the problem statement?

You need to be clear what you are trying to do. Identify a right, meaningful problem.

?
What is the need and desired outcome?

Focus on the gap, not the solution, and what the user/customer wants achieved.

?
Why is the problem important?

Choosing the correct problem to solve increases the odds you succeed in your initiative.

?
Who is experiencing the problem?

You need to focus on who the customer really is whom you're trying to value add.

?
What are the pain points you’re trying to solve?

You want to target key issues users have with whatever you're trying to get them to do.

?
Where is the user when they’re using the product?

Context matters. Knowing the user's environment (physical location, device, surrounding distractions) informs design and functionality. A product used on a noisy factory floor will have different UI/UX needs than one used in a quiet office. Understanding the user's context improves usability and relevance.

?
When does the problem occur?

Understanding when the problem occurs (frequency, specific situations, time of day) helps prioritize solutions and identify trigger events for your product to intervene effectively.

?
How are users reaching their goals by using the product?

This focuses on user journeys and product effectiveness. Mapping user goals and how your product facilitates them reveals areas for improvement in usability and value proposition. It ensures your product is actually helping users achieve what they set out to do, and highlights potential friction points.

?
What is the hypothesis?

Product development should be driven by testable assumptions, not just gut feelings. Formulating a clear hypothesis ('If we build X, then Y will happen') allows you to validate your ideas through data and iteration.

?
Who gets value, at what velocity, at what volume?

Understanding value delivery is key to sustainability and growth. Knowing who benefits, how quickly they see value, and how much value they receive informs your business model, marketing strategy, and product roadmap. It helps you quantify impact and understand the scale of your potential success.

?
Why do we need X? What happens if we got rid of this by end of this year, or if we refused to build this? Who would come to us to complain and why would they do so?

This question challenges assumptions and forces you to justify features or projects. It encourages critical thinking about necessity and impact.

?
What are the blockers to doing X? Let's split them by policy, user research, resources.

First step to unblocking is to understand the nature of the blocker. Each type of blocker deserves its own treatment.

Alarm Bells

They say...
You should be doing xxx, yyy, zzz because Company X is doing it as well.
Why it's scary

Context is important, there's very little point in trying to copy solutions if it worked to solve their problems, not ours.

They say...
I already have a plan and it incorporates input and requirements from X departments.
Why it's scary

It most likely is an aggregation of desired solutions that do not solve real problems. It also is likely overly complex because it tries to be everyone's solution.

They say...
I have KPIs that xxx/IDSC/committee already approved X years ago
Why it's scary

You probably haven't reviewed if they're still appropriate and if it measures your ability to solve user problems

They say...
I already have a strategy approved X years ago
Why it's scary

You probably missed out on technologies, solutions and products that came up.

They say...
We need to be no worse off / Ensure we're no worse off.
Why it's scary

Problems don't always need to be solved in the same way, but "no worse off" generally assumes solutions are static.

They say...
It's impossible to track whether our tool improves productivity, saves manual labor and how much it improves the business.
Why it's scary

You can't track the productivity increase for every person, but you can follow >5 teams for several weeks and record how much they benefit in time savings, efficiency, errors they encounter, or even entire work flows they no longer do. But this has to be done before you deploy and is pointless to lament you didn't after the fact.

They say...
Anything is technically possible. GPT 4, 5, 6, 7 are all the same. What matter are the business requirements and the use case.
Why it's scary

I've heard this a lot. Tech advancements can meaningfully change the game for business. Like, models are literally getting much smarter with every release. This just betrays a lack of understanding by "technical consultants" and is a lazy excuse to not think deeper.

Dealbreakers

They say...
No one knows what problem is it we're solving.
Why it's scary

No clear problem.

They say...
Problem being tackled seems to be changing after every meeting.
Why it's scary

Problem keeps changing.

They say...
We're constantly adding new requirements to our total list of requirements.
Why it's scary

Requirements keep growing.

They say...
No one's asking for this.
Why it's scary

Nobody wants it.

They say...
Meetings are dominated by people who say "I think..." but no one actually knows someone who's a user.
Why it's scary

No user knowledge.

They say...
You're doing things because bosses asked.
Why it's scary

Boss-driven, not user-driven.

They say...
Problem is an edge case, but we have money, so who cares.
Why it's scary

Solving a rare problem (wasteful).

They say...
Business owner says they need all the requirements, so let's keep every one.
Why it's scary

Unfocused and wasteful.

Apptitude / Curated by Zixian Chen

© 2024–2026. All Rights Reserved.