4  Empathize and Define

4.1 Learning Objectives

By the end of this chapter, you will be able to:

• Conduct User Research: Apply observation, interview, and ethnographic research techniques to understand IoT users
• Create Empathy Maps: Synthesize user research into Says-Thinks-Does-Feels quadrants that reveal insights
• Identify Pain Points: Categorize user frustrations as functional, emotional, financial, or social

Key Concepts

• Empathy Map: A four-quadrant tool capturing what users Say, Think, Do, and Feel; reveals the gap between stated and actual user needs
• User Interview: A structured conversation technique using open-ended questions to uncover real user behaviors, motivations, and frustrations — not opinions or feature requests
• Pain Point Categories: Functional (task-related), emotional (frustration, anxiety), financial (cost, waste), social (status, relationships) — categorizing pain points reveals where solutions add the most value
• Persona: A composite user archetype built from interview data, representing a segment of real users; used to keep design decisions user-centered throughout development
• POV (Point of View) Statement: A user-centered problem definition format: “[User] needs [need] because [insight]” — the anchor for all subsequent design work
• HMW (How Might We): A question format that reframes problems as opportunities; “HMW help elderly users remember medication without anxiety?” invites solution generation
• Insight: A non-obvious pattern discovered from user research that reframes how the team understands the problem

In 60 Seconds

The empathize and define phases transform vague “we need an IoT device” ideas into precise user-centered problem statements; by conducting interviews, building empathy maps, and using the HMW and POV frameworks, teams ensure they are solving real problems rather than building technology for its own sake.

• Develop User Personas: Create detailed representations of target users for design reference
• Write Problem Statements: Use POV and HMW frameworks to create actionable, user-centered problem definitions
• Define Success Metrics: Establish measurable criteria for evaluating solution effectiveness

For Beginners: Empathize and Define

Design methodology gives you a structured, proven process for creating IoT systems from initial concept to finished product. Think of it like following a recipe when cooking a complex meal – the methodology tells you what to do first, how to handle each step, and how to bring everything together into a successful final result.

Sensor Squad: Walking in Someone Else’s Shoes!

“Empathize means really understanding what someone else experiences,” said Sammy the Sensor. “If we are building a smart garden system, we do not just sit at our desks imagining what gardeners need. We go to actual gardens, watch people water their plants, and ask them what frustrates them. Maybe they hate carrying heavy watering cans, or they forget to water when traveling.”

Max the Microcontroller showed how to organize findings: “We use an empathy map with four sections: What do users SAY? What do they THINK? What do they DO? And what do they FEEL? A gardener might SAY ‘I water every day’ but we OBSERVE they actually forget half the time. The gap between what people say and do is where the real insights hide.”

“Then we Define the problem,” added Lila the LED. “We write a problem statement like: ‘Busy professionals who love gardening need a way to keep plants healthy despite irregular schedules, because forgetting to water causes plants to die and makes them feel guilty.’ That sentence guides everything we build!” Bella the Battery agreed, “A well-defined problem is half the solution!”

4.2 Prerequisites

• Design Thinking Introduction: Understanding the seven-phase framework and problem statement formula

4.3 Stage 1: Empathize

4.3.1 Understanding Your Users

The Empathize stage requires stepping outside your assumptions and entering the user’s world. For IoT products, this means understanding: - Physical context (where they’ll use the device) - Technical context (existing devices and connectivity) - Social context (who else is affected) - Emotional context (frustrations, fears, desires)

User Research Techniques

1. Observation Watch users in their natural environment without interfering.

Example: For a smart home thermostat, observe how families interact with heating/cooling: - Do they check temperature often? - Who controls the thermostat? - When do comfort complaints happen? - What workarounds have they created?

2. Interviews Ask open-ended questions that reveal needs and frustrations.

Good questions:

• “Walk me through your morning routine…”
• “Tell me about the last time [topic] frustrated you…”
• “What would make this easier?”
• “How do you currently solve this problem?”

Bad questions:

• “Would you use a smart device that…?” (leading)
• “Do you want feature X?” (yes/no, not insightful)

3. Empathy Mapping Organize observations into four quadrants:

Figure 4.1: Empathy Map Example: Understanding Elderly Medication Management Needs

Empathy Map for Smart Pill Bottle User: Four quadrants reveal the full picture of user experience. What users SAY (“I forget if I took my pills”) differs from what they FEEL (embarrassed, anxious). This emotional dimension is critical for IoT product design - the solution must address feelings, not just functional needs.

Alternative View: Empathy Map Template (Blank)

Use this blank template to map your own user research findings:

Figure 4.2: Blank empathy map for your user research. Fill each quadrant with findings from observations and interviews.

4. Contextual Inquiry Observe users performing actual tasks in their real environment while asking questions.

5. Journey Mapping Document the complete user experience across time and touchpoints.

4.3.2 Identifying Pain Points

Functional Pain Points:

• Tasks that are difficult or time-consuming
• Features that don’t work as expected
• Missing capabilities users need

Emotional Pain Points:

• Frustration with complexity
• Anxiety about safety/security
• Embarrassment about relying on technology

Financial Pain Points:

• High costs of existing solutions
• Hidden ongoing expenses
• Wasted resources (energy, time)

Social Pain Points:

• Difficulty sharing information with others
• Privacy concerns with connected devices
• Accessibility challenges for some users

Example: Smart Pill Bottle Pain Point Analysis

Category	Pain Point	Current Solution	Opportunity
Functional	Forgetting to take pills	Phone alarms (easily dismissed)	Contextual reminder tied to bottle
Emotional	Anxiety about memory	Worry silently	Gentle confirmation without judgment
Social	Family worry	Daily check-in calls	Automatic “all good” notification
Financial	Expensive pill organizers	$40+ weekly dispensers	Simpler, affordable add-on

4.4 Stage 2: Define

4.4.1 Creating Problem Statements

Transform empathy insights into focused problem statements that guide solution development.

POV (Point of View) Framework:

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

Components:

• User: Specific person type, not “people” or “everyone”
• Need: A verb-based need, not a solution
• Insight: The surprising “why” that emerged from research

Example POV Statements:

Weak: “Users need a smart pill bottle because they forget to take medication.”

Strong: “Elderly people living independently need a simple way to confirm they took today’s medication because they fear burdening family with check-in calls and doubt their own memory.”

Why it’s better:

• Specific user (elderly living independently, not just “users”)
• Need framed as action (confirm they took medication)
• Insight reveals emotional depth (fear of burdening, self-doubt)

“How Might We” (HMW) Statements

Transform POV into ideation prompts using “How Might We”:

From POV: “Elderly people living independently need a simple way to confirm they took today’s medication because they fear burdening family.”

HMW Statements:

1. How might we make confirmation automatic without user effort?
2. How might we reassure family without feeling like surveillance?
3. How might we preserve dignity while providing reminders?
4. How might we make the solution obvious even for technology-hesitant users?

Why HMW Works:

• “How” invites exploration (not yes/no)
• “Might” gives permission to experiment
• “We” creates collaborative ownership
• Scoped enough to guide, open enough to inspire

4.4.2 Defining Success Metrics

User-Centered Metrics:

• Task completion rate (e.g., medication taken on time)
• User satisfaction scores (NPS, CSAT)
• Adoption rate (users who continue using after 30 days)
• Error rate (mistakes or failed interactions)

Technical Metrics:

• Device reliability (uptime percentage)
• Response time (latency for notifications)
• Battery life (for mobile/wearable devices)
• Data accuracy (sensor precision)

Business Metrics:

• Customer acquisition cost
• Monthly recurring revenue
• Churn rate
• Support ticket volume

Example: Smart Pill Bottle Success Metrics

Metric Type	Metric	Target	How to Measure
User	Medication adherence	>90%	Bottle sensor data
User	User satisfaction	>4.5/5	Monthly survey
Technical	Alert delivery success	>99%	Server logs
Technical	Battery life	>6 months	Field testing
Business	30-day retention	>80%	Usage analytics
Business	Support tickets	<5% of users	Helpdesk data

4.5 Knowledge Check

Quiz: Empathize and Define Stages

4.6 Worked Example: Empathize and Define for a Smart Water Leak Detector

Scenario: A home insurance company wants to reduce water damage claims (averaging $11,000 per incident, 2023 Insurance Information Institute data) by offering policyholders a subsidized smart water leak detector. The product team has 8 weeks to define the problem before prototyping begins.

Phase 1: Empathize – User Research (2 weeks)

The team conducted contextual inquiry with 18 homeowners who had experienced water damage in the past 3 years:

Research Method	Participants	Key Finding
In-home interviews	18 homeowners	14 of 18 knew their water main location but had never tested their shutoff valve
Observation (basement/utility rooms)	18 homes	11 of 18 had water heaters with visible corrosion; only 2 had any leak detection
Insurance claim review	200 claims	72% of damage occurred while homeowners were away (vacation, work)
Plumber interviews	5 professionals	Average leak-to-discovery time without detection: 8-14 days for slow leaks

Empathy Map (synthesized from 18 interviews):

Quadrant	Findings
SAYS	“I never think about water damage until it happens.” “The insurance claim process was a nightmare.” “I’d pay to avoid going through that again.”
THINKS	“My house is too old for smart devices.” “These gadgets probably need a plumber to install.” “What if it gives false alarms at 3 AM?”
DOES	Checks for leaks only when they hear dripping. Places towels under suspicious pipes. Turns off water main only when leaving for 2+ weeks.
FEELS	Anxious about hidden leaks (especially in walls). Frustrated by insurance deductibles ($1,000-$5,000). Skeptical about “smart home” complexity.

Critical gap discovered: Users SAY “I check for leaks regularly” but OBSERVATION shows they only notice active dripping. Slow seepage behind walls, under water heaters, or at supply line connections goes undetected for days to weeks.

Phase 2: Define – Problem Framing (1 week)

Pain Point Analysis:

Category	Pain Point	Severity	Current Workaround
Functional	Cannot detect slow leaks behind walls	Critical	None – discovered only when visible damage appears
Functional	No remote shutoff when away from home	High	Ask neighbor to check; turn off main before vacation
Emotional	Anxiety about “ticking time bomb” pipes in older homes	High	Avoid thinking about it
Financial	$1,000-$5,000 deductible even with insurance	High	None
Social	Embarrassment about water damage to neighbors below (condos)	Medium	Apologize; pay for repairs

POV Statement (weak first attempt): “Homeowners need a smart water leak detector.”

Problems: vague user (“homeowners”), solution-prescribing (“smart water leak detector”), no insight.

POV Statement (refined): “Homeowners aged 40-65 with houses over 15 years old need to detect and stop water leaks within minutes of onset, because slow leaks cause $11,000 average damage over 8-14 days of undetected seepage, and 72% of major water damage occurs while residents are away from home.”

Why this is better: specific user (age + home age), verb-based need (detect and stop), quantified insight (damage cost, detection delay, away-from-home statistic).

HMW Statements (generated 12, top 4 shown):

1. How might we detect water where it should never be, even behind walls or under floors?
2. How might we automatically stop water flow the moment a leak starts, without requiring the homeowner to be present?
3. How might we make leak detection work in older homes without requiring a plumber for installation?
4. How might we turn leak prevention into a financial incentive rather than an expense?

Success Metrics Defined:

Metric	Target	Measurement
Leak detection time	< 5 minutes from onset	Lab testing with calibrated drip rates
False alarm rate	< 1 per month per household	90-day field trial with 200 homes
Self-installation success	> 85% of users complete setup without help	Unboxing study with 30 users
Insurance claim reduction	> 40% fewer water damage claims	12-month controlled trial with insurer
User retention at 6 months	> 90% still have device active	Device telemetry analytics

Outcome: This empathize-define phase redirected the product concept. The team originally planned a simple moisture sensor pad. The research revealed that (a) detection alone is insufficient – automatic shutoff is essential because 72% of damage occurs while away, (b) installation anxiety is the primary adoption barrier, not price, and (c) the insurance discount (HMW #4) became the core go-to-market strategy, with the insurer subsidizing $60 of the $89 device cost in exchange for projected claim reduction savings of $2,200 per policyholder over 5 years.

Putting Numbers to It

Insurance economics drive IoT adoption decisions. Average water damage claim: $11,000. With 2% annual claim rate and $60 subsidy, insurer breaks even when:

\(\text{Subsidy per policy} < \text{Claim rate reduction} \times \text{Avg claim cost}\)

\(\$60 < \Delta_{rate} \times \$11,000\)

Required reduction: \(\Delta_{rate} > \frac{\$60}{\$11,000} = 0.00545 = 0.545\%\)

If leak detectors reduce claims from 2.0% to 1.5% (25% relative reduction = 0.5 percentage points):

\(\text{Savings per policy} = 0.005 \times \$11,000 = \$55/year\)

Over 5 years: \(5 \times \$55 = \$275\) saved vs \(\$60\) subsidy = $215 net profit per policy. With 200,000 policyholders, ROI = $43M over 5 years for $12M subsidy investment.

Interactive Calculator:

viewof ins_subsidy = Inputs.range([10, 200], {value: 60, step: 5, label: "Device subsidy per policy ($)"})
viewof ins_avg_claim = Inputs.range([5000, 20000], {value: 11000, step: 500, label: "Average claim cost ($)"})
viewof ins_initial_rate = Inputs.range([0.5, 5.0], {value: 2.0, step: 0.1, label: "Initial claim rate (%)"})
viewof ins_reduced_rate = Inputs.range([0.5, 5.0], {value: 1.5, step: 0.1, label: "Reduced claim rate (%)"})
viewof ins_years = Inputs.range([1, 10], {value: 5, step: 1, label: "Investment timeframe (years)"})
viewof ins_policyholders = Inputs.range([10000, 500000], {value: 200000, step: 10000, label: "Number of policyholders"})

ins_calc = {
  const rate_reduction = (ins_initial_rate - ins_reduced_rate) / 100;
  const required_reduction = ins_subsidy / ins_avg_claim;
  const savings_per_policy_per_year = rate_reduction * ins_avg_claim;
  const total_savings_per_policy = savings_per_policy_per_year * ins_years;
  const net_profit_per_policy = total_savings_per_policy - ins_subsidy;
  const total_investment = ins_subsidy * ins_policyholders;
  const total_roi = net_profit_per_policy * ins_policyholders;
  const roi_percentage = ((total_roi / total_investment) * 100).toFixed(1);

  return {
    rate_reduction: (rate_reduction * 100).toFixed(3),
    required_reduction: (required_reduction * 100).toFixed(3),
    savings_per_year: savings_per_policy_per_year.toFixed(2),
    total_savings: total_savings_per_policy.toFixed(2),
    net_profit: net_profit_per_policy.toFixed(2),
    total_investment: (total_investment / 1000000).toFixed(1),
    total_roi: (total_roi / 1000000).toFixed(1),
    roi_percentage: roi_percentage
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<h4 style="color: #2C3E50; margin-top: 0;">Insurance Economics Results</h4>
<table style="width: 100%; border-collapse: collapse;">
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Claim rate reduction:</strong></td>
  <td style="padding: 8px; text-align: right;">${ins_calc.rate_reduction}%</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Required reduction (break-even):</strong></td>
  <td style="padding: 8px; text-align: right;">${ins_calc.required_reduction}%</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Savings per policy per year:</strong></td>
  <td style="padding: 8px; text-align: right;">$${ins_calc.savings_per_year}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Total savings over ${ins_years} years:</strong></td>
  <td style="padding: 8px; text-align: right;">$${ins_calc.total_savings}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Net profit per policy:</strong></td>
  <td style="padding: 8px; text-align: right; color: ${parseFloat(ins_calc.net_profit) >= 0 ? '#16A085' : '#E74C3C'}; font-weight: bold;">$${ins_calc.net_profit}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Total investment (${ins_policyholders.toLocaleString()} policies):</strong></td>
  <td style="padding: 8px; text-align: right;">$${ins_calc.total_investment}M</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Total ROI:</strong></td>
  <td style="padding: 8px; text-align: right; color: ${parseFloat(ins_calc.total_roi) >= 0 ? '#16A085' : '#E74C3C'}; font-weight: bold;">$${ins_calc.total_roi}M (${ins_calc.roi_percentage}%)</td>
</tr>
</table>
</div>`

4.7 Quantitative Benchmarks for User Research

How much user research is enough? Industry data provides guidance:

4.7.1 Sample Sizes That Actually Work

Research Method	Minimum Sample	Optimal Sample	Diminishing Returns At	Source
Usability testing (qualitative)	5 users	8-12 users	15 users (95% of issues found)	Nielsen Norman Group
Contextual inquiry (observation)	8 sessions	15-20 sessions	25 sessions	Beyer & Holtzblatt
In-depth interviews	12 participants	20-30 participants	40 participants	Guest et al. (2006)
Diary studies	10 participants x 7 days	15-20 x 14 days	25 x 14 days
A/B testing (quantitative)	500 per variant	2,000 per variant	Depends on effect size
Survey (quantitative validation)	100 responses	300-500 responses	1,000+ responses

The 5-user rule: Jakob Nielsen’s research shows that 5 users find approximately 85% of usability issues. The 6th through 15th users primarily find duplicate issues. However, this applies only to usability testing of a single user segment. If your product serves 3 distinct segments (e.g., elderly patients, family caregivers, and medical staff), you need 5 users per segment = 15 users minimum.

Putting Numbers to It

Nielsen’s 5-user rule rests on probability theory. With average detection rate \(p = 0.31\) per tester, the probability that N testers collectively find a usability issue is:

\(P_{found}(N) = 1 - (1 - p)^N\)

For 5 testers: \(P_{found}(5) = 1 - (1 - 0.31)^5 = 1 - 0.1564 = 0.8436 \text{ (84.4\%)}\)

For 15 testers: \(P_{found}(15) = 1 - (1 - 0.31)^{15} = 0.9899 \text{ (98.9\%)}\)

Diminishing returns calculation: Going from 5 to 15 testers triples cost ($300 → $900 stipends) but only gains 14.5% more issues found. The marginal value per additional tester drops from 16.9% (tester 1) to 0.8% (tester 15).

Interactive Calculator:

viewof nielsen_p = Inputs.range([0.1, 0.5], {value: 0.31, step: 0.01, label: "Detection rate per tester (p)"})
viewof nielsen_n = Inputs.range([1, 30], {value: 5, step: 1, label: "Number of testers (N)"})
viewof nielsen_cost_per_tester = Inputs.range([20, 200], {value: 60, step: 10, label: "Cost per tester ($)"})

nielsen_calc = {
  const p_found = 1 - Math.pow(1 - nielsen_p, nielsen_n);
  const total_cost = nielsen_n * nielsen_cost_per_tester;

  // Calculate marginal value (difference from previous tester)
  const p_found_prev = nielsen_n > 1 ? 1 - Math.pow(1 - nielsen_p, nielsen_n - 1) : 0;
  const marginal_gain = p_found - p_found_prev;

  return {
    p_found: (p_found * 100).toFixed(2),
    total_cost: total_cost,
    marginal_gain: (marginal_gain * 100).toFixed(2),
    cost_per_percent: (nielsen_cost_per_tester / (marginal_gain * 100)).toFixed(2)
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<h4 style="color: #2C3E50; margin-top: 0;">Nielsen's 5-User Rule Calculator</h4>
<table style="width: 100%; border-collapse: collapse;">
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Issues found with ${nielsen_n} tester(s):</strong></td>
  <td style="padding: 8px; text-align: right; color: #16A085; font-weight: bold;">${nielsen_calc.p_found}%</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Total testing cost:</strong></td>
  <td style="padding: 8px; text-align: right;">$${nielsen_calc.total_cost}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Marginal gain (tester #${nielsen_n}):</strong></td>
  <td style="padding: 8px; text-align: right;">${nielsen_calc.marginal_gain}%</td>
</tr>
<tr>
  <td style="padding: 8px;"><strong>Cost per percentage point found:</strong></td>
  <td style="padding: 8px; text-align: right;">$${nielsen_calc.cost_per_percent}</td>
</tr>
</table>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: #7F8C8D;">
<em>Note: Diminishing returns become apparent as N increases. Compare cost per percentage point across different values of N.</em>
</p>
</div>`

4.7.2 Research Budget Allocation

A common question from product teams: “What percentage of the project budget should go to user research?”

Project Phase	% of Phase Budget	Activities	IoT-Specific Considerations
Discovery/Empathize	8-12% of total budget	Interviews, observations, competitive analysis	Include home visits (IoT devices live in physical spaces)
Define	3-5%	Synthesis workshops, persona creation	Test with non-technical users (50%+ of IoT buyers)
Prototype	5-8%	Usability testing per iteration	Test physical + digital together (not just the app)
Post-launch	2-4% ongoing	Analytics review, support ticket analysis	Monitor device abandonment rates (30-day, 90-day)
Total	18-29%

Putting Numbers to It

Budget allocation for $200K IoT project following 18-29% research guideline. Baseline: $100K labor (50%), $40K hardware/certs (20%), $60K remaining (30%).

Minimum research budget (18%): $200K × 0.18 = \(36,000\) - Discovery/Empathize: $200K × 0.10 = $20,000 (10 users × $2K each = interviews + analysis) - Define: $200K × 0.04 = $8,000 (2-week synthesis sprint) - Prototype testing: $200K × 0.065 = $13,000 (3 test rounds × 5 users)

Optimal research budget (25%): $200K × 0.25 = \(50,000\)

If research prevents one major pivot ($47K from earlier example): Break-even research spend = $47K. At 35% pivot probability without research: Expected ROI = \(\frac{0.35 \times \$47,000}{\$36,000} - 1 = 45.7\%\) above break-even.

Interactive Calculator:

viewof budget_total = Inputs.range([50000, 1000000], {value: 200000, step: 10000, label: "Total project budget ($)"})
viewof budget_research_pct = Inputs.range([5, 40], {value: 18, step: 1, label: "Research budget (%)"})
viewof budget_discovery_pct = Inputs.range([5, 15], {value: 10, step: 0.5, label: "Discovery/Empathize (% of total)"})
viewof budget_define_pct = Inputs.range([2, 8], {value: 4, step: 0.5, label: "Define (% of total)"})
viewof budget_prototype_pct = Inputs.range([3, 10], {value: 6.5, step: 0.5, label: "Prototype testing (% of total)"})

budget_calc = {
  const total_research = budget_total * (budget_research_pct / 100);
  const discovery = budget_total * (budget_discovery_pct / 100);
  const define = budget_total * (budget_define_pct / 100);
  const prototype = budget_total * (budget_prototype_pct / 100);
  const actual_pct = ((discovery + define + prototype) / budget_total * 100).toFixed(1);

  return {
    total_research: total_research.toFixed(0),
    discovery: discovery.toFixed(0),
    define: define.toFixed(0),
    prototype: prototype.toFixed(0),
    actual_total: (discovery + define + prototype).toFixed(0),
    actual_pct: actual_pct
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
<h4 style="color: #2C3E50; margin-top: 0;">Research Budget Allocation</h4>
<table style="width: 100%; border-collapse: collapse;">
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Discovery/Empathize (${budget_discovery_pct}%):</strong></td>
  <td style="padding: 8px; text-align: right;">$${parseInt(budget_calc.discovery).toLocaleString()}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Define (${budget_define_pct}%):</strong></td>
  <td style="padding: 8px; text-align: right;">$${parseInt(budget_calc.define).toLocaleString()}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Prototype testing (${budget_prototype_pct}%):</strong></td>
  <td style="padding: 8px; text-align: right;">$${parseInt(budget_calc.prototype).toLocaleString()}</td>
</tr>
<tr style="border-top: 2px solid #2C3E50;">
  <td style="padding: 8px;"><strong>Total research budget:</strong></td>
  <td style="padding: 8px; text-align: right; color: #16A085; font-weight: bold;">$${parseInt(budget_calc.actual_total).toLocaleString()} (${budget_calc.actual_pct}%)</td>
</tr>
<tr>
  <td style="padding: 8px;"><strong>Remaining for development:</strong></td>
  <td style="padding: 8px; text-align: right;">$${(budget_total - parseInt(budget_calc.actual_total)).toLocaleString()}</td>
</tr>
</table>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: ${parseFloat(budget_calc.actual_pct) >= 18 && parseFloat(budget_calc.actual_pct) <= 29 ? '#16A085' : '#E67E22'};">
<em>${parseFloat(budget_calc.actual_pct) >= 18 && parseFloat(budget_calc.actual_pct) <= 29 ? '✓ Within recommended 18-29% research budget range' : '⚠ Outside recommended 18-29% research budget range'}</em>
</p>
</div>`

ROI of user research: A study by the IEEE (2018) across 60 software projects found that every $1 invested in user research during the discovery phase saved $10-$100 in development rework later. For IoT products with physical hardware, the savings are even larger because hardware changes after tooling are 10-50x more expensive than software changes.

Putting Numbers to It

User research ROI for IoT hardware. Discovery phase: 10 interviews × 2 hrs × $150/hr = $3,000. Without research, probability of major pivot after PCB: 35%.

Cost of post-PCB pivot:

• PCB redesign: $2,500 (engineering) + $1,200 (fab) = \(3,700\)
• Component changes: $800
• Testing re-validation: 40 hrs × $120/hr = $4,800
• Timeline delay: 6 weeks × $25K/month burn = $37,500
• Total pivot cost: $46,800

Expected cost without research: \(0.35 \times \$46,800 = \$16,380\)

With research (reduces pivot risk to 8%): \(\text{Expected cost with research} = \$3,000 + 0.08 \times \$46,800 = \$6,744\)

Net savings: \(\$16,380 - \$6,744 = \$9,636\) (321% ROI)

Interactive Calculator:

viewof roi_research_cost = Inputs.range([1000, 20000], {value: 3000, step: 500, label: "Research cost ($)"})
viewof roi_pcb_redesign = Inputs.range([1000, 10000], {value: 3700, step: 100, label: "PCB redesign cost ($)"})
viewof roi_components = Inputs.range([100, 5000], {value: 800, step: 100, label: "Component changes ($)"})
viewof roi_testing = Inputs.range([1000, 15000], {value: 4800, step: 200, label: "Testing re-validation ($)"})
viewof roi_delay = Inputs.range([5000, 100000], {value: 37500, step: 2500, label: "Timeline delay cost ($)"})
viewof roi_pivot_prob_no_research = Inputs.range([10, 80], {value: 35, step: 5, label: "Pivot probability without research (%)"})
viewof roi_pivot_prob_with_research = Inputs.range([1, 30], {value: 8, step: 1, label: "Pivot probability with research (%)"})

roi_calc = {
  const total_pivot_cost = roi_pcb_redesign + roi_components + roi_testing + roi_delay;
  const expected_cost_no_research = (roi_pivot_prob_no_research / 100) * total_pivot_cost;
  const expected_cost_with_research = roi_research_cost + (roi_pivot_prob_with_research / 100) * total_pivot_cost;
  const net_savings = expected_cost_no_research - expected_cost_with_research;
  const roi_percentage = ((net_savings / roi_research_cost) * 100).toFixed(1);

  return {
    total_pivot_cost: total_pivot_cost.toFixed(0),
    expected_no_research: expected_cost_no_research.toFixed(0),
    expected_with_research: expected_cost_with_research.toFixed(0),
    net_savings: net_savings.toFixed(0),
    roi_percentage: roi_percentage
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #9B59B6; margin-top: 0.5rem;">
<h4 style="color: #2C3E50; margin-top: 0;">User Research ROI Calculator</h4>
<table style="width: 100%; border-collapse: collapse;">
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Total pivot cost (if it happens):</strong></td>
  <td style="padding: 8px; text-align: right;">$${parseInt(roi_calc.total_pivot_cost).toLocaleString()}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Expected cost WITHOUT research:</strong></td>
  <td style="padding: 8px; text-align: right; color: #E74C3C;">$${parseInt(roi_calc.expected_no_research).toLocaleString()}</td>
</tr>
<tr style="border-bottom: 1px solid #ddd;">
  <td style="padding: 8px;"><strong>Expected cost WITH research:</strong></td>
  <td style="padding: 8px; text-align: right; color: #16A085;">$${parseInt(roi_calc.expected_with_research).toLocaleString()}</td>
</tr>
<tr style="border-top: 2px solid #2C3E50;">
  <td style="padding: 8px;"><strong>Net savings:</strong></td>
  <td style="padding: 8px; text-align: right; color: ${parseFloat(roi_calc.net_savings) >= 0 ? '#16A085' : '#E74C3C'}; font-weight: bold;">$${parseInt(roi_calc.net_savings).toLocaleString()}</td>
</tr>
<tr>
  <td style="padding: 8px;"><strong>ROI on research investment:</strong></td>
  <td style="padding: 8px; text-align: right; color: ${parseFloat(roi_calc.roi_percentage) >= 0 ? '#16A085' : '#E74C3C'}; font-weight: bold;">${roi_calc.roi_percentage}%</td>
</tr>
</table>
<p style="margin-top: 0.5rem; font-size: 0.9em; color: #7F8C8D;">
<em>Research reduces pivot probability from ${roi_pivot_prob_no_research}% to ${roi_pivot_prob_with_research}%, saving an expected $${parseInt(roi_calc.net_savings).toLocaleString()}.</em>
</p>
</div>`

4.7.3 When to Stop Researching and Start Building

Signal	Action
You hear the same pain points from 3+ unrelated users	Pain point is real – define it
Empathy map quadrants are filling with consistent data	Synthesis is converging – move to Define
New interviews produce no new insights (saturation)	Stop interviewing, start defining
Stakeholders are quoting user research in meetings	Research has penetrated the team – leverage it
You can predict what the next user will say	You have enough qualitative data – validate quantitatively

4.8 Common Pitfalls

Pitfall: Confirmation Bias in User Research

The Mistake: Asking leading questions like “Would you use a smart device that does X?” or only interviewing users who already like your concept. You hear what you want to hear, not what users actually need.

Why It Happens: Teams are emotionally invested in their ideas. Interview questions unconsciously lead users toward confirming the concept. Researchers nod enthusiastically at positive feedback, causing users to agree more. Negative feedback is dismissed as “that user doesn’t get it.”

The Fix: Use neutral questions: “Tell me about the last time you…” instead of “Do you want…?” Include skeptics in user research. Have someone outside the team review interview transcripts for bias. Ask “What would make you NOT use this?” to surface objections.

Pitfall: Solving the Wrong Problem (Defining Too Early)

The Mistake: Creating a problem statement that’s actually a solution in disguise. Example: “Users need a Bluetooth-connected device” - this prescribes Bluetooth before understanding if connectivity is even needed.

Why It Happens: Engineers naturally think in solutions. The excitement of building overshadows the discipline of understanding. Stakeholders pressure teams to “get building” before research is complete.

The Fix: Test your problem statement: Does it mention any specific technology? If yes, rewrite it. Use the formula: “[User] needs [need] because [insight]” - where “need” must be a verb, not a noun/product.

Match the Research Technique to Its Purpose

Order the Empathize-to-Define Workflow

Label the Diagram

💻 Code Challenge

4.9 Summary

• User Research Techniques: Observation, interviews, empathy mapping, contextual inquiry, and journey mapping reveal user needs that users themselves may not articulate directly
• Empathy Map Quadrants: SAYS (direct quotes), THINKS (inferred beliefs), DOES (observable behaviors), FEELS (emotions) provide a complete picture of user experience
• Pain Point Categories: Functional (tasks), emotional (feelings), financial (costs), and social (relationships) pain points guide comprehensive problem understanding
• POV Statement Formula: “[User] needs [need] because [insight]” ensures problem statements remain user-centered and avoid prescribing solutions
• HMW Statements: “How Might We” transforms problem statements into ideation prompts that invite creative exploration while maintaining focus
• Success Metrics: User-centered, technical, and business metrics should be defined before prototyping to enable objective evaluation of solutions

4.10 Concept Relationships

Empathize and Define in the Design Thinking Flow

Empathize → Define Connection:

• Raw observations (Says/Does) → Insights (Thinks/Feels) → Problem Statement
• User quotes → Pain points → HMW questions → Solution space

Define → Ideate Gateway:

• Weak problem statement (“users want technology”) → Scattered, unfocused ideas
• Strong problem statement (“[specific user] needs [verb action] because [insight]”) → Targeted, relevant solutions

Common Patterns:

• 5 user interviews → Pattern emerges (3+ users share pain point) → Valid problem
• Empathy map gap: Says ≠ Does → Hidden insight → Breakthrough innovation
• POV insight section → Becomes design constraint (“must preserve dignity” = no invasive monitoring)

4.11 See Also

Related Resources

Previous/Next in Series:

• Design Thinking Introduction - Seven-phase overview, problem statement formula
• Ideate, Prototype, Test - Using HMW statements to generate solutions

Deep Dives:

• User Research Methods - Contextual inquiry, diary studies, surveys
• Persona Development - Creating detailed user personas from empathy data
• Journey Mapping - Visualizing user experience across touchpoints

4.12 What’s Next

Continue to Ideate, Prototype, and Test to learn brainstorming techniques, prototype fidelity levels, and user testing methods that validate your problem definition with real users.

Previous	Current	Next
Design Thinking Introduction	Empathize and Define	Ideate, Prototype, and Test