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.

Step by Step: Conducting an Ethnographic Interview

Before the interview:

Define the interview objective (aligned with RQ)
Create an interview guide with topics, not closed questions
Prepare informed consent
Check recording equipment

During the interview:

Establish rapport: Present the purpose, ensure confidentiality, build trust.

Prioritize goals over tasks: Ask first about why (motivations) and then what (actions).

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)

Encourage narratives: Ask for stories of specific incidents, not abstract opinions.

"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.

Record verbatim phrases: The user's exact vocabulary is valuable for design.

After the interview:

Transcribe or take detailed notes immediately
Identify emerging patterns
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):

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.

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.

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.

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

Review all research data: Interviews, observations, surveys.

Identify behavior patterns: What variables distinguish different user groups?

Group users with similar behaviors: These groups will be your Personas.

Define each group's goals: Experience, end, and life goals.

Add context and humanizing details: Name, photo, representative quote.

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:

Discovering the steps the user actually takes, which are almost never the ones the team assumes.
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").
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:

Cards are created with content pieces or functionalities
Participants group cards in a way that makes sense to them
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:

Users are presented with a hierarchical structure (without visual design)
They're asked to find specific items
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.
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.
Think-Aloud Protocol. ScienceDirect Topics.