Module 4: Discovery Methods

Exploring Real Needs

Learning objective: At the end of this module, you will be able to execute formative research methods (such as ethnographic interviews and desk research) and develop Personas and Scenarios based on real research data.

Estimated time: 2 hours

---

Module 4 focuses on the generative and exploratory research phase, whose objective is to deeply understand problems, context, and real user needs before proposing solutions.

In the 4-phase cycle you saw in Module 3, here you cover Discover (understanding the unknown: interviews, observation) and Explore (mapping the experience and modeling users: personas, journey maps, information architecture). This is the problem space.

---

4.1. Secondary Research (Desk Research)

Secondary research is the collection and synthesis of existing data gathered by others. It's the recommended first step before any primary user research.

Objectives and Value

Desk Research helps to:

• Gain a broad understanding of the product domain
• Identify what has been researched and what remains to be explored
• Find opportunity gaps
• Avoid "reinventing the wheel"

Information Sources

Internal Sources:

• Previous company research
• Customer and satisfaction data
• Transactional and support data
• Existing web analytics

External Sources:

• Academic studies and scientific publications
• Consulting reports (McKinsey, Forrester, Nielsen)
• Industry organization documentation
• Market trend analysis

Search Logs and Analytics Analysis

Pre-existing quantitative data is valuable because it's based on a high volume of real users.

Search Analytics allows:

• Identifying terms users actually search for
• Diagnosing navigation and content problems
• Developing vocabularies that match user language

Important limitation: Analytics data tells what users do, but doesn't say why. Qualitative research is required to understand causes.

---

4.2. Ethnographic and Contextual Interviews

Qualitative research is exploratory and used to understand the underlying reasons, opinions, and motivations of users.

The Value of Ethnography

Ethnography is a set of qualitative methods aimed at understanding the activities and mindsets of a group by observing their ordinary activities in their usual environment.

Contextual Inquiry is a specific technique where the researcher:

• Spends time where the activity happens
• Observes the user in their real context
• Asks questions while the user performs their tasks

The Master-Apprentice Model

Contextual research is based on:

• The user is the master who performs the activity
• The researcher is the apprentice who observes and asks

This reduces the risk of making wrong assumptions and reveals behaviors the user has forgotten to mention.

From the Research Question to the Guide

Module 3 ended with a promise: that your hypotheses were the bridge between the research question and the interview questions. This is where you cross it.

It's the step almost nobody teaches. There's plenty of material on what makes a question good — open, concrete, not leading — and very little on how you arrive at one. Phillips and Holland (2026) published a seven-step process for building interview guides in academic qualitative research. What follows is that process brought into the constraints of a UX project: less time, fewer participants, and a team waiting on decisions.

Step 1. Break the question into three topics.

Write your research question at the top of a blank document and underline its components. Aim for three topics, no more. Three is enough to have a conversation and few enough not to drown in the analysis.

For the corner store, "why do people come to the site, look, and not buy?" opens into: how they shop today (the habit, with or without the store), what they expect from delivery (the Module 3 hypothesis), and what makes them hesitate at the moment of paying.

This step is also a free diagnostic of your question:

• If all three topics can be answered by a single question, your research question is too narrow.
• If you end up with eight topics, it's too broad and won't fit in one interview. Cut it now, not later.

Step 2. Generate many questions, unfiltered.

Under each topic, write every question that comes to mind. Don't fix the wording, don't worry about repetition: that comes next. The goal is to cover the topic from every angle before pruning.

It helps to vary the type of information you ask for, because each type opens a different door:

• Definition: "what does a delivery arriving properly mean to you?"
• Narration: "tell me about the last time you bought something in the neighborhood."
• Description: "what does a day when you buy food look like?"
• Contrast: "how is a purchase that went well different from one that went badly?"
• Thoughts and feelings: "what goes through your head when you see they only take bank transfers?"

A practical trick: go back to the reports, support tickets, and reviews you gathered in desk research (4.1). The vocabulary people use there hands you questions already written.

Watch for the one-sided bias. If all your questions explore what works, you'll come out with data confirming what you already believed. For every question about what the user likes, add its counterpart: "what has been difficult?", "what made you give up?".

Step 3. Rephrase and consolidate.

Now, one topic at a time:

Before looking at the wording, run each question through these two:

Does it add information? Imagine the participant has already answered. Does that answer help you understand your problem better? If you hesitate, the question needs changing.

Is it fishing for a confirmation? The simplest example is ice cream. "Do you like ice cream?" is a bad question, because it already stakes out a position: you like it. "You don't like ice cream?" stakes out the opposite and is just as bad. Better: "do you eat ice cream?", which asks about the behavior and not about the opinion you were already carrying.

Then, on the ones that survived:

• Remove closed questions (the ones answered yes or no) and leading ones (the ones carrying the answer inside).
• Swap your team's jargon for the participant's words: "checkout" is "when you go to pay."
• One question per question. "How do you order and how long do you wait?" is two.
• Merge the ones asking the same thing in different words.

Step 4. Add prompts.

This is the part most often skipped, and the one that returns the most depth per minute invested. A prompt is what you say after the participant answers and goes quiet.

General prompts, useful at any moment and worth knowing by heart:

• "Tell me more about that."
• "What was that like?"
• "Can you give me an example?"
• "What happened next?"
• And the most underrated one: silence. Count to three before speaking. The second thing people say is usually the interesting one.

Specific prompts, written under the question they belong to and visually distinct (indented, italic), so you don't mistake them for new questions during the session. Under "tell me about the last time you ordered something online that didn't arrive when you expected": how did you find out? what did you do? did you buy there again?

Prompts are a support, not a script. If the participant already covered it, don't use them.

Step 5. Filter.

Go back over everything and cut without guilt: the repeated, whatever no longer answers the research question, and whatever you're asking out of your own curiosity. Curiosity is legitimate but the participant's time is finite.

Step 6. Order the guide.

A guide isn't a list, it's a route:

• Easy opening. One broad, low-risk question the participant can answer without thinking. It lets you calibrate how they talk and lets them warm up.
• Sensible flow. From general to specific, from comfortable to sensitive. Anything touching money, mistakes, or frustration goes in the middle or at the end, never at the start.
• Open close. "Is there anything I didn't ask that you think I should know?" It is, consistently, one of the most productive questions in the whole interview.

Step 7. Test it before you use it.

Nobody debuts a guide on a real participant. It costs half an hour and saves you a wasted interview.

• On yourself: read it out loud, all of it. Questions that sound odd spoken sound odd in the session too, and there you'll find out too late. Time it.
• With someone else: a pilot interview with a colleague or an acquaintance close to the profile. You're not collecting data, you're spotting which question is misunderstood, which gets a one-word answer, and how much time you have to spare or lack.

After the pilot you'll almost always go back to step 3. That isn't a sign you did it wrong: the process is circular, and it's designed that way.

How many questions?

Phillips and Holland suggest 10 to 12 with their prompts, for a one-hour academic interview devoted only to talking. In a 45 to 60 minute UX session that also includes consent, rapport, and "show and tell," the time allows for considerably fewer: 6 to 8 core questions, with their prompts written in, opening and closing included.

The number is a reference, not a rule. Half a dozen questions with room for the person to expand is worth more than fifteen that force you to rush them. If you have to choose, choose depth.

Step by Step: Conducting an Ethnographic Interview

Before the interview:

1. Define the interview objective (aligned with RQ)
2. Build the guide following the seven steps in the previous section
3. Prepare informed consent
4. Check recording equipment

During the interview:

1. Establish rapport: Present the purpose, ensure confidentiality, build trust.
2. Prioritize goals over tasks: Ask first about why (motivations) and then what (actions).
3. Use open questions:
   • ✅ "Tell me about the last time you..."
   • ✅ "What happened next?"
   • ❌ "Did you like the experience?" (closed)
   • ❌ "Don't you think it would be better if...?" (leading)
4. Encourage narratives: Ask for stories of specific incidents, not abstract opinions.
5. "Show and tell": Ask the user to show you how they do things. The gap between what they say and what they do is a design opportunity.
6. Record verbatim phrases: The user's exact vocabulary is valuable for design.

After the interview:

1. Transcribe or take detailed notes immediately
2. Identify emerging patterns
3. Compare with other interviews

Participant Recruitment

It's fundamental that participants are representative of the target user.

The Screener is a filter questionnaire with questions that determine if a person meets the criteria to participate.

Example screener criteria:

• Specific age range
• Frequency of product/service use
• Work role or responsibilities
• Previous experience with similar technology

---

4.3. Contextual Inquiry: Observing Reality

"You can observe a lot by just watching." (Yogi Berra)

Sometimes interviews fall short. People want to tell the truth, but our memory is fallible and we tend to rationalize what we do. This is where Contextual Inquiry comes in.

It's like being a documentary filmmaker of your user's life. You don't just ask, you're there.

The 4 Principles of Contextual Inquiry

Beyer and Holtzblatt defined four key principles that set this apart from a coffee chat (Smashing Magazine):

1. CONTEXT: Go to the place where the action happens.
   • Why: If you're researching accounting software, go to the accountant's office. You'll see the sticky notes with passwords on the monitor, the ambient noise, the constant interruptions. They won't tell you that over Zoom.
2. PARTNERSHIP: Adopt the Master-Apprentice model.
   • Why: You're the curious apprentice; they're the expert in their work. "Show me how you do that monthly report." This breaks the interrogation dynamic and empowers them.
3. INTERPRETATION: Validate your observations in real time.
   • Why: If you see the user frown, ask: "I saw you make a face when you exported the file, did something happen?" Don't assume you know why they did it.
4. FOCUS: Don't lose your way.
   • Why: It's easy to get distracted by office gossip. Keep the conversation gently guided toward topics relevant to your project, without being rigid.

Anecdote: "The mystery of the ignored button"

A while ago, I was working on a warehouse management system. In interviews, the warehouse workers swore the system was "slow but it worked."

I went to the warehouse (with a hard hat and reflective vest :construction_worker:). I watched a user, Don Manuel. Every time he had to enter an order, he pulled out a paper notebook, wrote down codes, and then, at the end of the shift, transferred them to the computer.

"Don Manuel, why do you write them down first?"

"Ah, it's because the system closes if I don't move the mouse for 5 minutes, and I lose everything. Better to lock it in on paper."

Bingo! The problem wasn't the entry interface, it was the session timeout. In a meeting-room interview, Don Manuel would never have mentioned the notebook; to him it was obvious.

Contextual Inquiry vs. Traditional Interview

Aspect	Traditional Interview (Lab/Remote)	Contextual Inquiry (In Situ)
Location	Artificial (Room, Zoom)	Natural (Where the action happens)
Focus	What the user says	What the user does (and says)
Recall	The user must remember details	The user shows you the details
Surprises	Limited to the narrative	High (you see real workarounds)

Tips for Contextual Inquiry in Latam 🌎

Doing this in our region has its tricks:

• Shared spaces: In many Latin American offices, space is open and noisy. Be respectful and try not to interrupt the work of the coworkers next to you.
• "Tea/coffee time": Accept that invitation. In informal moments the best cultural insights come out about hierarchy and how information flows.
• Real homes: If you visit homes, remember not everyone has a Pinterest "home office desk." Many people work from the dining table with the TV on. That IS their real context. Design for that.

---

4.4. Creating Personas and User Models

Once qualitative data is collected, it needs to be synthesized into useful models for the team.

What is a Persona?

A Persona is a fictional user archetype created from qualitative data collected by talking to real people.

Purpose of Personas:

• Represent the user in the design process
• Generate empathy in the team
• Frame design decisions based on real needs
• Avoid designing for "the average user" (which doesn't exist)

Important: Personas were introduced by Alan Cooper in 1999 in his book "The Inmates Are Running the Asylum" and further developed in "About Face" (2007).

Components of an Effective Persona

Personas should be based on behavior patterns, not demographics. Key components are:

1. Goals - Most important

Cooper defines three types of goals:

Goal Type	Description	Example
Experience Goals (Visceral)	How the user wants to feel	"I want to feel safe when making transactions"
End Goals (Behavioral)	What they want to achieve	"I want to transfer money to my family in another city"
Life Goals (Reflective)	Who they want to be	"I want to be a responsible provider for my family"

2. Behaviors and Attitudes

• Usage patterns identified in research
• Preferences and frustrations

3. Context

• Usage environment (physical, social, technological)
• Constraints and limitations

4. Demographics (secondary)

• Fictional name and representative photo
• Basic data that helps humanize

Step by Step: Creating a Persona

1. Review all research data: Interviews, observations, surveys.
2. Identify behavior patterns: What variables distinguish different user groups?
3. Group users with similar behaviors: These groups will be your Personas.
4. Define each group's goals: Experience, end, and life goals.
5. Add context and humanizing details: Name, photo, representative quote.
6. Validate with team and stakeholders: Ensure Personas are useful and credible.

Persona Template

PERSONA: [NAME]

"[Quote that captures their main attitude or need]"

PROFILE
- Age:
- Occupation:
- Usage context:

GOALS
- Experience goal: [How they want to feel]
- End goal: [What they want to achieve]
- Life goal: [Who they want to be]

BEHAVIORS
- [Behavior pattern 1]
- [Behavior pattern 2]
- [Behavior pattern 3]

FRUSTRATIONS
- [Pain point 1]
- [Pain point 2]

USAGE CONTEXT
- Devices:
- Environment:
- Usage frequency:

Usage Scenarios

Scenarios are the narrative complement to Personas.

A scenario is a concise narrative description of how a Persona uses a product to achieve their goals.

Context Scenarios describe the ideal experience, how the product fits into the user's life to help them achieve their goals.

Example scenario:

"Maria is on the subway heading to work. She receives a notification that her mother needs money urgently for a medical emergency. Maria opens the app, and in less than a minute manages to send the money using her fingerprint, without needing to remember complex passwords. She receives immediate confirmation and can let her mother know the money is on its way."

Empathy Maps

If the Persona answers who the user is, the empathy map answers what they are going through. It's a single-page tool that organizes what you know about a user into six zones:

Zone	Question	Example (Maria, banking app)
Thinks and feels	What actually worries them?	"If this fails, my mom doesn't get the money today"
Sees	What's in their environment?	Other apps asking for a password every time
Hears	What are others telling them?	"Watch out for scams, don't enter your password just anywhere"
Says and does	What's their observable behavior?	Checks the balance three times before transferring
Pains	What frustrates or blocks them?	Not being sure whether the transfer went through
Gains	What counts as success?	Immediate confirmation she can forward

What it's actually for: its value isn't in the finished poster, it's in the conversation it forces. When a team fills the pains and gains zones with verbatim quotes from interviews, design discussions stop being about opinions.

The classic mistake: filling it with what the team imagines instead of what users said. An empathy map with no data behind it is a brainstorm dressed up as research. Every zone should trace back to a specific session.

Journey Maps

The journey map visualizes every touchpoint a user has with a product or service over time: before, during and after the direct interaction.

Where the Persona is a snapshot and the scenario is a story, the journey map is the full timeline, including everything that happens outside your product.

Components of a journey map:

• Phases: The stages of the process (e.g. Discovery → Evaluation → Purchase → Use → Support)
• Actions: What the user does in each phase
• Thoughts: What they're asking themselves, what they expect
• Emotions: The emotional curve across the journey
• Touchpoints: Where they interact (app, web, call center, branch, WhatsApp)
• Pain points: Where the experience breaks
• Opportunities: Where design can intervene

Why this matters so much in Latin America: real journeys are rarely digital end-to-end. A Chilean user who buys online may end up picking up in store, coordinating over WhatsApp and complaining by phone. If your map ends at "purchase confirmed", you're missing exactly where it's decided whether they come back.

Journey map vs. Service Blueprint: the journey map shows the experience through the user's eyes. The service blueprint adds what happens backstage (systems, people, processes) to make that experience happen. If the problem is "the user waits 3 days for their refund", the journey map tells you it hurts; the blueprint tells you why the internal process takes 3 days.

Rule of thumb: a journey map built without real user data isn't a journey map, it's a flowchart with faces on it. The emotional curve must come from what you observed, not from what you assume it feels like.

Which one do I use, and when?

Tool	Answers	Use it when
Persona	Who are they?	You need to align the team on who you're designing for
Scenario	How would they use this?	You want to describe the ideal experience of a task
Empathy map	What are they going through?	You need to build empathy and organize qualitative data for a segment
Journey map	What's the full path like?	You're looking for where the end-to-end experience breaks

None of the four is a deliverable you make once and file away. They're living hypotheses: they update when the evidence changes. A Persona from three years ago that nobody revisited doesn't describe your users, it describes the users you used to have.

---

4.5. Task Analysis

Personas and journey maps tell you who the user is and what their full path looks like. Task analysis zooms in: it takes a single important task and breaks it down into the real steps someone takes to accomplish it.

The difference from a journey map is one of scale. The journey map is the whole movie (before, during, and after, with its emotional curve). Task analysis is one scene in slow motion: the concrete steps, the decisions made along the way, and the exact point where things get stuck.

What is it for? Three things:

1. Discovering the steps the user actually takes, which are almost never the ones the team assumes.
2. Finding the precise point where a task breaks (not "checkout is confusing," but "at step 4 the user doesn't know whether they've already paid").
3. Serving as a bridge to what comes next: it feeds information architecture (section 4.6) and, later on, the user stories the development team works from.

The logic is hierarchical: a goal breaks down into tasks, each task into subtasks, and each subtask into concrete actions.

Goal: pay the electricity bill
└─ Task: find the amount to pay
   └─ Subtask: locate the account number
      └─ Action: look for the latest bill in the drawer / in email / in the app

You don't need to break everything down to the atom. You go down to the level of detail where the problems and decisions show up; no more, no less.

Task analysis template:

TASK ANALYSIS: [Task name]

GOAL (in the user's words)
- [What they want to accomplish, not which button they want to press]

HOW THEY DO IT TODAY
- Tools they use:
- Workarounds or personal tricks:

MAIN STEPS (the "happy path")
1.
2.
3.

DECISION POINTS
- [Where the user has to choose something, and with what information]

OBSERVED PROBLEMS
- [Where they hesitate, make mistakes, get frustrated, or abandon]

WHAT THEY NEED TO KNOW
- [Information they're missing at each step]

SUCCESS CRITERION
- [How the user knows they finished well]

An important detail: the goal is written from the user, not from your product. "Send money to my mom" is a goal; "use the transfers feature" is a task you assume they want to do. If you write the goal in terms of your interface, you've biased the analysis before you even start.

Where the data comes from: task analysis isn't invented in a meeting room. It comes from what you observed in the ethnographic and contextual interviews of sections 4.2 and 4.3, especially from "show and tell," when the person shows you how they really do the task, with their shortcuts and their detours.

Anecdote: on a bill-payment project, the team assumed the task started when the app opened. The analysis showed it started much earlier: the person first looked for the paper bill to copy the account number, because they didn't know it by heart. The real problem wasn't in the app, it was in a step that happened outside it. Without breaking the task apart, that step was invisible.

---

4.6. Techniques for Information Architecture (IA)

Information Architecture is the foundation of a good user experience. It focuses on how information is organized, navigation, and conceptual groupings.

Card Sorting

Purpose: Determine the navigation structure and labels of a site or application.

How it works:

1. Cards are created with content pieces or functionalities
2. Participants group cards in a way that makes sense to them
3. Grouping patterns are analyzed

Types:

• Open: Participants create their own categories
• Closed: Participants sort cards into predefined categories
• Hybrid: Combination of both

Free tools: Optimal Workshop (limited free version), UXtweak

Tree Testing

Purpose: Evaluate if a proposed navigation structure works.

How it works:

1. Users are presented with a hierarchical structure (without visual design)
2. They're asked to find specific items
3. Success and path taken are measured

When to use it: After Card Sorting, to validate the proposed structure before designing.

---

Practical Exercise - Module 4

From interview to Persona

This exercise takes about an hour and needs one thing: a real person willing to talk with you. A family member, a friend, a coworker.

Part 1: Pick a territory, not a product

Choose an everyday activity your participant actually does: ordering food delivery, paying bills, doing the grocery run, coordinating their kids' schedules. Don't pick "using app X": you're exploring a need, not evaluating an interface.

Part 2: Interview in context (20-30 minutes)

Apply what we covered in 4.2 and 4.3:

• Start with goals, not tasks. Ask why they do what they do before asking how.
• Use open-ended questions. If your participant answers with a yes or a no, the question was badly framed.
• Ask for a specific story: "tell me about the last time that happened" works far better than "what do you usually do?".
• Use show and tell: ask them to show you the phone, the app, the notebook where they write things down. People say one thing and do another, and that gap is your design opportunity.
• Take the apprentice role. Your participant is the master. If you catch yourself explaining something to them, you stopped researching.
• Write down verbatim quotes, not your interpretations. "I don't trust leaving my card saved" is worth more than "the user perceives insecurity".

Part 3: Build the Persona

With that data, build a Persona using the template from section 4.4. Constraints:

• The goals are mandatory: at least one experience goal, one end goal and one life goal.
• Every frustration must trace back to something your participant actually said.
• Demographics go last and matter least. If your Persona is defined by "woman, 34, Santiago", it isn't a Persona yet.

Part 4: The scenario

Write a one-paragraph context scenario: what the ideal experience would look like for your Persona solving that need. Don't describe screens. Describe what they accomplish.

Reflect: compare the Persona you built with what you would have assumed before the interview. What surprised you? That surprise is exactly the value of having researched instead of assumed, and it's the conversation you'll have to have with your stakeholders.

An honest note on sample size: one interview is not a Persona. A real Persona is built from patterns that repeat across several participants. This exercise teaches you the method, it doesn't hand you a valid deliverable. With a single participant you're still in anecdote territory.

---

Module 4 References

• Cooper, A. (1999). The Inmates Are Running the Asylum. Sams Publishing.
• Cooper, A., Reimann, R., & Cronin, D. (2007). About Face 3: The Essentials of Interaction Design. Wiley.
• Gray, D., Brown, S., & Macanufo, J. (2010). Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. O'Reilly Media.
• Kalbach, J. (2020). Mapping Experiences: A Complete Guide to Customer Alignment Through Journeys, Blueprints, and Diagrams. O'Reilly Media.
• Phillips, E., & Holland, F. (2026). Designing semi-structured interview guides for interpretative phenomenological analysis and reflexive thematic analysis: a practical guide. Qualitative Research in Psychology. https://doi.org/10.1080/14780887.2026.2719595 (Open Access, CC BY 4.0)
• Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media.
• Rosenfeld, L., Morville, P., & Arango, J. (2015). Information Architecture: For the Web and Beyond. O'Reilly Media.
• Hu, J., & Gao, X. (2017). Using think-aloud protocol in self-regulated reading research. Educational Research Review, 22, 181-193. Via Think-Aloud Protocol, ScienceDirect Topics.

---