A practical POV statement template using the User + Need + Insight framework, with 10 industry examples and copyable fill-in-the-blank templates.
A Point of View statement is the single sentence that turns a pile of empathy research into a clear, actionable problem worth solving. It sits at the hinge of the design thinking process. When the POV is sharp, ideation flows naturally and the team stops arguing about which problem to work on. When it is fuzzy, every downstream decision becomes a debate. This guide gives you the template, the three tests every POV must pass, ten industry examples you can adapt, and the most common ways teams get it wrong.
The canonical POV statement template, taught at Stanford d.school and adapted across thousands of design teams, has three slots:
[User] needs a way to [need] because [insight].
That looks simple, and that is the point. The discipline is not in the sentence structure, it is in what you put inside each slot. Each piece has to earn its place:
Before locking in a POV, run it through three tests. If any one of them fails, the statement is not ready and you owe yourself another pass through the research.
Can you point to the actual person behind the User slot? Not a persona document, an actual human you spoke to or watched. "First-year medical residents during night shifts" passes. "Healthcare workers" does not. Specificity is what makes a POV operationally useful, because it tells the team whose feedback counts during testing.
Read the "because" clause out loud. Did you learn that from research, or did you assume it before the project started? Anything in the insight slot that you already believed on day one is not an insight, it is a hypothesis. Real insights tend to feel slightly uncomfortable, because they often contradict the assumption that funded the project.
Strip the POV of every word that hints at a specific solution. If the sentence collapses, the POV was prescribing the answer instead of describing the problem. A well-built POV leaves at least three credible solution directions open. That is what your How Might We questions are for in the next step.
Below are ten POV statements across industries you can use as scaffolding. Each one includes the underlying research signal that produced the insight, because the insight is the part teams skip and the reason most POVs feel generic.
POV: A newly diagnosed Type 2 diabetes patient in their first 90 days needs a way to connect daily food and activity choices to their next blood test result, because the gap between behaviour and feedback is too long for them to learn what is actually working. Research signal: Five of six interviewees described feeling "blind" between quarterly check-ups and abandoning new habits within three weeks.
POV: Students in 35-plus seat lecture classes need a way to signal confusion to the teacher without speaking up in front of peers, because the social cost of asking a question is higher than the academic cost of staying lost. Research signal: Classroom observation showed an average of 1.2 questions per 50-minute class, with the same three students producing most of them.
POV: Young professionals whose rent consumes 40 percent of take-home pay need a way to build a small emergency cushion in weeks, not years, because traditional advice to "save 20 percent of income" feels like proof the system was not built for them. Research signal: Diary studies revealed users abandoning savings apps after 14 days when projected timelines exceeded 18 months.
POV: Fashion shoppers who order three sizes intending to return two need a way to start a return before the package arrives, because the mental load of "remembering to ship it back" is what causes returns to expire unredeemed. Research signal: Of users who said they "always return what does not fit", 38 percent had at least one unreturned item over the cutoff window.
POV: A mid-level operations manager evaluating a new analytics tool during a free trial needs a way to see one report built on her own data within five minutes of signing in, because she is being asked to justify the trial to a sceptical boss who will lose interest after the first meeting. Research signal: Trial users who imported data on day one converted at 4x the rate of those who did not, but only 22 percent imported on day one.
POV: A first-time unemployment applicant needs a way to know whether their application is moving forward, because silence from the system is interpreted as denial and pushes them to abandon the claim and seek informal work. Research signal: Phone-centre logs showed 61 percent of inbound calls were status checks rather than substantive questions.
POV: Families of four who shop weekly need a way to plan meals around what is already in the fridge, because they keep buying with their aspirational self in mind and eating with their tired self at 7 p.m. Research signal: Photo diaries showed an average of 1.8 kg of produce thrown out per household per week, almost all bought during the previous shop.
POV: A new hire joining a fully remote team needs a way to build informal relationships with three colleagues in their first month, because every retention conversation in exit interviews mentioned the feeling of being "a contractor with full-time hours" during the first 90 days. Research signal: Exit interviews from remote leavers within their first year mentioned "isolation" or "no real team" in 7 of 10 cases.
POV: An infrequent flyer travelling alone needs a way to know in advance what each airport step will look and feel like, because the uncertainty, not the time pressure, is what triggers them to arrive three hours early and still feel rushed. Research signal: Shadowing showed infrequent flyers stopping every 90 seconds on average to re-read signage and check their phone.
POV: A homeowner setting up a smart-home device on a Sunday afternoon needs a way to recover when the app loses connection mid-setup, because the moment they have to "start over" is when they put the device back in the box and consider returning it. Research signal: Customer-support transcripts showed "started over" appearing in 44 percent of setup-related tickets and correlating strongly with refund requests.
Use these scaffolds during your synthesis workshop. Print them, paste them into a whiteboard, or drop them into a doc. The blanks force the team to be specific.
A [specific user, with the context that makes them different] needs a way to [verb-based outcome they cannot achieve today] because [insight from research that explains why this is hard for them].
When the underlying problem is mostly emotional, this variant keeps the feeling at the centre rather than burying it in the insight.
A [specific user] needs a way to feel [emotion] when [situation], because today they feel [opposing emotion] and it leads them to [unwanted behaviour].
When the user is caught between two competing forces, naming both makes the design problem visible to the rest of the team.
A [specific user] needs a way to [outcome A] without [unwanted consequence B], because the tools they use today force them to trade one for the other.
If your team thinks in Jobs to Be Done, this variant maps the JTBD job statement into a POV without losing the underlying need.
When [situation], a [specific user] needs a way to [job] so they can [outcome], because [insight about why current solutions fall short].
"Millennials in urban areas" is a slide from a pitch deck, not a user. Replace it with the most specific real person you observed, and add the contextual detail that makes them different from the rest of their segment. "A 28-year-old freelance designer with irregular monthly income" gives the team something to design for.
"Needs an AI assistant" or "needs a dashboard" is a solution sneaking into the problem space. Strip the noun and force the team to express the need as a verb the user would recognise: "needs a way to prepare for tomorrow's pitch in 20 minutes between school pickup and dinner".
"Because they need help managing their schedule" is not an insight, it is the need re-phrased. A real insight tells you something about why the need is hard, the user's worldview, or the system around them. If you can swap the insight clause across two unrelated POVs and both still make sense, the insight is generic.
Teams under deadline pressure often write the POV before doing the empathy work, then collect research to confirm it. The fix is structural: do not let anyone draft a POV until the team has read every interview note and clustered them with an affinity diagram. The POV should feel like a forced consequence of the clusters, not an opinion that survived them.
If the research surfaced more than one user with genuinely different needs, write more than one POV. Choose which to prioritise based on strategic fit, frequency of the pain, and your team's capacity to serve them well. Forcing one statement to cover everyone makes it so generic it stops being useful.
A POV is the launching pad, not the destination. Once you have a POV that passes the three tests, the next move is to generate ideas without prematurely converging on a solution. The bridge is the How Might We question, which inverts the POV from a problem statement into an invitation. Each POV typically produces three to five HMW questions, each opening a different solution space.
For example, the e-commerce returns POV from earlier becomes:
Each of these would generate different prototype directions, and that breadth is exactly what a strong POV makes possible. Learn the full HMW method in our How Might We guide, and see worked POV + HMW pairs in the Problem Statement Examples library.
Reading templates only gets you so far. The POV gets sharper the moment it has to survive a real research cluster, a real stakeholder review, and a real round of HMW questions. The Design Thinker Labs Define stage walks you from raw empathy notes through synthesis, POV drafting, and HMW generation in a single guided flow, with the templates above built into the editor. That keeps the POV honest, because it has to do real work before the next stage unlocks.
Related guides: design thinking templates · design thinking tools and software · usability heuristics
Design Thinker Labs Home · All Guides · How It Works · Pricing