1634 Empathize and Define

1634.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
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

1634.2 Prerequisites

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

1634.3 Stage 1: Empathize

1634.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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#fff', 'fontSize': '14px'}}}%%
graph TD
    subgraph EmpathyMap["Empathy Map: Smart Pill Bottle User"]
        subgraph Says["SAYS"]
            S1["'I forget if I took my pills'"]
            S2["'My kids worry about me'"]
            S3["'These bottles are hard to open'"]
        end

        subgraph Thinks["THINKS"]
            T1["'Am I getting too old?'"]
            T2["'I don't want to be a burden'"]
            T3["'Why is this so complicated?'"]
        end

        subgraph Does["DOES"]
            D1["Checks bottle multiple times"]
            D2["Asks spouse if pills were taken"]
            D3["Sets phone alarms"]
        end

        subgraph Feels["FEELS"]
            F1["Anxious about health"]
            F2["Frustrated by complexity"]
            F3["Embarrassed by forgetfulness"]
        end
    end

    style Says fill:#16A085,stroke:#2C3E50
    style Thinks fill:#2C3E50,stroke:#16A085
    style Does fill:#E67E22,stroke:#2C3E50
    style Feels fill:#7F8C8D,stroke:#2C3E50

Figure 1634.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:

%% fig-cap: "Blank Empathy Map Template"
%% fig-alt: "Four-quadrant empathy map template with SAYS quadrant for direct quotes from users, THINKS quadrant for inferred thoughts and beliefs, DOES quadrant for observable behaviors and actions, and FEELS quadrant for emotions and frustrations. Center shows target user persona placeholder."

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#fff', 'fontSize': '12px'}}}%%
graph TD
    subgraph template["EMPATHY MAP: [User Name/Type]"]
        subgraph says["SAYS"]
            s1["• Direct quotes..."]
            s2["• Verbal statements..."]
            s3["• What they tell others..."]
        end
        subgraph thinks["THINKS"]
            t1["• Internal beliefs..."]
            t2["• What they wonder..."]
            t3["• Unspoken concerns..."]
        end
        subgraph does["DOES"]
            d1["• Observable actions..."]
            d2["• Behaviors..."]
            d3["• Workarounds..."]
        end
        subgraph feels["FEELS"]
            f1["• Emotions..."]
            f2["• Frustrations..."]
            f3["• Fears/desires..."]
        end
    end

    style says fill:#16A085,stroke:#2C3E50
    style thinks fill:#2C3E50,stroke:#16A085
    style does fill:#E67E22,stroke:#2C3E50
    style feels fill:#7F8C8D,stroke:#2C3E50

Figure 1634.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.

1634.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

1634.4 Stage 2: Define

1634.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

1634.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

1634.5 Knowledge Check

Quiz: Empathize and Define Stages

Question 1: During the Empathize stage for a smart home product, you observe that users frequently override their automated thermostat schedule. What should you do FIRST?

Explanation: Option D follows the Empathize principle of understanding before solving. Observing overrides is data; understanding WHY reveals the real problem. Users might override because: guests are visiting, they’re sick and need different temperature, the schedule doesn’t match their actual routine, or they don’t trust automation. Each reason leads to a different solution. Options A-C jump to solutions without understanding the root cause.

Question 2: Which empathy map quadrant would contain the observation: “User checks security camera app 15 times per day”?

Explanation: “Checks camera 15 times per day” is an observable behavior (DOES). While it might suggest anxiety (FEELS) or worry about security (THINKS), the observation itself is what the user physically does. Proper empathy mapping separates facts (DOES, SAYS) from inferences (FEELS, THINKS). Noting this in DOES allows the team to then ask “why?” to fill in the other quadrants.

Question 3: A POV statement reads: “People need a smart lock.” What is WRONG with this statement?

Explanation: The POV formula requires: [Specific User] needs [verb-based need] because [insight]. “People” is too vague (specific user missing), “a smart lock” is a solution not a need (should be verb-based like “to grant temporary access”), and there’s no insight (why). A better version: “Short-term rental hosts need to grant temporary access to guests without physical key exchange because they manage multiple properties remotely and can’t meet every guest.”

Question 4: You’re creating “How Might We” statements for a smart irrigation system. Which HMW is BEST?

Explanation: Option B is user-centered (busy homeowners), need-focused (maintain healthy lawns), and insight-driven (minimal effort). Option A prescribes a technology (sensors), Option C prescribes ML, and Option D focuses on a metric rather than user need. Good HMW statements leave the solution space open while clearly defining who and what.

1634.6 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.

1634.7 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

1634.8 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.