Unit 2: Empathy, Observation and Problem Identification - Subjective Questions

User empathy is the ability to understand a user's experiences, emotions, motivations, needs, and difficulties from the user's point of view.

It is essential because it:

• Helps designers avoid making decisions based only on personal assumptions.
• Reveals the context in which users interact with a product or service.
• Identifies emotional, functional, and social needs.
• Supports the creation of relevant and accessible solutions.
• Builds a shared understanding of users within the design team.

Empathy requires active engagement with users through observation, interviews, contextual inquiry, and other research methods. A solution developed with empathy addresses the user's actual problem rather than merely implementing a technically impressive feature.

Major user research methods include:

• User interviews: Direct conversations used to understand experiences, goals, motivations, and difficulties.
• Observation: Watching users perform activities in a natural or controlled environment.
• Contextual inquiry: Observing users in context while asking questions about their actions and decisions.
• Surveys and questionnaires: Collecting structured responses from a relatively large group.
• Focus groups: Facilitated discussions that reveal attitudes, expectations, and group perceptions.
• Diary studies: Asking participants to record experiences over a period of time.
• Usability testing: Evaluating how effectively users complete tasks with a product or prototype.
• Analytics review: Studying behavioral data such as task completion, errors, retention, and navigation paths.

Researchers usually combine several methods to obtain both behavioral evidence and explanations of user behavior.

Computational empathy is the systematic use of user data, models, and computing techniques to recognize, interpret, or respond to users' states, needs, intentions, and difficulties.

In software engineering, it may involve:

• Analyzing interaction logs to detect repeated errors or abandonment.
• Using accessibility information to adapt an interface.
• Applying sentiment analysis to support messages or feedback.
• Personalizing workflows based on user context and behavior.
• Detecting frustration through repeated actions, long delays, or failed attempts.

Computational empathy can influence development by helping teams prioritize user-centered requirements, improve error handling, personalize assistance, and identify usability problems at scale. However, inferred emotions are not always accurate. Such systems should therefore use transparent data practices, obtain meaningful consent, minimize data collection, avoid manipulative personalization, and allow users to correct or reject inferences.

Qualitative research explores why users behave in a particular way and how they interpret their experiences.

• Produces descriptive, non-numerical data.
• Common methods include interviews, field observation, contextual inquiry, and diary studies.
• Usually uses smaller, purposefully selected samples.
• Helps discover needs, motivations, perceptions, and unexpected issues.

Quantitative research measures what happens, how often it happens, or how strongly variables are related.

• Produces numerical data.
• Common methods include surveys, experiments, analytics, and task-performance measurements.
• Usually uses larger samples.
• Helps estimate frequency, compare alternatives, and test hypotheses.

For example, interviews may reveal why users abandon registration, while analytics may show what percentage abandon it and at which step. Qualitative research is especially useful during exploration, whereas quantitative research is useful for measurement and validation. A mixed-method approach combines depth with measurable evidence.

Field observation is the systematic study of users while they perform activities in their natural environment, such as a workplace, home, shop, hospital, or public space.

A typical procedure is:

1. Define the research objective and select relevant participants and locations.
2. Obtain consent and decide what information may be recorded.
3. Observe users, tasks, interactions, tools, and environmental conditions.
4. Record notes, quotations, events, photographs, or video where permitted.
5. Separate observed facts from the researcher's interpretations.
6. Organize evidence into patterns, needs, and insights.

Benefits:

• Reveals actual behavior rather than only reported behavior.
• Exposes environmental constraints, interruptions, and workarounds.
• Identifies needs users may not be able to describe.

Limitations:

• Can require substantial time and access.
• Participants may change behavior when observed.
• Interpretation can be affected by researcher bias.
• Privacy and confidentiality require careful management.

The AEIOU framework organizes field observations into five categories:

• Activities: Goal-directed actions and processes performed by users.
• Environments: Physical, digital, social, and organizational settings in which activities occur.
• Interactions: Exchanges between people, products, systems, and services.
• Objects: Tools, devices, documents, and other items used during an activity.
• Users: People involved, including their roles, abilities, relationships, and characteristics.

For example, when studying a hospital reception area:

• Activities: Registration, appointment verification, payment, and queue management.
• Environments: A noisy reception area with limited seating and privacy.
• Interactions: Patients speaking with receptionists or using a self-service kiosk.
• Objects: Identity cards, forms, token displays, computers, and payment terminals.
• Users: Patients, caregivers, receptionists, and medical staff.

The framework prevents observers from focusing only on the primary user and helps them examine the complete context in which a problem occurs.

An effective user interview involves three stages.

Before the interview:

• Define clear research objectives.
• Recruit participants who represent relevant user groups.
• Prepare an interview guide with open-ended questions.
• Arrange a suitable setting and obtain informed consent.

During the interview:

• Begin with simple background questions to establish context.
• Ask about actual past experiences instead of hypothetical preferences.
• Use neutral language and avoid leading questions.
• Probe important responses with questions such as why, how, and what happened next.
• Listen actively and allow pauses.
• Record notes or audio only with permission.

After the interview:

• Summarize observations promptly.
• Transcribe or organize significant statements.
• Code responses into themes and compare participants.
• Separate direct evidence from interpretation.

A good interview is a guided conversation rather than a rigid questionnaire or a sales discussion.

Inquiry and probing techniques help a researcher obtain detailed, reliable accounts of user experience.

• Open-ended inquiry: Encourages explanation. Example: "How do you currently manage appointments?"
• Experience-based probing: Requests a real incident. Example: "Tell me about the last time you missed an appointment."
• Clarification probe: Resolves vague language. Example: "What do you mean when you say the process was difficult?"
• Elaboration probe: Asks for more detail. Example: "What happened after the application displayed that message?"
• Laddering: Moves from a feature or action toward the underlying value by repeatedly asking why it matters.
• Critical-incident inquiry: Examines an especially successful or unsuccessful event.
• Silent probing: Uses a deliberate pause to give the participant time to continue.

These techniques should be used neutrally. Researchers should not suggest an expected answer, interrupt unnecessarily, or treat every statement as factual without seeking a concrete example.

Common interview mistakes include:

• Leading questions: They suggest the preferred answer. Replace them with neutral questions.
• Closed questions used too early: They restrict discovery. Begin with open-ended questions and use closed questions only for confirmation.
• Asking several questions at once: Participants may answer only one part. Ask one clear question at a time.
• Relying on hypothetical behavior: Users may inaccurately predict future actions. Ask about recent, real experiences.
• Interrupting or filling every silence: This prevents reflection. Allow the participant time to think.
• Defending the product: The interview should investigate the user's perspective, not persuade the participant.
• Ignoring nonverbal signals: Note hesitation, confusion, and environmental context without making unsupported assumptions.
• Recording interpretations as facts: Keep direct observations and quotations separate from conclusions.

A consistent interview guide, interviewer training, pilot interviews, and post-interview review can reduce these errors.

Raw research data can be converted into a problem definition through the following process:

1. Collect evidence: Gather interview statements, observations, task data, and relevant documents.
2. Organize the data: Label and group notes using coding or affinity mapping.
3. Identify patterns: Look for repeated goals, barriers, workarounds, emotions, and contradictions.
4. Interpret patterns: Ask what users are trying to achieve and why the observed issue matters.
5. Express needs: Write needs as outcomes rather than predetermined features. For example, use "needs a reliable way to know whether payment succeeded" instead of "needs a larger confirmation button."
6. Prioritize: Consider severity, frequency, strategic relevance, and the consequences of leaving the need unmet.
7. Frame the problem: State the user, need, context, and insight without prescribing a solution.
8. Validate: Return to users or additional evidence to test the interpretation.

This process creates traceability from a proposed design problem back to observable research evidence.

Explicit needs are needs that users can recognize and communicate directly. For example, a user may say that they need larger text or a faster search function.

They can be identified through:

• Direct interview questions.
• Surveys and feedback forms.
• Support requests and feature requests.
• Complaints and stated preferences.

Implicit needs are unspoken, unnoticed, socially sensitive, or difficult-to-express needs. For example, a user repeatedly writing passwords on paper may indicate a need for secure but easier authentication.

They can be identified through:

• Field observation and contextual inquiry.
• Analysis of workarounds and repeated errors.
• Comparison between what users say and what they do.
• Attention to emotional reactions, environmental constraints, and task sequences.

Explicit requests should not automatically be treated as final solutions. Designers must investigate the underlying goal, while implicit needs should be supported by multiple observations before being accepted as valid insights.

A user pain point is a recurring difficulty, risk, inefficiency, frustration, or unmet need experienced while a user tries to achieve a goal.

Major categories include:

• Functional pain points: A product does not support a required task. Example: a banking application cannot schedule recurring transfers.
• Usability pain points: The task is possible but confusing or error-prone. Example: unclear navigation causes users to miss payment settings.
• Process pain points: A workflow requires unnecessary steps, repetition, or waiting. Example: entering the same information into several forms.
• Financial pain points: Costs are high, hidden, or unpredictable. Example: unexpected service charges appear at checkout.
• Emotional pain points: Users feel anxious, embarrassed, excluded, or uncertain. Example: an unclear medical result screen creates avoidable fear.
• Support pain points: Users cannot obtain timely help. Example: an automated support system repeatedly blocks access to a human agent.

A pain point should be documented with evidence, context, affected users, frequency, severity, and impact.

A systematic method includes:

1. Document each pain point: State the task, context, obstacle, and user consequence.
2. Attach evidence: Include quotations, observation notes, analytics, or task-performance results.
3. Combine duplicates: Use affinity mapping to group related problems under common themes.
4. Estimate frequency: Determine how often the problem occurs and how many users are affected.
5. Assess severity: Consider task failure, wasted time, financial loss, safety risk, and emotional impact.
6. Examine reach and strategic relevance: Determine whether the issue affects a critical user group or business objective.
7. Check confidence: Rate the strength and diversity of supporting evidence.
8. Prioritize and validate: Rank the issues, investigate uncertain high-impact findings, and review priorities with stakeholders and users.

A team may use a score such as:

where is frequency, is severity, is reach or relevance, and is confidence. The score supports discussion but should not replace ethical judgment, particularly for accessibility and safety issues.

A user persona is a research-based representation of a significant user group that shares similar goals, behaviors, needs, and constraints. It helps a design team reason consistently about whom it is designing for.

An evidence-based persona commonly includes:

• A concise name or identifier.
• Relevant background and context.
• Primary goals and desired outcomes.
• Behaviors, habits, and current workflows.
• Motivations and decision factors.
• Skills, knowledge, and technology usage.
• Constraints, accessibility requirements, and environmental conditions.
• Pain points and common workarounds.
• A scenario showing when and why the user engages with the product.
• Supporting evidence or a reference to the research segment.

Demographic details should be included only when they influence behavior or design requirements. A persona is not a fictional character created from stereotypes; it must be grounded in patterns found across real participants.

The process of creating personas includes:

1. Collect diverse user data: Use interviews, observation, surveys, analytics, and support records.
2. Code relevant variables: Identify goals, behaviors, contexts, motivations, skills, and barriers.
3. Find behavioral patterns: Group participants according to meaningful similarities rather than superficial demographics.
4. Define persona groups: Select groups that represent important and distinct design needs.
5. Construct each persona: Summarize goals, behaviors, constraints, pain points, and a realistic usage scenario.
6. Connect claims to evidence: Maintain references to research notes or participant clusters.
7. Review for bias: Remove stereotypes, irrelevant personal details, and unsupported assumptions.
8. Validate: Compare personas with additional participants, quantitative segments, frontline staff, and actual product behavior.
9. Update over time: Revise or retire personas when users, markets, or evidence change.

Validation is important because an attractive persona document can still be inaccurate. A useful persona should predict meaningful differences in user behavior and support concrete design decisions.

A user persona is a detailed, research-based representation of a user segment. It typically includes goals, behaviors, motivations, context, constraints, and pain points.

A target archetype is a broader behavioral model that captures a recurring role, attitude, or interaction pattern. It is generally less biographical and more focused on the qualities that influence product use.

Key differences are:

• Personas are usually richer and more contextual; archetypes are more abstract.
• Personas may describe a realistic representative individual; archetypes describe a recurring behavioral pattern.
• Personas support scenario design and detailed requirement discussions; archetypes help compare broad usage modes across products or contexts.

For example, a persona might describe a specific type of first-year student with limited digital confidence. The related archetype might be the guided learner, who values reassurance and step-by-step support. Both tools must come from research and should guide priorities without excluding users who do not fit neatly into a category.

An empathy map is a collaborative visual tool used to organize research findings about a user and build a shared understanding of the user's experience.

Its common sections are:

• Says: Direct statements and quotations from the user.
• Thinks: Beliefs, concerns, expectations, or thoughts inferred from evidence.
• Does: Observable actions, habits, and workarounds.
• Feels: Emotions indicated by words, tone, behavior, or context.
• Pains: Barriers, fears, risks, frustrations, and negative outcomes.
• Gains: Goals, desired outcomes, benefits, and measures of success.

The map helps teams compare stated opinions with actual behavior, identify contradictions, and generate research questions. Entries in Says and Does should be based directly on evidence. Entries in Thinks and Feels are interpretations and should therefore be marked as assumptions when supporting evidence is weak.

An empathy map becomes actionable through structured interpretation:

1. Populate it with evidence: Add quotations, observed actions, emotions, barriers, and goals from research.
2. Identify tensions: Compare what users say with what they do, think, or appear to feel.
3. Cluster related entries: Group repeated observations into themes.
4. Find causes and consequences: Determine why a behavior occurs and what outcome it creates.
5. Write an insight: Express a non-obvious explanation that connects evidence to an underlying need.
6. Validate the insight: Check it against other participants, methods, or data sources.
7. Frame an opportunity: Convert the insight into a neutral design challenge, often using a How might we question.
8. Define success: Specify the user outcome that would indicate improvement.

For example, users may say that they want more options but repeatedly abandon a screen containing many choices. The insight may be that users value control but experience decision overload. An opportunity could be: How might we preserve control while making the first decision easier?

A strong user insight is an evidence-supported interpretation that explains an important and often non-obvious reason behind user behavior.

The concepts differ as follows:

• Observation: A factual record of what happened. Example: users keep handwritten copies of transaction numbers.
• Need: An outcome the user requires. Example: users need confidence that a transaction can be traced.
• Insight: An explanation of why the behavior and need matter. Example: users preserve manual evidence because the digital system does not provide a trustworthy sense of completion.
• Solution: A specific response. Example: provide a downloadable receipt and transaction history.

A strong insight is:

• Grounded in multiple pieces of evidence.
• Relevant to an important user goal.
• Specific enough to guide design.
• Open enough to allow several possible solutions.
• Capable of changing the team's understanding of the problem.
• Clear about whether any part remains an assumption.

An insight should explain meaning, not merely repeat a quotation or disguise a feature request.

An integrated approach should combine qualitative and quantitative methods.

Research objectives:

• Understand journey planning, ticketing, disruption management, accessibility, and safety needs.
• Identify differences between routine commuters, occasional travelers, tourists, older adults, and users with disabilities.

Methods:

• Conduct field observation at stations, stops, and interchange points using the AEIOU framework.
• Use contextual interviews during real journeys.
• Interview transport staff and caregivers where relevant.
• Run a survey to measure the frequency and severity of discovered issues.
• Analyze existing journey-planner usage, search failures, and support requests.
• Test representative tasks with current services or early prototypes.

Sampling:

Use purposive sampling to include different travel frequencies, locations, accessibility needs, languages, and levels of digital confidence. Add quantitative sampling large enough to compare important groups.

Analysis:

• Code interviews and observations.
• Build affinity clusters and empathy maps.
• Compare qualitative themes with survey and analytics data.
• Prioritize pain points by frequency, severity, reach, and confidence.

Ethics:

Obtain informed consent, avoid recording bystanders without permission, minimize location data, protect travel histories, anonymize findings, and provide accessible participation options.

Expected outputs:

The study should produce validated needs, prioritized pain points, personas or archetypes, empathy maps, user insights, journey scenarios, and evidence-based problem statements suitable for ideation.