Unit 2: Empathy, Observation and Problem Identification

INT335 — Design Thinking 10 min read

I. Orientation

Design thinking begins by understanding people before defining solutions. Empathy, observation, and research help designers identify what users actually do, feel, need, and struggle with. Problem identification converts evidence from real users into a focused problem statement rather than an assumption or premature solution.

Human-centred focus: Decisions begin with user experiences, such as difficulty completing a form, rather than with a preferred technology.
Evidence before interpretation: Observed behaviour, interview statements, and usage data should support conclusions.
Context matters: The same action may have different meanings at home, at work, online, or under time pressure.
Divergent and convergent thinking: Research expands understanding; synthesis narrows evidence into insights and problem definitions.
Needs versus solutions: “Users need faster checkout” describes a need; “add a large blue button” is a proposed solution.
Ethical responsibility: Researchers protect privacy, obtain informed participation, avoid manipulation, and represent users accurately.

II. User Empathy and Research Methods — Understanding the person behind the task

A. User Empathy and Research Methods

User empathy is the disciplined attempt to understand a user’s perspective, emotions, motivations, abilities, and constraints. Research methods provide structured ways to replace designer assumptions with evidence.

Perspective-taking: Consider what a first-time banking-app user sees when asked to enter unfamiliar financial information.
Emotional understanding: Record feelings such as anxiety, embarrassment, confidence, or frustration alongside observable actions.
Method selection: Use interviews for beliefs, observation for behaviour, surveys for measurable patterns, and usability tests for interaction difficulties.
Triangulation: Compare sources; for example, a user may claim to shop weekly in an interview while transaction data shows daily purchases.
Ethical practice: Explain the research purpose, request consent, anonymise sensitive statements, and allow participants to withdraw.

III. Computational Empathy in Software Engineering — Translating user experience into system behaviour

A. Computational Empathy in Software Engineering

Computational empathy applies empathy principles to software design and engineering so that systems respond appropriately to users’ goals, limitations, emotions, and context.

Accessible interaction: A form should support keyboard navigation, readable contrast, screen readers, and clear error messages for users with different abilities.
Context-aware behaviour: A mobile application may simplify actions when connectivity is poor or when the user is operating it with one hand.
Emotion-sensitive design: A failed payment should use calm, specific language such as “Payment was not completed; check your card details,” rather than a cryptic error code.
Human override: Automated recommendations, moderation, or support systems should offer escalation when the system misinterprets a user’s situation.
Data responsibility: Emotion or behaviour data must be collected transparently; inferred sentiment should not be treated as certain evidence of a user’s intentions.

IV. Qualitative and Quantitative User Research — Depth and measurable breadth

A. Qualitative and Quantitative User Research

Qualitative research explores meanings and experiences, while quantitative research measures frequency, scale, or relationships using numerical evidence.

Qualitative evidence: Interviews, field notes, diary entries, and open-ended responses reveal why a user avoids a feature or develops a workaround.
Quantitative evidence: A survey showing that 62% of 500 respondents abandon a registration process indicates scale but may not explain the reason.
Sampling purpose: Qualitative samples seek relevant variation, such as novice and expert users; quantitative samples seek sufficient size and representativeness.
Analysis methods:
- Qualitative: Code statements into themes such as “trust,” “confusion,” or “time pressure.”
- Quantitative: Calculate frequencies, averages, conversion rates, or task-completion percentages.
Complementarity: Use qualitative interviews to discover possible causes, then use a survey or analytics to test how widespread those causes are.

V. Field Observation and AEIOU Framework — Studying behaviour in context

A. Field Observation and AEIOU Framework

Field observation examines users in their real environment, where physical conditions, interruptions, tools, and social relationships influence behaviour. AEIOU provides five lenses for organising observations.

Activities: Record what users do, such as “checks stock before promising an item,” rather than interpreting it immediately as “is inefficient.”
Environments: Note layout, lighting, noise, temperature, connectivity, and space; a warehouse worker’s scanning errors may increase in a crowded aisle.
Interactions: Observe person-to-person, person-to-device, and person-to-object relationships, including when users ask colleagues for help.
Objects: Identify tools and artefacts, such as paper notes, barcode scanners, passwords, or improvised labels.
Users: Describe roles, experience levels, goals, and constraints without reducing a person to a stereotype.
Observation discipline: Timestamp events, separate description from interpretation, and avoid changing the setting through unnecessary intervention.

VI. User Interviews and Inquiry Techniques — Eliciting experience rather than rehearsed opinion

A. User Interviews and Inquiry Techniques

A user interview is a planned conversation used to uncover experiences, decisions, motivations, and unmet needs. Effective inquiry encourages concrete accounts of past behaviour instead of hypothetical preferences.

Open questions: Ask “Tell me about the last time you returned an item” rather than “Would you use an easier return process?”
Probing: Follow a significant statement with “What happened next?” or “Why was that difficult?” to expose causes and consequences.
Critical incidents: Ask about a recent success or failure; a specific incident can reveal more than a general opinion.
Laddering: Move from an action to its reason: “You save receipts” → “Why?” → “So you can prove purchase if a dispute occurs.”
Avoiding bias: Do not lead with “How helpful is this feature?” because the question assumes the feature is helpful.
Interview structure: Establish consent, begin with context, explore recent behaviour, clarify language, and end by checking whether important issues were missed.
Documenting evidence: Capture exact phrases, pauses, workarounds, and contradictions; interpret them during synthesis rather than interrupting the participant.

VII. User Needs and Problem Identification — Converting evidence into a design focus

A. User Needs and Problem Identification

User needs are the outcomes, capabilities, or conditions users require to achieve a goal. Problem identification defines the obstacle clearly enough to guide design without prescribing a particular solution.

Need formulation: “A commuter needs to know whether a train is delayed before leaving home” identifies an outcome, unlike “needs a notification feature.”
Evidence chain: Link observation to effect: “User rereads the dosage label three times, delaying medication use and increasing uncertainty.”
Problem statement: State user, context, difficulty, and consequence: “New patients struggle to locate appointment instructions because the portal separates them across three menus.”
Root-cause analysis: Ask why repeatedly; a missed deadline may arise from unclear ownership, not simply from a missing reminder.
Scope control: Define a specific user group and situation, avoiding broad claims such as “everyone needs a better website.”
Prioritisation: Consider frequency, severity, affected users, strategic importance, and feasibility; an occasional safety issue may outrank a frequent minor inconvenience.

VIII. Explicit and Implicit User Needs — Stated requirements and hidden expectations

A. Explicit and Implicit User Needs

Explicit needs are directly stated by users, while implicit needs are unstated expectations inferred from behaviour, context, or accepted standards.

Explicit need: A user says, “I need to download my invoices as a PDF,” which is a clear requested outcome.
Implicit need: The same user may also need confidence that the downloaded invoice is authentic, searchable, and stored securely.
Inference basis: Treat implicit needs as hypotheses supported by evidence, such as repeated checking, workaround use, hesitation, or abandonment.
Distinguishing wants: “Add more colour” may be a preference; the underlying need may be better status visibility or easier differentiation.
Validation: Test inferred needs through follow-up interviews, observation, prototype evaluation, or behavioural data.
Risk of assumption: Designers can project their own expectations; an unverified implicit need should not become a mandatory requirement.

IX. User Pain Points and Problem Identification — Locating friction and consequence

A. User Pain Points and Problem Identification

A pain point is a recurring or meaningful difficulty that creates effort, delay, risk, confusion, dissatisfaction, or emotional strain during a user journey.

Time pain: A customer re-enters the same address on four checkout screens, adding measurable delay.
Process pain: An employee must switch between an inventory system and a spreadsheet because the official system lacks a comparison view.
Financial pain: Hidden service fees cause users to revise a purchase after reaching the final payment step.
Emotional pain: Repeated password failures can create anxiety, especially when account access is urgent.
Severity and frequency: A problem affecting 1,000 users once may deserve different treatment from a safety-critical problem affecting 20 users.
Problem framing: Describe the friction and consequence, not the fix: “Caregivers cannot confirm whether a medication reminder was acknowledged, creating uncertainty,” rather than “build a dashboard.”

X. User Personas and Target Archetypes — Representing evidence-based user groups

A. User Personas and Target Archetypes

A persona is a research-grounded representation of a meaningful user group; a target archetype is a broader behavioural pattern used to focus design decisions.

Evidence base: Build personas from recurring research patterns, such as shared goals, behaviours, constraints, and environments, not invented demographic detail.
Core fields: Include name or label, role, goals, behaviours, frustrations, technical context, and a representative quotation grounded in research.
Behavioural distinction: “Time-pressed coordinator” may be more useful than age alone because it explains prioritisation and workflow.
Primary and secondary users: Identify who directly uses the system and who influences, supports, or is affected by it.
Avoiding stereotypes: Do not treat a persona as every member of a demographic group; state its boundaries and evidence.
Design use: Evaluate a proposed feature by asking whether it helps the persona achieve a documented goal under a documented constraint.

XI. Empathy Mapping and User Insights — Synthesising what research means

A. Empathy Mapping and User Insights

An empathy map organises evidence about a user into what the user says, thinks, does, and feels, helping teams identify patterns and generate actionable insights.

Says: Record a relevant statement, such as “I do not know whether the request went through,” using the user’s own words when possible.
Thinks: Infer concerns cautiously from context, such as uncertainty about whether submitting twice will create duplicate requests.
Does: Document observable actions, including refreshing a page, asking a colleague, or saving a screenshot.
Feels: Note emotions connected to events, such as anxiety during a failed submission or relief after receiving confirmation.
Pains and gains: Add obstacles and desired outcomes; the pain is uncertainty, while the gain is reliable confirmation.
Evidence marking: Distinguish direct quotes and observations from interpretations so the map does not present assumptions as facts.
Insight formation: An insight connects evidence to meaning: “Because users cannot distinguish saved drafts from submitted forms, they repeatedly resubmit requests to reduce uncertainty.”
Design implication: Convert the insight into a question such as “How might the system make submission status unmistakable?” while preserving freedom to explore multiple solutions.
Synthesis process: Cluster repeated observations, compare exceptions, identify tensions, and validate the resulting insight with additional users or existing data.