The Design Problem Statement: Useful vs. Useless

Most design teams write problem statements that sound professional and go nowhere. They're fluffy. They're vague. Worse, they're written after the solution has already been decided. This is a guide to the kind that actually matters.

A problem statement is supposed to do one thing: keep your team focused on the real problem before you start solving it. When it works, it kills bad ideas in the room. When it doesn't, you end up shipping something that nobody actually needed.

What Bad Problem Statements Look Like

Let's start with the versions most teams write.

The first kind is vague: "Users are struggling with our onboarding flow." This tells you almost nothing. Struggling how? Which users? Which part of it? Three people read this and picture three different problems. Your discovery meanders for weeks because you don't know what to actually research.

Then there's the disguised solution: "We need to simplify the dashboard." This isn't a problem statement at all. It's someone's half-baked idea. You haven't identified what users are struggling with, so simplification might be exactly wrong. Maybe they find it overwhelming because the mental model is broken, not because it has too many elements. Or maybe they don't need a dashboard.

Some teams stack multiple problems into one statement: "Users find the interface confusing, the checkout is slow, and they don't know how to contact support." Now you've got three separate issues. A problem statement narrows things down. This expands them. Pick the one problem that, if you solve it, moves the needle for your business and your users.

Finally, there's the untested assumption: "Mobile users abandon because the interface is hard to navigate on small screens." You think this. You don't know it. A real problem statement rests on something you've observed: user research, analytics, support tickets, session recordings. Without grounding, it's just a hypothesis. It might be right. But you haven't tested it yet.

What Changes When You Get It Right

A real problem statement kills meetings. In a kickoff, someone proposes a solution. You pull out the problem statement and ask: is this actually the problem we're trying to solve? Suddenly the vague idea evaporates.

It also narrows your research. You're not exploring "everything about this feature." You're testing a specific hypothesis about a specific problem. Your research plan becomes tighter. You find answers instead of data.

At the end, you have a measure. Did we solve this problem or not? Not "does it look nice." Not "did we ship it." Just: does this address what we said it would?

And it forces honesty. Writing a good problem statement often means saying "we're not solving this other problem right now." That clarity is uncomfortable but necessary.

The Template

A good problem statement has four parts.

Current situation: Provide the minimum context someone needs to understand what's happening and where. Skip the product history. A sentence or two. The goal is scope, not explanation.

The specific problem: Describe what's actually broken, in concrete terms. Not "the interface is confusing," but "users spend an average of 90 seconds navigating three separate menus to access saved items that they expect to find on the main screen." Specific beats vague every time.

Impact: Name who's affected and what it costs. If you have numbers (revenue, support volume, churn rate), use them. If not, describe the qualitative cost: which goals get blocked, what workarounds are people using, which customers are at risk.

Success measure: Define what solved looks like and how you'll know you got there. It doesn't have to be fancy, but it has to be observable. A completion rate, a user behavior shift, a metric that moves.

Real Examples

Mobile checkout abandonment

You're seeing cart abandonment spike on mobile. Digging into session recordings, users are dropping out after entering their shipping address. They click back multiple times, then just close the browser.

12% of users who reach the shipping screen never finish the purchase. That's roughly 300k in annual revenue. They're also less likely to come back and try again.

The measure: mobile checkout completion rate hits 65% (it's at 53% now).

This works because you have data. You know the exact step where people bail. You know what it costs the business. This is a real problem statement.

SaaS onboarding gap

Free trial users create their first project (guided, hand-held). But only 8% become paying customers. The jump from guided project to "I can do this myself" is too large.

It blocks growth. The team thinks 20%+ is realistic if users felt confident enough to keep going. You need to know.

The measure: track how many trial users build a second project from scratch (not from a template). Currently 12% of those who finish the first one do it. Target is 40%.

This captures the actual friction and what success looks like behaviorally.

Internal tools feature gap

Design and product teams keep asking the internal tools team for features. Vendors ship faster. Satisfaction scores are sliding.

Teams waste 2-3 hours per week on workarounds instead of using the tool for what it's meant for. They're talking about switching to external tools instead (which means a costly migration).

The measure: after shipping the feature, 80%+ of teams report that their regular workarounds disappear.

When to Write One

Write a problem statement when you're starting discovery. Or when your team disagrees on what the actual problem is. Or when someone wants to design a solution but you haven't confirmed the underlying user problem yet.

Don't bother when you're iterating on an existing feature (you already know what's broken). Or fixing a critical bug (same reason). Or when customers have already validated the problem and you've confirmed what needs fixing.

The rule: if there's ambiguity about what problem you're solving, write the statement. If there isn't, skip it.

Why This Matters

A problem statement is a commitment to understanding before building. It's core to user-centered design. Teams that write good ones invest time upfront with users instead of guessing. They rebuild less often because they actually solved the right problem.

The hard part isn't the format. It's the honesty. It's admitting what you don't know yet instead of acting like you've figured it out.

Here's a one-page version for your kickoff meeting:

Print it, fill it in with your team, and tape it to the wall. When someone proposes a solution that doesn't match the problem statement, you already know what to say. More importantly, you've already killed the meeting where that bad idea gets traction.