Problem Statement Examples & Customer Templates (14)

The problem statement is the hinge of the entire design thinking process. Get it right and everything downstream (ideation, prototyping, testing) flows naturally. Get it wrong and you will build a brilliant solution to the wrong problem. This guide gives you 14 worked design problem statement examples across eight industries, fill-in customer problem statement templates you can copy today, and a short diagnostic for telling a strong statement from a vague one.

What Is a Problem Statement?

A problem statement is one or two sentences that name whose problem this is, what they are trying to achieve, and why the obstacle exists — written before anyone proposes a solution. Its job is narrow and unglamorous: to hold a team to one shared definition of the problem long enough to solve it. It is a claim about the present, grounded in research, not a description of the thing you intend to build.

Two phrases get used almost interchangeably, and the difference is worth keeping straight because they answer to different audiences:

• A design problem statement frames the problem for the people who will design a response. It leads with the user and the insight, and it stays deliberately solution-neutral so that ideation is not pre-empted. The POV format below is the standard shape.
• A customer problem statement frames the same problem for the people who decide whether it is worth solving. It keeps the customer's situation and motivation, then adds the workaround they use today and what that workaround costs them — the clauses that turn a user need into a business case. Template 2 below is that shape.

Both describe one reality. Write the design version first, from what you heard in research; derive the customer version from it when you need to argue for the work. If the two disagree on who the user is or what they want, the disagreement is real and you are not ready to ideate.

A usable statement has four parts: a specific user described by situation rather than demographic, a need stated as an outcome they care about, an insight explaining why the need goes unmet, and no solution anywhere in the sentence. Drop any one of the four and the statement stops doing work: without the insight it is a feature request, and with a solution baked in it is a specification wearing a problem's clothes.

Two Essential Formats

Design thinking uses two complementary problem statement formats, each serving a different purpose:

• Point of View (POV): A declarative statement that captures who the user is, what they need, and the insight that makes the need actionable. Format: "[User] needs [need] because [insight]."
• How Might We (HMW): A question that reframes the problem as an opportunity for ideation. Format: "How might we [desired outcome] for [user] so that [benefit]?" Learn the full method in our HMW guide.

The POV grounds you in user reality. The HMW opens up solution space. You need both. A POV without an HMW leaves the team staring at a diagnosis with nowhere to go; an HMW without a POV invites brainstorming detached from anything a real person said.

Customer Problem Statement Templates

Before the examples, here are four fill-in templates. Copy the one that matches your situation, then replace the bracketed parts with language taken from your research notes rather than your own paraphrase.

Template 1: The classic POV

[Specific user, described by situation not demographic] needs a way to [verb + outcome they care about] because [surprising insight from research].

Use this as your default. The "because" clause carries the weight: if it repeats the need in other words, you have described a symptom rather than a cause.

Template 2: The customer problem statement (job-oriented)

When [situation], [customer] wants to [motivation], but [obstacle], so they [current workaround], which costs them [consequence].

This is the format commercial teams tend to prefer, because the consequence clause converts a user problem into a business case. It pairs well with jobs to be done research.

Template 3: The HMW reframe

How might we [enable / remove / reduce / reveal] [something concrete] for [user] so that [benefit in their terms]?

Write three to five variants at different altitudes. One narrow ("How might we cut the refill request to two taps?"), one wide ("How might we make a month of medication feel effortless?"), one that questions the premise ("How might we remove the need to remember at all?").

Template 4: The tension statement

[User] wants [goal A] and [goal B], but today they must trade one for the other because [structural reason].

Reach for this when research keeps surfacing a genuine conflict rather than a missing feature. Tensions produce the most interesting ideation, because resolving one usually requires a change of shape rather than an extra button.

Healthcare Examples

Example 1: Chronic Disease Management

POV: A newly diagnosed Type 2 diabetes patient needs a way to understand which daily decisions affect their blood sugar because they feel overwhelmed by conflicting information from doctors, websites, and well-meaning family members.

HMW: How might we help newly diagnosed diabetes patients connect their daily choices to their health outcomes so that they feel empowered rather than overwhelmed?

Why it works: the insight is not "patients lack information" (they are drowning in it) but that the information conflicts. That reframe rules out another leaflet and points toward feedback tied to the patient's own readings.

Example 2: Medication Adherence

POV: Elderly patients managing multiple prescriptions need a way to keep track of which medications to take and when because existing pill organizers don't account for changing dosages, refill schedules, or drug interactions.

HMW: How might we simplify medication management for elderly patients with complex prescriptions so that they can follow their regimen confidently without caregiver assistance?

Why it works: it names the failure of the current workaround. When a statement explains why today's solution breaks, the team inherits a design constraint instead of a blank page.

Education Examples

Example 3: Student Engagement

POV: High school students in large lecture-style classes need a way to stay engaged during lessons because they feel invisible in a room of 35+ students and have no way to signal confusion without public embarrassment.

HMW: How might we create low-friction channels for students to signal confusion or interest during large-group instruction so that teachers can adapt in real time?

Why it works: the barrier is social, not technical. Naming embarrassment as the obstacle keeps the team from proposing a hand-raising app that nobody would use.

Example 4: Career Exploration

POV: First-generation college students need a way to explore career paths connected to their major because they lack the professional networks and family precedents that guide career discovery for their peers.

HMW: How might we give first-generation students the career exposure and mentorship that professional networks provide organically for other students?

Why it works: it locates the gap in access rather than in motivation, which changes the solution space from "encourage students" to "manufacture the missing network".

Fintech Examples

Example 5: Savings Behavior

POV: Young professionals living paycheck to paycheck need a way to build an emergency fund because traditional savings advice ("save 20% of income") feels impossible when rent takes 40% of take-home pay.

HMW: How might we make saving feel achievable for people whose fixed costs leave almost no discretionary income?

Why it works: it quotes the advice users actually hear and explains why it lands badly. Specific language beats a generic "users struggle to save".

Example 6: Small Business Cash Flow

POV: Small business owners with seasonal revenue need a way to manage cash flow across lean months because they understand their annual revenue is sufficient but can't bridge the gaps between busy periods.

HMW: How might we help seasonal businesses smooth their cash flow so that slow months don't threaten their survival?

Why it works: the owner is competent, not confused. Statements that respect user expertise avoid the trap of designing education for people who need timing.

Sustainability Examples

Example 7: Food Waste

POV: Families of four need a way to reduce food waste because they buy groceries with good intentions but lack the planning tools to use perishable items before they spoil, which leaves them with guilt and wasted money.

HMW: How might we help families plan meals around what they already have so that less food ends up in the trash?

Why it works: the intention already exists, so the design problem is planning support rather than persuasion.

Example 8: Sustainable Commuting

POV: Suburban commuters who want to reduce their carbon footprint need alternatives to single-occupancy driving because public transit doesn't reach their neighborhoods and carpooling requires coordination they don't have time for.

HMW: How might we make shared commuting as convenient as driving alone for people in transit-poor areas?

Why it works: it sets the bar the solution must clear (as convenient as driving alone), which gives the team a testable success condition.

Workplace Examples

Example 9: Remote Collaboration

POV: Remote team members across time zones need a way to maintain the informal knowledge-sharing that happened naturally in offices because important context is now trapped in private Slack threads and undocumented meetings.

HMW: How might we recreate the serendipitous knowledge-sharing of physical offices for distributed teams without adding meeting fatigue?

Why it works: the "without" clause carries a constraint drawn from research. Constraints inside an HMW keep ideation from producing another recurring call.

Example 10: Employee Onboarding

POV: New hires at fully remote companies need a way to build relationships with colleagues because the onboarding process focuses on systems and processes but neglects the social connections that drive retention and engagement.

HMW: How might we help new remote employees build genuine team relationships in their first 30 days without forced social activities?

Why it works: it names what people reject (forced fun) as well as what they need, so the team knows which obvious answer is already ruled out.

Retail and Service Examples

Example 11: Returns and Exchanges

POV: Online shoppers buying clothing in unfamiliar sizes need a way to judge fit before ordering because they have learned to buy three sizes and return two, turning every purchase into an errand they resent.

HMW: How might we give shoppers enough confidence about fit before checkout so that returns stop being part of their normal buying routine?

Why it works: the workaround (buy three, return two) is the evidence. Describing the behaviour is more useful than asserting "sizing is inconsistent".

Example 12: Public Service Access

POV: Residents applying for housing assistance need a way to know where their application stands because silence between submission and decision pushes them to re-apply, call, and visit in person, which slows the queue for everyone.

HMW: How might we keep applicants informed during the waiting period so that they stop needing to chase their own case?

Why it works: it links the user's pain to a system consequence, which is how a problem statement earns priority from people who control budgets.

Product and SaaS Examples

Example 13: Feature Adoption

POV: Product managers at a B2B SaaS company need a way to understand why a well-reviewed feature sees almost no repeat use because analytics show the drop-off but exit surveys only collect answers from users who already decided to leave.

HMW: How might we surface the moment a feature stops earning its place in a user's workflow so that product teams can intervene before abandonment becomes silent churn?

Why it works: it separates the measurable symptom (drop-off) from the research gap (no voice from active-but-fading users), which tells the team where to do empathy work next.

Example 14: Free-to-Paid Conversion

POV: Free-tier users of a design tool need a way to experience the value of paid features inside their real projects because trial checklists and feature tours show capabilities without ever touching the work they actually opened the app to do.

HMW: How might we let free users apply premium capabilities to a project they already care about, so that upgrading feels like keeping progress rather than buying a promise?

Why it works: the insight reframes conversion as a continuity problem, not a persuasion problem, which rules out more pop-ups and points toward in-context trials.

Before and After: Three Rewrites

Most first drafts are not wrong, only unusable. These rewrites show the common repair patterns.

• Before: "Users want a better dashboard." After: "A warehouse shift lead needs to see which orders are at risk in the next two hours because they currently rebuild that picture by walking the floor and asking three people." Repair: replace the requested feature with the situation that produced the request.
• Before: "Customers churn because the product is hard to use." After: "Customers who cancel in month two need to show their manager a result before the next budget review because they were the person who championed the purchase." Repair: replace an assumed cause with what interviewees actually said was at stake.
• Before: "How might we use AI to improve onboarding?" After: "How might we get a new user to their first useful output on day one without a training session?" Repair: take the technology out of the question so the solution stays open.

Common Mistakes

• Hiding a solution inside the need. "Needs a mobile app" is a decision, not a need. Ask what the app would let them do, then write that.
• Using a demographic instead of a situation. "Millennials" tells you nothing you can design for; "people whose income arrives irregularly" does.
• Writing a because clause you already believed. If the insight predates the research, the research did not happen.
• Bundling several problems. Two "and"s in a statement usually means two statements. Split them and prioritise.
• Scoping so wide that everything qualifies. If any idea your team proposes could answer the HMW, the question is not doing work.
• Never revisiting it. A statement written before testing should be re-read after it, and edited when evidence contradicts it.

How to Write Your Own

The quality of your problem statement depends entirely on the quality of your empathy research. If your POV feels generic or obvious, you haven't gone deep enough. Go back to your empathy maps and look for the surprising insight, the thing that contradicts your initial assumption.

Three tests for a good problem statement:

• Specificity: Does it describe a specific user with a specific need? "People need better tools" is not a problem statement.
• Insight: Does the "because" clause contain something you learned from research, not something you assumed before starting?
• Scope: Is it narrow enough to act on but broad enough to allow multiple solution approaches?

A practical working order: pull five to seven verbatim quotes from your interviews, cluster them until one tension repeats, draft the POV from that tension, then write four HMW variants at different altitudes and ask the team which one they can generate ten ideas against in five minutes. The one that produces ideas is your statement; the ones that stall were either too vague or already contained the answer.

Note on the examples above: they are composites written to illustrate structure, drawn from patterns common in published design thinking practice rather than from named client engagements. Use them as scaffolding for your own research, not as findings about your users.

For the full process of moving from empathy research to problem definition, and for the deeper treatment of the declarative format, see the POV statement template guide. Both stages are built into the structured workflow in Design Thinker Labs.