Unit 2: Empathy, Observation and Problem Identification

I. Foundations of Human-Centred Problem Discovery

Design thinking is a human-centred, iterative approach to innovation that begins by understanding people before defining solutions. Empathy and observation reduce the risk of solving an assumed problem; problem identification converts research evidence into a focused design challenge.

• Governing principle: Design decisions should be grounded in evidence about users’ behaviours, goals, environments, constraints, and emotions.
• Human-centred orientation: The unit of analysis is the person in context, not merely a product feature or technical failure.
• Evidence before solutions: Researchers first collect observations, statements, and measurements, then synthesize them into needs and problem statements.
• Iteration: Empathizing and defining are not strictly linear; prototype feedback may expose new needs and require further research.
• Triangulation: Confidence increases when interviews, observations, analytics, and other sources point toward the same finding.
• Ethical responsibility: Researchers should obtain informed consent, protect personal data, avoid manipulation, and represent users without stereotyping.
• Core progression:
  • Research produces raw evidence.
  • Interpretation reveals patterns and tensions.
  • Synthesis creates insights, personas, and empathy maps.
  • Problem framing identifies a meaningful opportunity for design.

II. Empathy and User Research — Building Evidence-Based Understanding

A. User Empathy and Research Methods

User empathy is the disciplined effort to understand another person’s experience from that person’s perspective rather than relying on the designer’s assumptions.

• Dimensions of empathy:
  • Cognitive empathy: Understanding what a user thinks, such as why a commuter distrusts an arrival-time estimate.
  • Emotional empathy: Recognizing feelings, such as anxiety during an online payment failure.
  • Compassionate empathy: Using understanding to reduce a genuine difficulty without taking control away from the user.
• Research methods: Common methods include contextual observation, interviews, diary studies, surveys, usability testing, analytics, and review analysis.
• Method selection: The research question determines the method; “How often does abandonment occur?” suits analytics, while “Why do users abandon?” requires qualitative inquiry.
• Empathic conduct: Researchers use neutral language, listen without interruption, notice contradictions, and separate evidence from interpretation.
• Research record: A useful note distinguishes a direct quote such as “I save the receipt until delivery” from the inference that the user lacks trust.
• Bias control: Reflexive notes, diverse recruitment, multiple researchers, and evidence tagging help limit confirmation and similarity biases.

B. Computational Empathy in Software Engineering

Computational empathy applies user-centred understanding to software systems by using behavioural data and contextual signals to anticipate or respond to user difficulty.

• Operational signals: Repeated clicks, undo actions, long task times, error logs, cursor hesitation, and support requests can indicate confusion or frustration.
• Adaptive response: A system may offer contextual help after three failed submissions, but it should not infer a sensitive emotional state without sufficient evidence.
• Engineering application: Developers can translate empathy into accessible defaults, recoverable errors, informative messages, and workflows tolerant of mistakes.
• Data pipeline:
  • Events such as payment_failed are captured with time and context.
  • Patterns are aggregated across sessions.
  • Researchers interpret patterns alongside interviews.
  • Teams implement and test a response.
• Ethical boundaries: Consent, data minimization, explainability, security, and opt-out controls are essential because behavioural traces can expose private circumstances.
• Key limitation: A measurable action is not an emotion; rapid clicking may indicate urgency, habit, a device defect, or frustration.

C. Qualitative and Quantitative User Research

Qualitative research explains meanings and motivations, whereas quantitative research measures frequency, magnitude, and relationships.

1. Qualitative research:

   • Data form: Interview transcripts, photographs, field notes, diary entries, and observed behaviours.
   • Typical sample: Small, purposively selected groups provide depth rather than statistical representation.
   • Analysis: Coding and thematic analysis may group evidence under themes such as “uncertain fees” or “fear of irreversible action.”
   • Strength: It reveals unexpected needs and explains why a behaviour occurs.
   • Limitation: Findings can be influenced by researcher interpretation and cannot automatically be generalized.

2. Quantitative research:

   • Data form: Task completion rates, ratings, conversion percentages, error counts, and time measured in seconds.
   • Typical sample: Larger samples support comparison and statistical inference when sampling is appropriate.
   • Strength: It estimates scale; for example, analytics may show that 28% of sessions end at identity verification.
   • Limitation: A percentage identifies where a problem occurs but may not explain its cause.

A basic completion rate is:

Completion rate = (C / N) × 100

Here, C is the number of users who complete the task, and N is the number who attempt it.

• Mixed-method design: Analytics can locate a high-drop-off step, interviews can explain the obstacle, and usability testing can evaluate a revised design.

III. Contextual Observation and Inquiry — Studying Real Behaviour

A. Field Observation and AEIOU Framework

Field observation examines users in the environment where an activity naturally occurs, capturing contextual details that participants may forget or consider too ordinary to mention.

• Observation focus: Researchers record actions, sequences, workarounds, interruptions, physical conditions, tools, and interactions without immediately judging them.
• AEIOU framework:
  • Activities: Goal-directed actions, such as scanning an item, comparing prices, and completing payment.
  • Environments: Physical or digital settings, including noise, lighting, connectivity, layout, and privacy.
  • Interactions: Exchanges between people, systems, and objects, such as a passenger asking staff to interpret a ticket machine.
  • Objects: Tools and artefacts involved, including forms, phones, labels, receipts, and assistive devices.
  • Users: Participants, roles, capabilities, relationships, and relevant characteristics.
• Concrete recording: “User checked the printed list four times in six minutes” is stronger evidence than “user was confused.”
• Researcher role: Observation may be non-participant or participant-based, but the degree of involvement should be documented.
• Limitations: The observer’s presence can alter behaviour, rare events may not occur, and private environments require careful consent.

B. User Interviews and Inquiry Techniques

User interviews are purposeful conversations used to uncover experiences, decisions, priorities, language, and interpretations that are not directly observable.

• Interview structure: Structured interviews standardize questions; semi-structured interviews combine consistency with probing; unstructured interviews favour exploration.
• Question design: Open prompts such as “Describe the last time you renewed the service” produce richer evidence than “Was renewal easy?”
• Behavioural anchoring: Asking about a specific recent event reduces hypothetical and socially desirable responses.
• Inquiry techniques:
  • Probing: “What happened next?” expands an account without suggesting an answer.
  • Five Whys: Repeatedly exploring causes can move from a visible complaint to an underlying need.
  • Critical incident technique: Participants describe a particularly successful or difficult event.
  • Contextual inquiry: The participant performs real work while explaining decisions to the researcher.
• Neutrality: Leading questions such as “How useful was our convenient dashboard?” contaminate evidence by embedding a positive judgment.
• Documentation: With permission, recordings preserve exact language; notes should mark observations, quotations, and interpretations separately.

IV. Needs and Problem Definition — Converting Evidence into Focus

A. User Needs and Problem Identification

A user need expresses a desired outcome or capability, while problem identification defines the evidence-based obstacle preventing that outcome.

• Need versus solution: “Needs to verify payment confidently” preserves design freedom; “needs a green confirmation button” prematurely specifies a solution.
• Synthesis process: Teams cluster research evidence, identify repeated patterns, examine exceptions, infer needs, and test those inferences against source data.
• Problem statement components: A useful statement identifies the user, need, context, and reason the need matters.
• Point-of-view form:

[User] needs a way to [need] because [research-grounded insight].

• Example: “First-time applicants need a way to confirm that documents were accepted because delayed feedback makes them repeat uploads.”
• Quality criteria: The problem should be human-centred, specific enough to guide ideation, broad enough for alternatives, and supported by multiple observations.

B. Explicit and Implicit User Needs

Explicit needs are directly stated by users, whereas implicit needs are inferred from behaviour, context, contradictions, or workarounds.

1. Explicit needs:

   • Evidence: A participant says, “I need the invoice as a PDF for reimbursement.”
   • Advantage: The requirement is visible and can often be validated directly.
   • Risk: Users may express a familiar solution rather than the underlying outcome.

2. Implicit needs:

   • Evidence: A participant repeatedly photographs confirmation screens despite saying the service is reliable.
   • Inference: The behaviour may indicate a need for proof, traceability, or reassurance.
   • Validation: Researchers should probe the behaviour and compare it across users before treating the inference as established.

• Latent needs: Some needs remain unrecognized until a new possibility appears, such as automatic version recovery eliminating manual backup habits.
• Interpretive discipline: An implicit need must remain traceable to evidence; intuition alone is not a research finding.

C. User Pain Points and Problem Identification

Pain points are recurring sources of difficulty, delay, cost, risk, confusion, or emotional strain within a user journey.

• Common categories:
  • Functional: A control fails or a task cannot be completed.
  • Usability: Labels, navigation, or feedback make completion unnecessarily difficult.
  • Process: Approvals, handoffs, or waiting periods create delay.
  • Financial: Fees or unpredictable costs obstruct the goal.
  • Emotional: Uncertainty, embarrassment, or loss of control damages the experience.
• Evidence capture: Frequency, severity, duration, affected users, and consequences distinguish a minor inconvenience from a critical problem.
• Prioritization: A frequently occurring issue with severe consequences generally deserves more attention than an isolated cosmetic complaint.
• Root-cause analysis: “Users abandon registration” is a symptom; observation may reveal that an unexplained identity request creates distrust.
• Avoiding false framing: Teams should not assume that every complaint requires a feature; the cause may be policy, content, service design, or system performance.

V. User Models and Insight Synthesis — Communicating Research

A. User Personas and Target Archetypes

A user persona is a research-based representation of a significant behavioural pattern, while a target archetype captures the shared goals and constraints of a user group.

• Core elements: A persona includes relevant context, goals, behaviours, motivations, constraints, skill level, and evidence-based frustrations.
• Behavioural segmentation: “Occasional mobile claimant with low process confidence” is more actionable than a demographic category such as “people aged 25–34.”
• Evidence base: Personas should emerge from recurring interview, observation, and usage patterns rather than fictional biography.
• Design use: Teams can evaluate whether a concept supports the persona’s goal, environment, capability, and likely failure conditions.
• Primary and secondary personas: A primary persona guides central design decisions; secondary personas identify additional needs that should be accommodated without compromising the core experience.
• Limitations: Personas become harmful when they stereotype users, include decorative details, hide diversity, or remain unchanged after new research.

B. Empathy Mapping and User Insights

An empathy map organizes research evidence to make a user’s perspective visible and support the development of defensible insights.

• Typical quadrants:
  • Says: Direct quotations, such as “I never know whether the form was submitted.”
  • Thinks: Likely concerns inferred cautiously from converging evidence.
  • Does: Observable actions, such as refreshing the page and checking email.
  • Feels: Emotional states supported by words, tone, expression, or repeated behaviour.
• Additional fields: Some maps include pains, gains, goals, influences, and environmental factors.
• Evidence discipline: Quotations belong under “Says”; interpretations under “Thinks” or “Feels” should be labelled as inferences.
• Insight formation: An insight explains a meaningful tension, cause, or unmet motivation rather than merely repeating an observation.
• Insight pattern: A user may claim speed is most important yet repeatedly verify every detail; the deeper insight is that confidence, not speed alone, governs completion.
• Design value: Strong insights support problem statements, ideation criteria, prototype decisions, and later validation.
• Limitation: An empathy map is a synthesis tool, not raw evidence; it must remain linked to transcripts, field notes, analytics, and observed events.