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

User empathy is the ability to understand users' experiences, emotions, motivations, needs, and difficulties from their perspective. It requires designers to move beyond personal assumptions and examine how users actually think, feel, and behave.

User empathy is essential because it:

• Helps designers discover users' real needs rather than relying on assumptions.
• Reveals emotional, social, and environmental factors affecting user behavior.
• Reduces the risk of creating products that are technically effective but difficult or unpleasant to use.
• Encourages inclusive and accessible design decisions.
• Builds a strong foundation for problem identification, ideation, prototyping, and testing.

For example, observing elderly users operating a mobile banking application may reveal difficulties with small text, complex navigation, or unfamiliar terminology. These insights can guide the design of a simpler and more accessible interface.

User research methods help designers understand users, their context, and their problems. Major methods include:

• Interviews: One-to-one conversations used to understand users' experiences, expectations, motivations, and concerns.
• Observation: Watching users perform activities in their natural environment to identify actual behavior and hidden difficulties.
• Surveys: Structured questionnaires used to collect information from a large number of users.
• Contextual inquiry: Observing users while asking questions about their actions in the actual context of use.
• Focus groups: Moderated discussions with multiple participants to explore shared perceptions and differences.
• Diary studies: Users record activities, thoughts, or emotions over a period of time.
• Usability testing: Users attempt specific tasks while researchers identify interaction problems.
• Analysis of usage data: Logs, analytics, and behavioral metrics reveal patterns in how a product is used.

A strong research process commonly combines multiple methods so that findings from one source can be verified using another.

Computational empathy is the application of empathy-oriented thinking to the design, development, and operation of software systems. It involves understanding users' goals, emotions, limitations, contexts, and likely responses, then translating that understanding into software behavior and engineering decisions.

Its role includes:

• Designing interfaces that respond appropriately to user context and ability.
• Creating meaningful error messages instead of exposing technical details.
• Anticipating frustration caused by delays, failures, or complex workflows.
• Supporting accessibility and diverse user capabilities.
• Using interaction data responsibly to personalize assistance.
• Considering the impact of system decisions on users and other stakeholders.

For example, when a payment fails, an empathetic system clearly explains what happened, confirms that the user was not charged, and provides practical recovery options. Computational empathy does not mean that software genuinely experiences emotion; it means that engineers intentionally design systems around informed models of human needs and consequences.

Computational empathy can be incorporated across the software development life cycle as follows:

• Requirements analysis: Conduct interviews and observations to identify user goals, fears, constraints, and accessibility needs.
• System design: Develop personas, empathy maps, user journeys, and inclusive interaction patterns.
• Implementation: Write understandable messages, provide recovery options, preserve user progress, and implement accessibility standards.
• Testing: Include representative users and test emotional as well as functional outcomes, such as confusion, confidence, and frustration.
• Deployment: Provide transparent onboarding, privacy controls, and support channels.
• Maintenance: Analyze feedback, support requests, abandonment patterns, and recurring errors to improve the product.

For example, a healthcare application may use plain language during requirements and interface design, protect sensitive information during implementation, test with users having different abilities, and monitor whether appointment-booking failures cause abandonment after deployment.

This approach treats empathy as a continuous engineering responsibility rather than a one-time research activity.

Qualitative research investigates the meaning, motivation, and context behind user behavior, whereas quantitative research measures behavior using numerical data.

Qualitative research:

• Answers questions such as why, how, and what does the user experience?
• Common methods include interviews, field observation, focus groups, and diary studies.
• Usually uses smaller, purposefully selected samples.
• Produces themes, narratives, explanations, and contextual insights.
• Is appropriate for discovering unknown needs and exploring complex experiences.

Quantitative research:

• Answers questions such as how many, how often, and to what extent?
• Common methods include surveys, analytics, controlled experiments, and task-performance measurement.
• Usually uses larger samples.
• Produces counts, percentages, averages, correlations, and other measurable results.
• Is appropriate for measuring prevalence, comparing alternatives, or testing hypotheses.

For example, interviews may reveal why users abandon registration, while analytics may show that of users abandon it at the password-creation step. Both methods are complementary.

Mixed-method research combines qualitative and quantitative methods to obtain both contextual understanding and measurable evidence. Quantitative data identifies the size or frequency of a pattern, while qualitative data explains the reasons behind it.

A mixed-method study for an online learning platform could include:

1. Analytics review: Measure course completion, video abandonment, assessment attempts, and navigation paths.
2. Survey: Collect satisfaction ratings and responses from a broad sample of learners.
3. Task observation: Observe selected learners finding a course, completing a lesson, and submitting an assessment.
4. Interviews: Explore why learners skip lessons, abandon assessments, or prefer specific content formats.
5. Triangulation: Compare findings across methods. For example, analytics may show high abandonment on long videos, while interviews may reveal limited internet access and lack of time.
6. Prioritization: Rank problems using prevalence, severity, and impact on learning outcomes.

This combination prevents the team from treating numerical correlation as a complete explanation and strengthens confidence when several forms of evidence support the same finding.

Field observation is a research method in which users are studied while they perform real activities in their natural environment, such as a workplace, home, hospital, or public space.

Researchers should follow these principles:

• Observe actual behavior: Record what users do rather than relying only on what they claim to do.
• Minimize interference: Avoid unnecessarily changing the environment or directing user behavior.
• Capture context: Note physical conditions, social interactions, tools, interruptions, and constraints.
• Separate facts from interpretation: Record observations first and mark interpretations as hypotheses.
• Look for workarounds: Unofficial tools or alternative procedures often indicate unmet needs.
• Ask neutral clarifying questions: Questions should help explain actions without suggesting preferred answers.
• Record systematically: Use field notes, photographs, audio, or video when permission is provided.
• Maintain ethics: Obtain informed consent and protect privacy and confidential information.

Field observation is valuable because users may forget routine actions or may not recognize them as important enough to mention during an interview.

The AEIOU framework is a structured method for recording and interpreting field observations:

• A — Activities: Goal-directed actions and processes performed by users, including their sequence and duration.
• E — Environments: Physical, digital, social, and organizational settings in which activities occur.
• I — Interactions: Exchanges between users, systems, objects, services, and other people.
• O — Objects: Tools, devices, documents, furniture, or other items used during an activity.
• U — Users: The people involved, including their roles, abilities, relationships, emotions, and characteristics.

For example, while studying a hospital reception area, a researcher may document patient registration as an activity, the waiting room as the environment, communication with receptionists as an interaction, forms and token machines as objects, and patients, attendants, and staff as users.

The framework prevents researchers from focusing only on the primary user. It organizes complex observations into consistent categories, supports comparison across locations, and helps reveal relationships among behavior, context, people, and tools.

The AEIOU framework can guide an investigation of supermarket self-service checkout as follows:

• Activities: Scanning products, searching for product codes, weighing produce, applying discounts, selecting payment methods, packing items, and requesting assistance.
• Environments: Checkout layout, lighting, noise, queue length, available space, screen visibility, and location of staff.
• Interactions: Customer-screen interaction, customer-scanner interaction, payment-terminal use, staff assistance, and communication among customers waiting in line.
• Objects: Products, barcodes, bags, scales, scanners, receipts, loyalty cards, payment cards, and shopping carts.
• Users: First-time customers, experienced customers, elderly users, users with disabilities, parents with children, tourists, and support staff.

The researcher should note repeated scanning failures, unclear prompts, inaccessible controls, unexpected-item alerts, and user workarounds. These observations can produce insights such as the need for clearer instructions, larger touch targets, improved product search, better bagging-area detection, or more visible assistance. Findings should be validated through short interviews and system data before defining the final problem.

An effective user interview includes the following stages:

1. Define the research objective: Specify what the team needs to learn and how the findings will influence decisions.
2. Select participants: Recruit users who represent relevant behaviors, contexts, and experience levels.
3. Prepare an interview guide: Arrange open-ended questions from general topics to specific experiences.
4. Obtain informed consent: Explain the purpose, recording process, data use, confidentiality, and right to withdraw.
5. Build rapport: Begin with simple background questions and create a respectful, nonjudgmental environment.
6. Explore real experiences: Ask participants to describe recent events, decisions, actions, and feelings.
7. Probe carefully: Use follow-up questions such as What happened next? and Why was that difficult?
8. Summarize and confirm: Restate important points and allow participants to correct interpretations.
9. Document the session: Record notes and media only with permission.
10. Analyze findings: Code responses, group recurring themes, identify needs, and compare insights across participants.

The interviewer should remain neutral and avoid treating a participant's proposed solution as direct proof of the underlying need.

The main interview question types differ in purpose and the type of response they encourage:

• Open-ended question: Encourages a detailed response. Example: Tell me about the last time you booked a medical appointment.
• Closed-ended question: Requests a short, fixed, or factual response. Example: Did you complete the booking successfully?
• Probing question: Follows an earlier answer to obtain greater depth. Example: What made that step confusing?
• Leading question: Suggests an expected answer and may introduce bias. Example: Wouldn't a larger button make this page easier to use? This type should generally be avoided.
• Hypothetical question: Asks users to predict behavior in an imagined situation. Example: Would you use an automatic appointment scheduler? Such answers should be treated cautiously because predicted behavior may differ from actual behavior.

Open-ended and probing questions are especially valuable for empathy research because they reveal context and motivation. Closed-ended questions can confirm facts, while leading and hypothetical questions require careful handling to avoid unreliable conclusions.

Contextual inquiry is a research method in which the researcher observes a user performing real tasks in the actual context of use and asks questions to understand decisions, tools, constraints, and workarounds.

Contextual inquiry:

• Occurs in the user's natural environment.
• Focuses on current actions and real artifacts.
• Combines observation with timely clarification.
• Reveals tacit knowledge, interruptions, and environmental constraints.
• May require more time, access, consent, and privacy safeguards.

Conventional interview:

• Often occurs away from the activity being discussed.
• Depends largely on memory and self-reporting.
• Can efficiently explore attitudes, expectations, and past experiences.
• Is easier to schedule and conduct remotely.
• May miss habitual actions that users do not remember or consider important.

For example, an office worker may say that expense reporting is simple during an interview, but contextual inquiry may reveal repeated spreadsheet checks, searches for paper receipts, and assistance from colleagues. The two methods are complementary rather than interchangeable.

A user need is a requirement, goal, motivation, or desired outcome that enables a user to make progress in a particular context. A need should describe what the user is trying to achieve without prematurely prescribing a specific solution.

Raw observations can be transformed into need statements through these steps:

1. Record concrete evidence from interviews, observations, and artifacts.
2. Identify repeated behaviors, emotions, barriers, and workarounds.
3. Infer the underlying goal behind each behavior.
4. Group related evidence into themes.
5. Express the need in a user-centered form, such as The user needs a way to... because...
6. Remove embedded solutions and broad assumptions.
7. Validate the statement with additional users or data.

For example, the observation Commuters repeatedly check several screens for delay information should not immediately become Build a new dashboard. A stronger need statement is: Commuters need a reliable way to understand service disruptions quickly because conflicting updates make travel decisions difficult.

Explicit needs are needs that users can recognize and directly communicate. Implicit needs are unspoken, unrecognized, habitual, emotional, or contextual needs inferred from behavior and evidence.

Explicit needs:

• Are stated through interviews, surveys, requests, or complaints.
• Are relatively easy to document.
• Example: I need a search option to find previous invoices.

Implicit needs:

• May not be consciously recognized or clearly expressed by users.
• Are discovered through observation, probing, behavioral data, workarounds, and inconsistencies between words and actions.
• Example: A user repeatedly asks a colleague to verify an invoice before submission, indicating an implicit need for confidence, validation, or error prevention.

Designers identify explicit needs by listening and asking clear follow-up questions. They identify implicit needs by observing users in context, examining artifacts, noticing emotional reactions, and asking why a workaround exists. Both types must be validated because spoken requests can reflect preferred solutions, while inferred needs can be affected by researcher bias.

User pain points are recurring difficulties, frustrations, risks, delays, or obstacles that prevent users from achieving their goals effectively and satisfactorily.

Common categories include:

• Functional pain points: A feature or process does not work as required.
• Usability pain points: The interaction is confusing, inconsistent, or difficult to learn.
• Process pain points: A task involves too many steps, approvals, or handoffs.
• Financial pain points: Costs, fees, or pricing structures create difficulty.
• Emotional pain points: Users experience anxiety, uncertainty, embarrassment, or lack of trust.
• Accessibility pain points: Users face barriers related to vision, hearing, movement, cognition, language, or technology access.
• Support pain points: Help is unavailable, slow, or unable to resolve the issue.

Pain points support problem identification by locating where user goals are blocked. Researchers should document the context, frequency, severity, affected users, and consequences of each pain point. A pain point becomes a meaningful design problem only when it is supported by evidence and connected to an important user need.

A systematic problem-identification and prioritization method can include:

1. Consolidate evidence: Gather interview notes, observations, survey results, analytics, complaints, and usability findings.
2. Code the data: Label recurring goals, behaviors, barriers, emotions, and contexts.
3. Cluster themes: Use affinity grouping to combine related evidence.
4. Form insight statements: Explain what is happening, why it matters, and what evidence supports the interpretation.
5. Write problem statements: Define the user, need, context, and consequence without embedding a preferred solution.
6. Validate: Check the problem across multiple participants and research methods.
7. Prioritize: Rate each problem using factors such as frequency, severity, reach, strategic relevance, and confidence in the evidence.
8. Address ethical and accessibility impact: Give appropriate priority to problems causing exclusion, harm, or serious risk.

A simple priority model may be expressed as:

where is frequency, is severity, is impact, and is confidence in the evidence. The numerical score supports comparison but should not replace professional judgment, especially in safety-critical situations.

A user persona is a research-based representation of a significant user group that shares similar goals, behaviors, needs, and contexts. It is an analytical design tool rather than a fictional biography created from assumptions.

Essential components include:

• A clear name or identifier.
• Relevant background and context.
• Goals and desired outcomes.
• Behaviors and usage patterns.
• Skills, experience, and technology familiarity.
• Needs, motivations, and expectations.
• Pain points and constraints.
• Accessibility or environmental considerations.
• Evidence-based quotations or behavioral summaries.

Personas support design by helping teams evaluate decisions from a consistent user perspective, compare the needs of different groups, prioritize features, create realistic scenarios, and avoid designing only for team members' preferences.

A useful persona must be based on patterns found in research. Excessive personal details, stereotypes, unsupported demographic assumptions, and decorative biographies weaken its value.

A target archetype is a generalized pattern representing users who share important behaviors, motivations, goals, and attitudes relevant to a design problem.

It differs from related concepts in the following ways:

• Target archetype: Focuses on recurring behavioral and motivational patterns, such as a cautious first-time investor who seeks reassurance before making decisions.
• Demographic segment: Groups people using attributes such as age, income, occupation, or location. Members may share demographic characteristics but behave very differently.
• Individual user: Represents one real person with unique circumstances and cannot alone represent an entire user population.

Target archetypes help teams reason about behavior without depending only on broad demographic labels. For example, users aged 18–25 is a demographic segment, whereas mobile-first learners who study in short intervals and frequently lose connectivity is a behaviorally meaningful archetype.

Archetypes should be supported by research, acknowledge variation within groups, and be revised when new evidence contradicts earlier patterns.

An empathy map is a collaborative visualization that organizes research findings about a user's experience. It helps a team develop a shared understanding of user behavior, thoughts, emotions, and context.

Its major sections commonly include:

• Says: Direct statements and quotations from the user.
• Thinks: Beliefs, concerns, expectations, or internal questions inferred from evidence.
• Does: Observable actions, habits, decisions, and workarounds.
• Feels: Emotions such as confidence, anxiety, frustration, or satisfaction.
• Pains: Obstacles, risks, fears, and negative outcomes.
• Gains: Desired results, benefits, and indicators of success.

Some versions also include what the user sees and hears in the surrounding environment.

An empathy map distinguishes direct evidence from interpretation and exposes contradictions. For example, a user may say that a process is easy while repeatedly seeking help. Such contradictions generate research questions and possible insights, but they should be validated before being treated as facts.

A team can move from an empathy map to a problem statement through the following process:

1. Populate the map with evidence: Add user quotations to Says, observed behavior to Does, and evidence-supported interpretations to Thinks and Feels.
2. Identify patterns: Look for repeated behaviors, emotions, goals, pains, gains, and contradictions.
3. Ask interpretive questions: Examine why a pattern occurs and what underlying need may explain it.
4. Create insight statements: Connect an observation with its meaning. For example, Users repeatedly save screenshots of confirmation pages because they do not trust that records will remain available.
5. Define the need: State the desired outcome without specifying a feature.
6. Write a problem statement: Include the user, need, context, and reason the need matters.
7. Validate the interpretation: Compare it with additional interviews, observations, or quantitative evidence.

A suitable problem statement would be: Occasional service users need a dependable way to retrieve proof of completed transactions because uncertainty about record availability causes anxiety and repeated manual backups.

This process converts scattered observations into an actionable, evidence-based design focus while avoiding premature solution selection.