Defining the problem is half the solution

Defining the problem is half the solution. In any field, business, marketing, engineering or design, giving someone a useful result means understanding their pain first: what the problem is, what causes it, and why it happens to them. Only then can you offer something usable rather than something theoretical.

The clearest example is Uber. It started as UberCab in San Francisco in 2009, after the founders spent $800 on a private driver. That $800 was the answer to one question: what is the problem?

Same story in UX

The position of a single button, or the order of screens inside a flow, can be the reason someone:

• abandons a purchase
• fails to finish a task
• never reaches information they needed

That hits the experience and the business at the same time.

But how do you know it is actually a problem and not just an opinion or a taste? To avoid confusing a real problem with an invented one, you need a clear frame.

Problem statement framework

[User A] experiences [this problem] when they [try to complete this action] in [this context]. This is a problem because [it has this impact on the user experience and on the business].

To build a good one, use the 5Ws:

1. Who is affected?
2. What is the problem?
3. Where does it appear?
4. When does it happen?
5. Why does it happen, and why does it matter?

An example

When a customer tries to buy a product on the site, they get stuck because the payment options are unclear or broken, and that leads them to abandon the purchase.

One sentence, but it carries the person, the problem, the context and the impact. And that sentence then governs every design decision after it: does this decision solve it, or not?