Module 3: Strategic Planning

Defining the Problem and Roadmap

Learning objective: At the end of this module, you will be able to formulate clear and measurable research objectives, turn them into hypotheses that can be refuted, choose a sampling strategy, select appropriate methods according to context, and apply ethical principles in user research.

Estimated time: 2 - 2.5 hours


This module marks the transition from theory to practical action. Strategic Planning is the foundation of any research project, ensuring that limited resources are invested in obtaining the knowledge the business needs.

From here to the end of the course you'll walk a full lap of the research cycle, and you'll do it on a single case that will stay with you: the corner store from the exercise. You plan now (M3), discover and model (M4), evaluate (M5), measure (M6), and close by analyzing and communicating (M7).


3.1. Defining Objectives and Research Questions

The planning stage begins long before choosing a tool; it starts with clarity about what needs to be known.

Defining the Research Problem

A useful research study depends on a clear statement of the problem. In the UX context, the problem is defined as the lack of information that needs to be resolved.

Before choosing a method, it's fundamental to be clear about:

  • What is the business objective?
  • What do we need to learn to achieve it?

The Research Question (RQ)

The research question is the heart of all the work. It's the backbone that will be constantly referred to.

Characteristics of a good research question:

  1. From General to Specific: An initial question is usually too vague. It must be refined to include contextual details.
  1. Includes Context: Who will use the product? For what task? In what domain? How will success be defined?
  1. Concise but Complex: Cannot be answered with a simple yes, no, or a number.
  1. Aligned with the Method: Qualitative questions seek to understand experiences ("what?", "how?", "why?"). Quantitative ones seek to measure ("how much?", "how often?").

Refinement example:

Vague QuestionRefined Question
"Do they like our app?""What factors influence 25-35 year old users in Chile to complete the purchase process in our mobile app?"

Establishing SMART Objectives

Research objectives must be:

  • Specific: Clearly defined
  • Measurable: With clear success criteria
  • Achievable: Realistic with available resources
  • Relevant: Aligned with business
  • Time-bound: With time limit

Example of SMART objective:

"Identify the 3 main friction points in the checkout flow for new users during the next 4 weeks, through 8 usability tests."

From question to hypothesis: betting on something you could lose

The research question opens up the space of what you don't know. The hypothesis does the opposite: it commits to a tentative answer, one that could be wrong. It isn't mandatory in every study (generative research often starts from loose assumptions rather than formal hypotheses), but when you write one you gain two things: you focus what to look at, and you force yourself to be able to be wrong. Sometimes we're right about the hypothesis and many times we're not, but in both cases we learn, and we come away with information for the business.

In Module 2 we saw that a claim no possible result could refute isn't a hypothesis, it's a belief. Here we put that into practice.

A useful hypothesis has four parts:

We believe that [something happens or will happen] because [reason grounded in what you've already observed]. We'll know if [observable signal], measured by [concrete data or behavior].

  • We believe that — your prediction, not a wish.
  • because — where the hunch comes from: a previous interview, an analytics data point, a pattern you saw. If you can't fill in this part, you don't have a hypothesis, you have a guess.
  • we'll know if — what would have to happen to hold it true or false.
  • measured by — the specific evidence you're going to look for.

Example (following the corner store):

  • Guess: "people don't buy because the site is ugly."
  • Hypothesis: "We believe customers abandon the cart because they don't know when or how their order will arrive. We'll know if at least half the people we interview bring up delivery uncertainty before we ask about it, measured by their own words in the interview and the abandonment rate at the shipping step."

Notice the difference: the first can't be refuted (ugly according to whom?); the second tells you exactly what to listen for and when you'd be wrong.

From hypothesis to questions: each hypothesis translates into something you'll ask or observe. The store one isn't asked head-on ("do you abandon because you don't know when it arrives?" leads the answer). You explore it sideways: "tell me about the last time you bought something online and it didn't arrive when you expected." Your hypotheses are the bridge between the research question and the interview questions you'll see in Module 4.

Three ways to ruin a hypothesis:

  1. It can't be refuted: "users want a good experience." Nobody will ever discover otherwise. With no risk of being wrong, you learned nothing.
  2. It's so vague any result confirms it: "improving checkout will increase sales." By how much? Which part of checkout? In what timeframe?
  3. You have no way to measure it: if you can't name the signal that confirms or denies it, it isn't ready yet.

An honest note: don't fall in love with your hypotheses. You write them to test them, not to defend them. If you end up looking only for the evidence that proves you right, you're back to the confirmation bias we saw in Module 2.


3.2. The Map of UX Research Methods

User research can be applied at any stage of the design process. The choice of method depends on the objectives and phase of the project.

The Methods Matrix (Rohrer, 2014)

Christian Rohrer, from Nielsen Norman Group, proposed classifying methods according to three dimensions:

Dimension 1: Data Type

QualitativeQuantitative
Focuses on why and howFocuses on how much and how often
Observation and conversationNumerical values and metrics
Small samplesLarge samples
Generates hypothesesValidates hypotheses

Dimension 2: Focus

AttitudinalBehavioral
What users sayWhat users do
Surveys, interviewsUsability tests, analytics
Opinions and preferencesObservable actions

Dimension 3: Usage Context

  • Is the product used during research?
  • Is it in-person or remote?
  • With moderator or unmoderated?

Research According to Project Phase

PhasePurposeTypical Methods
DiscoveryKnow the user, identify needs, validate hypothesesInterviews, contextual observation, exploratory surveys
ConceptualizationValidate concepts and early prototypesCard sorting, tree testing, tests with low-fidelity prototypes
DevelopmentEvaluate usability and refine designUsability tests, heuristic evaluation
Post-launchMeasure satisfaction and detect problemsAnalytics, satisfaction surveys, A/B tests

Fundamental rule: The earlier research is conducted, the greater the impact on the product.


3.3. The 4-Phase Framework (NN/g)

Ever felt like research is something you do once and then forget? You're not alone, it's happened to me, to you, to everyone, and it'll keep happening, but let's work to make it happen less :)

Susan Farrell of Nielsen Norman Group offers a much healthier mindset: "Research should be ongoing, not finished." Research is a continuous cycle.

Here's her 4-phase framework, which helps you know which method to use at each moment in your product's life:

PhaseWhat are we after?Typical Methods (Toolbox)
DISCOVERUnderstand the unknown. Illuminate the problem before thinking about solutions.• Field study
• Diary study
• User interviews
• Stakeholder interviews
EXPLOREDefine the problem and its scope. Map the current experience and propose concepts.• Competitive analysis
• Design review
• Personas & Journey Maps
• Card sorting
• Prototypes (low fidelity)
TESTValidate specific solutions. Does this thing we designed work?• Usability tests (moderated/unmoderated)
• Benchmark testing
• Accessibility evaluation
LISTENMonitor the product's health live. Detect new problems.• Surveys (NPS/CSAT)
• Analytics
• Search logs (what people search on your site)
• Frequent bug review

Real Example: Redesigning a Delivery App in Chile 🇨🇱

Imagine you work on a delivery app (like Cornershop or Rappi) and they want to improve retention. Here's what the cycle would look like:

  1. Listen: You look at Analytics and see that 40% abandon at the cart.
  2. Discover: You run interviews to understand why. You find they don't trust the fruit will arrive fresh.
  3. Explore: You build a prototype where the user can choose the "ripeness" of their avocados (green or ready-to-eat). :avocado:
  4. Test: You test that prototype with 5 users. They love it, but they don't understand the avocado icon. You adjust.
  5. Listen: You launch and monitor whether the abandonment rate drops.

See? You never "finish" researching. It's a constant cycle of curiosity.


3.4. Impact Recruitment: The Art of the Screener

You can have the best research plan, but if you recruit the wrong people, your insights will be garbage ("Garbage In, Garbage Out").

To avoid this, we use a tool called a Screener (filter questionnaire).

What is a Screener?

It's a short questionnaire (usually an online survey) that filters participants to make sure they match the profile you need.

Golden tips for your Screener:

  1. Don't ask obvious questions: If you ask "Do you like coffee?" for a coffee study, everyone will say yes because they want the incentive. Better ask: "Which of these drinks have you had in the last week?" with a list (Tea, Coffee, Soda, Water). That way you filter without revealing what you're after.
  2. Define exclusion criteria (Kill questions): Questions that disqualify immediately. (E.g.: if you work at a bank and the user works for a competitor.)
  3. Look for articulation: If you need participants for an interview, include an open question (E.g.: "Tell me about your last bad online shopping experience"). If they answer with a single word ("Bad"), maybe they're not the best conversationalist for a 60-minute interview.

A question for you: Have you ever done research with "work friends" instead of real users? (I have, and I promise not to judge you, but let's cure ourselves of that habit today.)

Who to look for and how many: sampling strategy

A screener — the short filter questionnaire that decides whether a person qualifies — answers one question. Sampling strategy answers an earlier one: who you go looking for, and how many. They're two different questions, and both get botched often.

First, let's clear up a misunderstanding: in qualitative research you're not after a statistically representative sample. With 5 or 8 interviews you won't "represent" anyone, and that's fine, because that's not the goal. You're after range: covering the variety of situations, not the average. It's called purposive sampling, and it's the opposite of grabbing whoever is closest at hand.

Three strategies that actually work with small samples:

StrategyWhat it isWhen you choose it
Maximum variationYou pick participants as different from each other as possible on the dimensions that matter (experience, context, usage frequency)When you want to discover the full range of needs, not the typical case
Extreme caseYou look for those at the edges: the one who uses the product every day and the one who abandoned itWhen the extremes reveal what the average hides
Lead usersPeople who already solved the problem on their own, with their own workaroundsWhen you want to anticipate needs the rest can't articulate yet

What almost never helps is the "average user": it's a statistical invention that doesn't exist in reality. Designing for the average tends to end in a product that fits no one well.

And how many? Here you have to separate two cases, because they get confused all the time:

  • For usability testing: Jakob Nielsen's rule (2000) says 5 users uncover about 85% of usability problems, and that it's better to run several rounds of 5 than one big test. Careful: this rule is for finding problems in an interface, not for every kind of research.
  • For interviews and qualitative research: there's no magic number. The guide is saturation: you stop adding participants when new interviews stop bringing new themes. We cover it in detail in Module 7.

On a real project with a tight budget (a small corner store, say) you'll rarely run the ideal interviews. It's fine to do fewer, 2 or 3, as long as you're honest about what that allows and what it doesn't: with that many you learn the method and raise hypotheses, but you don't yet confirm a pattern. Naming that limitation in your report is part of the rigor, not a weakness.


3.5. Scope, Resources, and Ethics

Planning Factors

The research plan must consider:

Financial Resources and Time:

  • What is the deadline for making a decision?
  • What budget is available?
  • The objection of "lack of time" is overcome by adjusting scope, not eliminating research.

Team and Tools:

  • Are there trained researchers available?
  • What tools are available (recording software, recruitment platforms)?

Access to Participants:

  • How will representative users be recruited?
  • What incentives will be offered?

The Importance of Stakeholder Interviews

Before starting any research, the Clarity process is crucial: the necessary conversation before beginning any project.

Meeting with stakeholders allows:

  • Identifying the real questions and concerns of the business
  • Aligning expectations about results
  • Ensuring findings will be actionable

In an ideal team:

  • UX is the carrier of the user's voice
  • Product (PO) is the carrier of the business voice
  • Development ensures technological feasibility

Ethics, Privacy, and Transparency

Ethics is a central priority in modern research.

Fundamental ethical principles:

  1. Informed Consent: Participants must understand what will be researched, how their data will be used, and have the freedom to withdraw at any time.
  1. Data Privacy: Comply with regulations like GDPR. Personal data must be anonymized and protected.
  1. Do No Harm: Avoid questions or tasks that may generate emotional distress.
  1. Transparency in Purpose: While in some cases the specific objective is hidden (to avoid participants altering their behavior), deception must be minimized and ethically justified.

Step by Step: Creating a Research Plan

  1. Define the problem: What information does the business need to make a decision?
  1. Formulate the research question: Refine it until it's specific and actionable.
  1. Establish SMART objectives: What will you achieve and how will you measure success?
  1. Select the method: Use Rohrer's matrix to choose according to your needs.
  1. Define the sample: How many participants? With what characteristics?
  1. Plan logistics: Schedule, tools, recruitment, incentives.
  1. Prepare ethical documents: Informed consent, confidentiality agreement.

Template: UX Research Plan

UX RESEARCH PLAN

Project: [Name]
Date: [MM/DD/YYYY]
Lead Researcher: [Name]

1. BUSINESS CONTEXT
   - Business problem:
   - Decision to be made:
   - Decision deadline:

2. RESEARCH QUESTION
   - Main question:
   - Sub-questions:

3. OBJECTIVES
   - General objective:
   - Specific objectives (SMART):

4. METHODOLOGY
   - Selected method:
   - Justification:
   - Approach: [ ] Qualitative [ ] Quantitative [ ] Mixed

5. PARTICIPANTS
   - Target user profile:
   - Sample size:
   - Inclusion criteria:
   - Exclusion criteria:
   - Recruitment method:
   - Incentive:

6. LOGISTICS
   - Duration per session:
   - Modality: [ ] In-person [ ] Remote
   - Tools:
   - Schedule:

7. DELIVERABLES
   - Report format:
   - Delivery date:
   - Audience:

8. ETHICAL CONSIDERATIONS
   - Informed consent: [ ] Yes
   - Data anonymization: [ ] Yes
   - Secure storage: [ ] Yes

Practical Exercise - Module 3

Framing the problem: the corner store

A corner store in your city decided to sell online during the pandemic. Today it has a site with a catalog and a cart, but the owner tells you: "people come in, they look, and they don't buy. I think we need to change the button color."

That's the real starting point of most projects: someone brings you a solution, not a problem.

Part 1: From the request to the research problem

Reframe the owner's request as a research problem. Remember the problem isn't "the buttons are wrong", it's the missing information you need to resolve. Complete:

"We don't know ______________ and that prevents us from deciding ______________."

Part 2: The research question

Write a research question. Before calling it done, check it meets the four characteristics we covered:

  • Does it include context? (who, for what task, in what situation)
  • Is it concise but not answerable with a yes/no or a number?
  • Is it aligned with a method you can actually execute?
  • If it's qualitative, does it ask what, how or why?

Part 3: The SMART objective

Turn the question into an objective with an observable action verb. Check every letter: Specific, Measurable, Achievable, Relevant, Time bound.

Watch out for the A: the store has no budget for 30 participants or a lab.

Part 4: The hypothesis

Turn your question into a hypothesis you could lose. Use the structure from section 3.1:

"We believe ______________ because ______________. We'll know if ______________, measured by ______________."

If you can't fill in the because with something you've already observed or sense from data, you still have a guess, not a hypothesis.

Part 5: The method

Place your question on Rohrer's matrix. Do you need to know what people say or what they do? Do you need the why or the how many? Justify your chosen method in one sentence.

Part 6: The sample and the screener

First decide who to look for: are you better served by maximum variation, extreme cases, or lead users? Justify in one sentence why that profile, and not "the average user," will teach you more.

Then write three screening questions to recruit those people. At least one must rule out someone who isn't your target user.

Reflect: could your research end up concluding that the owner was right about the buttons? If the answer is no, your hypothesis isn't falsifiable and you're researching to confirm what you already decided.


Module 3 References