Problem Framing and Opportunity Definition

Introduction

User research produces observations, quotations, behaviours, frustrations and aspirations. Design thinking turns this evidence into a direction for action. The transition is neither automatic nor purely creative. It requires disciplined interpretation: deciding what the evidence means, whose needs matter, what challenge is worth addressing, and how the challenge can be expressed without prematurely prescribing a solution.

Problem framing is the practice of defining a meaningful design challenge from research evidence. Opportunity definition extends this work by identifying areas in which improved experiences, services or systems could create value for users and the organisation. Together, they connect discovery with ideation.

Poor framing can lead to an attractive but irrelevant interface. A team may optimise a feature that users do not need, treat a symptom as the underlying problem, or define the challenge so broadly that no practical decision is possible. Strong framing creates a shared focus while preserving enough openness for alternative solutions.

Learning Objectives

By the end of this chapter, learners should be able to:

• distinguish observations, insights, needs, problems and opportunities;
• develop user-centred point-of-view statements;
• write focused problem statements without embedding solutions;
• convert evidence into useful “How Might We” questions;
• identify and compare opportunity areas;
• prioritise opportunities using impact, evidence, feasibility and business value;
• recognise bias, ethical risks and limitations in problem framing; and
• communicate a defensible design direction to stakeholders.

From Research Evidence to Design Direction

Research data is not the same as a design problem. A participant saying, “I always call my daughter before using the payment machine,” is an observation or quotation. It may indicate uncertainty, low confidence, a trust concern, or a social coping strategy. The designer must interpret it in relation to other evidence rather than treating the statement as a complete specification.

A useful progression is:

Evidence → pattern → insight → need → problem frame → opportunity → concept.

An evidence item is something recorded during research: an observation, interview statement, usability failure, behavioural measure or support request. A pattern is a recurring or notable relationship across evidence. An insight is an interpretation that explains why the pattern matters. A need describes the outcome or condition a person requires, rather than a feature. A problem frame expresses the user difficulty in a focused way. An opportunity identifies a promising area for improvement. A concept is a proposed response.

These categories should not be confused. “Users need a larger button” is usually a solution or design preference. “Users need to recognise the primary action with confidence” is a need. “Older users struggle to distinguish the next step in the payment flow, especially under time pressure” is a problem frame. “Increase confidence and clarity during payment completion” is an opportunity area.

Symptoms, causes and outcomes

A symptom is an observable manifestation of difficulty. A cause is a condition contributing to it. An outcome is the effect on the user or organisation. For example:

Research does not always prove causation. Therefore, a team should use cautious language such as “may contribute to” until a causal explanation has been tested. Treating an assumption as a fact can send the project toward the wrong intervention.

Point-of-View Statements

A point-of-view (POV) statement expresses a human-centred interpretation of a user, their need and the insight explaining why that need exists. A commonly used structure is:

[User] needs to [need] because [insight].

For example:

A first-time benefits applicant needs to understand what evidence is required before beginning an application because uncertainty about documentation makes the process feel risky and encourages postponement.

The statement is not a research finding in isolation. It is a design interpretation grounded in findings. It identifies a particular user perspective, describes an outcome rather than a product, and gives a rationale.

Components of a strong POV

User. Specify the relevant person or group. “Everyone” is rarely useful. The group may be defined by context, behaviour, vulnerability, experience or role, such as “people applying for support for the first time” rather than “customers.”

Need. Express what the person must be able to do, understand, feel or achieve. Use verbs such as understand, compare, recover, decide, prepare, trust or control. Avoid naming a particular interface element.

Insight. Explain the tension, motivation or circumstance revealed by research. An insight should be more than a restatement of the need. It should help the team see the situation differently.

Weak and improved examples

A POV should be neither so narrow that it merely describes one incident nor so broad that it becomes a mission statement. The appropriate scope depends on the project, available evidence and decision authority.

Writing Effective Problem Statements

A problem statement is a concise description of a significant user difficulty and its context. It gives the team a common object of inquiry. A practical format is:

[User group] experiences [difficulty] when [context], which results in [consequence]. The team needs to understand or improve [desired outcome].

Example:

People with limited digital confidence experience uncertainty when reviewing an online appointment before submission, which results in errors and calls to the service centre. The team needs to help them verify important details with confidence.

This statement is specific enough to guide research and ideation, but open enough to permit multiple solutions.

Characteristics of a useful problem statement

1. Evidence-based: It can be traced to research observations or credible organisational data.
2. User-centred: It describes a user difficulty rather than an internal department’s preferred feature.
3. Contextual: It indicates when or where the problem occurs.
4. Outcome-oriented: It describes consequences and desired improvement.
5. Solution-neutral: It does not dictate a screen, channel, technology or implementation.
6. Actionable: The team has some ability to influence the situation.
7. Proportionate: Its scope matches the time, resources and authority of the project.

A problem statement is not a diagnosis of a person. Avoid language such as “users are careless” or “older people cannot use technology.” Such claims conceal system causes and can stigmatise groups. Prefer descriptions of the interaction, environment and constraints.

The “five whys” as a supporting technique

The five-whys technique asks why a difficulty occurs repeatedly in order to move from a visible symptom toward contributing conditions. It is not a proof of causality, and five is not a mandatory number. The questioning should stop when the team reaches a meaningful, researchable condition rather than a vague social explanation.

Example:

• Why are users contacting support after submitting a form? They do not know whether submission succeeded.
• Why do they not know? The confirmation is visually similar to an ordinary information message.
• Why does that matter? Users need a clear status signal at a high-anxiety moment.

The final framing should remain open to validation. Additional research may reveal that network delays, language barriers or organisational policy are also involved.

“How Might We” Questions

A “How Might We” (HMW) question converts a problem frame into an invitation to generate possibilities. “How” signals that alternatives may exist; “might” communicates possibility rather than certainty; “we” establishes shared responsibility.

For the appointment example, possible questions include:

• How might we help people verify key appointment details before submission?
• How might we make completion status unmistakable without overwhelming users?
• How might we support recovery when a submission is interrupted?

The questions differ in scope. The first focuses on verification, the second on status communication and the third on recovery. Each can produce different concepts.

Calibrating the scope of an HMW question

An HMW question that is too narrow embeds a solution:

How might we add a green confirmation banner to the form?

An HMW question that is too broad lacks a useful design boundary:

How might we improve healthcare?

A calibrated version might be:

How might we help first-time users feel confident that their appointment request has been received?

Useful HMW questions often focus on one of the following:

• reducing uncertainty;
• increasing access or comprehension;
• supporting comparison and decision-making;
• enabling recovery from error;
• strengthening trust and control;
• reducing unnecessary effort; or
• helping people accomplish a goal under real constraints.

A team can generate several HMW questions from one problem statement and then select those with the strongest evidence and strategic relevance. HMW questions are not final requirements. They are generative prompts that should later be tested against user outcomes and implementation constraints.

Defining Opportunity Areas

An opportunity area is a bounded domain in which a meaningful improvement may be possible. It is broader than a feature and narrower than a general ambition. For example, “mobile reminders” is a feature direction, while “help people remember required preparation before an appointment” is an opportunity area.

Opportunity areas can be expressed as outcome statements:

• Help applicants prepare before starting a complex task.
• Help users recover without losing progress.
• Help supervisors detect exceptions before they become failures.
• Help people understand how a decision was reached.

A good opportunity area links three elements:

1. User value: what improvement matters to people;
2. Evidence: what indicates that the opportunity is real; and
3. Strategic or organisational value: why the organisation should address it.

Opportunity mapping can be performed by clustering related needs and HMW questions. The team names each cluster with an outcome-oriented phrase, records supporting evidence, identifies affected users, and notes uncertainties. This prevents the loudest stakeholder suggestion from becoming the default priority.

Opportunity versus solution

A solution answers “What might we build or change?” An opportunity answers “Where could improvement create meaningful value?” Keeping these separate protects divergent thinking. A single opportunity may lead to changes in content, policy, service operations, interface design, staff training or technology.

For example, the opportunity “make application requirements understandable before submission” might lead to a checklist, plain-language guidance, a telephone preparation service, policy changes, or a combination of interventions. The best response cannot be selected until the opportunity and constraints are better understood.

Prioritising Opportunities

A project usually identifies more opportunities than it can address. Prioritisation makes trade-offs visible. Four useful dimensions are impact, evidence, feasibility and business value.

A simple qualitative matrix may classify each dimension as low, medium or high. This is appropriate when evidence is limited and the purpose is conversation rather than precise measurement. Teams should record who made each judgement and what assumptions remain.

For a more explicit comparison, a weighted scoring model can be used:

Here, P_i is the priority score for opportunity i; I_i, E_i, F_i and B_i are the ratings for impact, evidence, feasibility and business value; and w_I, w_E, w_F and w_B are weights. The ratings must use the same defined scale, such as 1 to 5. If the weights are intended to represent proportions, they should be non-negative and sum to 1. The score is a decision aid, not an objective truth.

Worked prioritisation example

Suppose a team rates three opportunities from 1 (low) to 5 (high). It chooses weights of 0.35 for impact, 0.25 for evidence, 0.20 for feasibility and 0.20 for business value.

For the first opportunity:

The units are rating points; the score has no physical unit. The calculation assumes that the dimensions are sufficiently comparable for a weighted sum and that the chosen ratings are defensible. It does not establish that the first opportunity will produce 4.35 units of benefit. The team should also discuss risks hidden by the score, such as legal dependencies or the possibility that a high-impact need affects a small but vulnerable population.

Prioritisation principles

• Do not confuse confidence in evidence with importance. A poorly studied problem may deserve research rather than dismissal.
• Do not allow feasibility to erase high-impact needs. Some difficult opportunities should be investigated through a smaller experiment.
• Include negative consequences and equity effects, not only efficiency or revenue.
• Separate “priority to learn about” from “priority to build now.”
• Revisit scores when new evidence, constraints or strategic goals emerge.

A Practical Framing Workflow

1. Gather and audit evidence

Review research notes, recordings, analytics, service data and stakeholder knowledge. Mark direct evidence separately from interpretation. Record the population, context and date. Check whether the sample represents the people affected by the proposed decision.

2. Identify patterns and tensions

Cluster repeated behaviours, workarounds, failures, goals and emotional responses. Look for contradictions: users may value speed but also require reassurance; staff may want fewer contacts while users need more explanation. Tensions often reveal productive design opportunities.

3. State needs and insights

Rewrite feature requests as user outcomes. Ask what the person is trying to accomplish, what prevents success, and why the condition matters. Make assumptions explicit.

4. Draft several POV statements

Create alternatives with different levels of scope. Compare them against the evidence. Avoid selecting the first plausible sentence merely because it sounds polished.

5. Formulate problem statements

Add context and consequences. Check that the wording is solution-neutral, respectful and actionable. Identify what the team does not yet know.

6. Generate and refine HMW questions

Write multiple questions. Remove embedded technologies and vague ambitions. Select questions that invite diverse concepts while retaining a clear user outcome.

7. Cluster into opportunity areas

Group related questions and needs. Give each group an outcome-oriented name. Document affected users, evidence, strategic relevance and unknowns.

8. Prioritise transparently

Use a matrix or weighted model, then conduct a qualitative review. Examine minority effects, dependencies and ethical risks. Decide whether the next action is to build, test, research or defer.

9. Validate the framing

Return to users, frontline staff and relevant subject experts. Ask whether the statement reflects the situation, whose perspective is missing, and what would count as improvement. Validation does not mean asking users to design the solution; it means testing the accuracy and relevance of the interpretation.

Illustrative Case: Community Clinic Appointment Access

This is a fictional illustrative case designed for learning.

Background

A community clinic receives online appointment requests, telephone calls and walk-in enquiries. The organisation wants to reduce avoidable call volume without excluding people who have limited digital access or confidence.

Problem

Analytics show that many online sessions end before submission. Interviews reveal that users are often unsure which appointment type to select and whether they need identification or referral information. Some participants begin the process on a mobile phone while travelling and later abandon it when they cannot locate the required details. Staff report that callers frequently ask whether their request was received.

The initial stakeholder request is: “Build a simpler booking form.” This is too solution-specific and does not explain the range of needs.

Analysis

The team separates evidence from interpretation:

• Evidence: users hesitate at appointment-type selection; some leave to find documents; callers seek confirmation; mobile interruptions are common.
• Pattern: uncertainty occurs before and after submission, particularly when users lack preparation or cannot maintain continuity.
• Insight: users are not merely seeking a shorter form; they need confidence that they are choosing correctly and that their effort has been preserved.
• Need: users need to prepare, choose and confirm without fear of making an irreversible mistake.

A POV statement becomes:

People arranging a clinic appointment for the first time need to understand their choices and confirm progress because uncertainty about eligibility, information requirements and submission status makes the process feel risky.

A problem statement becomes:

First-time clinic users experience uncertainty when selecting an appointment and checking submission status, especially when they are interrupted or lack required information. This leads to abandoned requests and avoidable calls. The service needs to help users make an informed choice and recover confidently across channels.

Possible HMW questions include:

• How might we help first-time users identify the appropriate appointment type?
• How might we show what information is needed before the user commits time?
• How might we help users recover after an interruption without repeating work?
• How might we make request status clear and trustworthy?

Opportunity definition and prioritisation

The team groups these questions into three opportunity areas: preparation and eligibility clarity; continuity and recovery; and confirmation and status transparency. It rates them using impact, evidence, feasibility and business value. Preparation and eligibility clarity receives the highest combined assessment because it affects the beginning of the journey, has strong interview and call evidence, and can initially be explored through content and service changes rather than major technical development.

Approach and possible response

The team does not immediately build a new form. It first prototypes plain-language appointment guidance, a pre-journey requirements checklist, clearer selection explanations and an interruption-recovery concept. It tests these with users who vary in digital confidence, language, disability and access to documents. The service team also reviews whether policy permits users to save partial information and whether telephone staff can provide consistent explanations.

Outcome

In this illustrative case, the outcome is not a claimed production metric but a better-defined design direction: improve preparation, choice confidence and continuity before optimising the form itself. The framing also reveals that content, policy, service operations and interface design may all contribute to the solution.

Learning points

1. A stakeholder feature request can conceal several distinct user needs.
2. Abandonment is a symptom; its causes must be investigated.
3. Opportunity areas maintain flexibility while preserving a clear outcome.
4. Prioritisation should include inclusion and service dependencies.
5. Testing the frame before building reduces the risk of solving the wrong problem.

Ethical, Inclusive and Professional Considerations

Problem framing allocates attention and resources. It therefore has ethical consequences. A team that defines a problem only around the majority user may design away the needs of people with disabilities, limited connectivity, low literacy, minority languages or insecure access to services.

Researchers and designers should ask:

• Who supplied the evidence, and who was absent?
• Could the proposed framing stigmatise a group or blame individuals for system barriers?
• Does the opportunity improve access, or does it merely shift work to users?
• Are sensitive data and quotations used with appropriate consent and protection?
• Could automation, personalisation or prioritisation unfairly exclude people?
• Are organisational goals aligned with users’ legitimate interests?

When using analytics, high frequency should not be the only criterion. A low-frequency problem may have severe consequences for a vulnerable group. Similarly, business value should not be interpreted only as short-term revenue. Compliance, trust, safety, staff sustainability and public benefit may be central forms of value.

Generative AI can assist with clustering notes, suggesting alternative wording or identifying repeated themes, but it should not be treated as an independent research analyst. Sensitive research material should not be entered into tools without appropriate governance. Human reviewers must verify summaries, preserve context, inspect omissions and ensure that generated language does not introduce stereotypes or unsupported claims. AI-generated framing is a draft requiring evidence review, not a finding.

Challenges and Limitations

Premature convergence. Teams often select the first plausible problem and stop exploring. Counter this by drafting multiple frames and comparing them.

Stakeholder dominance. Senior requests may be valuable but should be treated as hypotheses alongside user evidence.

False precision. Numerical priority scores can create an appearance of objectivity. Ratings depend on judgement, scale design and evidence quality.

Overgeneralisation. A few interviews cannot establish prevalence. Use qualitative research to understand meaning and quantitative data to assess distribution where appropriate.

Frame lock-in. A well-written statement can still be wrong. Make assumptions visible and define what evidence would change the frame.

Conflicting needs. Different users may require different outcomes. Do not collapse meaningful differences into an average user; identify segments, contexts and trade-offs.

Solution leakage. Words such as “app,” “dashboard,” “automate” and “add a button” often indicate that ideation has begun too early. Return to the user outcome.

Best-Practice Checklist

Before approving a problem frame or opportunity area, ask:

• Is the affected user or group clearly identified?
• Can every important claim be traced to evidence?
• Does the statement describe an outcome rather than a feature?
• Is the context and consequence clear?
• Does the wording avoid blame and stereotyping?
• Is the scope appropriate to the project’s authority?
• Have alternative interpretations been considered?
• Are the HMW questions open but not vague?
• Have impact, evidence, feasibility and business value been considered separately?
• Are equity, privacy, safety and unintended consequences visible?
• Is the next action clear: learn, test, build, partner or defer?

Chapter Summary

Problem framing transforms research evidence into a shared, actionable understanding of a design challenge. A disciplined process distinguishes evidence, patterns, insights, needs, problems, opportunities and solutions. Point-of-view statements combine a specific user, a meaningful need and an explanatory insight. Problem statements add context, consequences and a desired outcome while remaining solution-neutral.

“How Might We” questions convert problem frames into generative prompts. Opportunity areas group related needs and questions around outcomes rather than features. Prioritisation can consider impact, evidence, feasibility and business value through qualitative matrices or transparent weighted scoring, but numerical scores should support—not replace—judgement. Strong framing is iterative, inclusive and open to revision. Ethical practice requires attention to missing voices, vulnerable groups, privacy, bias and the difference between organisational value and user benefit.

Key Terms

Evidence: Recorded information supporting an interpretation, such as an observation, quotation, behaviour or service measure.

Pattern: A recurring or meaningful relationship identified across evidence.

Insight: An interpretation that explains why a pattern matters.

Need: A user outcome or condition required to achieve a goal.

Point of view (POV): A statement linking a user, need and insight.

Problem statement: A focused description of a user difficulty, context, consequence and desired improvement.

Symptom: An observable manifestation of a difficulty.

Cause: A condition that contributes to a difficulty.

Solution-neutral: Describing the challenge without prescribing a particular implementation.

“How Might We” question: An open, generative question that invites possible responses to a problem.

Opportunity: A bounded area in which improvement may create user and organisational value.

Opportunity area: A cluster of related needs or HMW questions expressed as an outcome-oriented domain.

Impact: The potential magnitude and reach of an improvement for users.

Evidence strength: The degree of confidence that a need or problem is real and significant.

Feasibility: The practical possibility of implementing and sustaining a response.

Business value: Organisational, strategic, financial, operational, compliance or mission-related benefit.

Weighted scoring: A prioritisation method that combines rated criteria using selected weights.

Assumption: A proposition treated as true but not yet adequately verified.

Frame lock-in: Continuing to use an initial problem definition despite contradictory evidence.

Stakeholder: A person or group affected by, responsible for or able to influence the service or design decision.

Review Questions

Short Answer Questions

1. Distinguish an insight from a user need.
2. What three elements commonly make up a point-of-view statement?
3. Why should a problem statement remain solution-neutral?
4. What is the purpose of a “How Might We” question?
5. Name four dimensions that can be used to prioritise opportunities.

Long Answer Questions

1. Explain the progression from research evidence to opportunity definition, using an example.
2. Describe the characteristics of a strong problem statement and explain why each matters.
3. Compare a feature request with an opportunity area. Why is the distinction useful?
4. Explain how ethical and inclusive considerations should influence prioritisation.
5. Discuss the benefits and limitations of using a weighted scoring model for opportunity prioritisation.

Analytical / Application Questions

1. A university’s students frequently contact support because they cannot tell whether an online enrolment request was submitted. Develop a POV statement, a problem statement and three HMW questions.
2. Using the weighted scoring formula in this chapter, calculate the priority score for an opportunity rated Impact = 4, Evidence = 5, Feasibility = 3 and Business value = 4, using weights 0.35, 0.25, 0.20 and 0.20 respectively. Interpret the result and identify one limitation of the calculation.
3. A product manager asks the team to “add an AI chatbot to reduce support costs.” Reframe this request as an evidence-based opportunity-definition process. Identify the assumptions that must be investigated before selecting a solution.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a point-of-view statement?

A. Users need a dashboard with three tabs.

B. First-time applicants need to understand required documents because uncertainty makes them postpone applications.

C. The organisation should reduce support costs by 20%.

D. How might we build a faster website?

Correct Answer: B. First-time applicants need to understand required documents because uncertainty makes them postpone applications.

Question 2

What is the main purpose of a problem statement?

A. To specify the final interface design

B. To provide a shared, focused description of a meaningful user difficulty

C. To guarantee that a proposed solution will succeed

D. To replace the need for user research

Correct Answer: B. To provide a shared, focused description of a meaningful user difficulty

Question 3

Which HMW question is most appropriately scoped?

A. How might we solve healthcare?

B. How might we add a blue button to the form?

C. How might we help first-time users confirm that their appointment request was received?

D. How might we increase every organisational metric?

Correct Answer: C. How might we help first-time users confirm that their appointment request was received?

Question 4

Which of the following is an opportunity area rather than a specific solution?

A. Add a reminder notification

B. Build a mobile application

C. Help users prepare the information required before starting

D. Install a chatbot

Correct Answer: C. Help users prepare the information required before starting

Question 5

Which prioritisation dimension asks whether the organisation can implement and sustain a response?

A. Impact

B. Evidence

C. Feasibility

D. Business value

Correct Answer: C. Feasibility

Question 6

Using the chapter’s weighted formula, what is the score when ratings are Impact = 4, Evidence = 5, Feasibility = 3 and Business value = 4, with weights 0.35, 0.25, 0.20 and 0.20?

A. 3.80

B. 4.00

C. 4.05

D. 4.35

Correct Answer: C. 4.05

Question 7

Why should a team distinguish a symptom from a cause?

A. To ensure every problem has exactly five causes

B. To avoid treating an observable result as a complete explanation

C. To eliminate the need for stakeholder input

D. To make the solution more technology-focused

Correct Answer: B. To avoid treating an observable result as a complete explanation

Question 8

Which practice best supports inclusive problem framing?

A. Relying only on the largest user group

B. Treating high-frequency problems as always more important

C. Checking whose perspectives are missing and considering consequences for vulnerable groups

D. Allowing senior stakeholders to define the problem without research

Correct Answer: C. Checking whose perspectives are missing and considering consequences for vulnerable groups

Question 9

What is a major limitation of a numerical priority score?

A. It cannot compare any opportunities

B. It automatically proves causation

C. Its ratings and weights depend on human judgement and assumptions

D. It can only be used for financial decisions

Correct Answer: C. Its ratings and weights depend on human judgement and assumptions

Question 10

How should generative AI generally be used in problem framing?

A. As an unquestioned replacement for research analysis

B. To generate drafts or clusters that human researchers verify against evidence

C. To decide which vulnerable groups should be excluded

D. To convert every need directly into a feature

Correct Answer: B. To generate drafts or clusters that human researchers verify against evidence