User Research Patterns and Pitfalls

This training helps product and design teams recognize common user research patterns, strengths, and pitfalls so they can conduct more reliable studies.

A digital instructor presents all 14 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

28 minFree to watchDownloads

What you’ll learn

01User Research Examples: Patterns, Strengths, and PitfallsWelcome. Over the next fourteen slides, we're going to learn how to read user research cases analytically rather than anecdotally. In other words, we'll judge the evidence instead of just retelling the story. For every example, we'll apply three lenses: recurring patterns, genuine strengths, and common failure points. Here's a concrete illustration. A usability test shows three of five participants abandoning checkout at the shipping step. Anecdotally, that's a story. Analytically, you ask whether five participants is enough to claim a pattern, and whether the task wording primed them. Now the strengths and pitfalls in paired form. Strength: a small qualitative sample can reveal the why behind friction that analytics only count. Pitfall: treating that small sample as proof of how often the problem occurs. Why this matters now: about sixty-nine percent of researchers use AI in at least some projects, and more non-researchers are running studies. So judgment is the edge. If you're a student or teacher, here's the plain-language recap: a research case is evidence to be weighed, not a story to be repeated. By the end, you'll be able to extract patterns, spot pitfalls, and make sharper decisions from any case you encounter. Let's begin with how to read a research example: anatomy of a case.maze.co maze.co lyssna.com+22 min
02How to Read a Research Example: Anatomy of a CaseLet's build a reliable way to read any research example. Every case follows one structure: context, question, method, sample, execution, findings, decisions. When you read, separate what was observed from what it might mean, and keep recommendations distinct from both. Ask three questions. Was the question answerable? Did the method fit? Did the sample support the claim? Then watch the language. A sentence like "five of eight participants failed the task" is an observation. "The design is confusing" is a conclusion. Quick example: a team tests a prototype with five users. The strength: five users often surface most common problems. The pitfall: rare but serious issues can go undetected, so treat those findings as directional. For students and teachers, this is like reading a lab report: check the method and sample before trusting the result. Keep these terms close: sample size, saturation, leading question, and task success. Next, we look at patterns across methods, starting with generative interviews.nngroup.com pmc.ncbi.nlm.nih.gov measuringu.com+21 min
03Patterns Across Methods: Generative Interview ExamplesLet's look at the interview, the most used method and, per Hearsay and MockFlow in 2026, the most over-used one. Strong interviews move from behavior to motivation, not from opinion to preference. Here's the pattern in practice. A researcher opens with an open-ended warm-up, then probes a critical incident, a specific moment when something went wrong. Strength: you hear what people actually did. Pitfall: leading questions slip in, like wasn't that frustrating, and the participant simply agrees. Strength: convenience sampling is fast. Pitfall: you interview whoever is nearby, and one vivid quote becomes the finding. For students and teachers, think of a class project: ask what your interviewee actually did last week, not what they think they prefer. The PM lesson is simple. Write the research question before the discussion guide. That one habit prevents most of what we just named. Next, let's see how these patterns play out in usability test examples.maze.co maze.co lyssna.com+22 min
04Patterns Across Methods: Usability Test ExamplesNow let's look at patterns across usability testing. One clear pattern: each scenario carries a single clear goal, and we measure behavior, not satisfaction alone. Strength: when a researcher sets a realistic scenario and lets a participant think aloud, you hear the reasoning behind each misclick. Pitfall: just as easily, a moderator can help mid-task, and the finding now describes coaching, not the interface. For students and teachers, this is like a lab demo: if you point at the right button, you are testing your hints, not the design. Next, sample size follows the goal. Discovery ranges from five to twenty, estimation from thirty to three hundred, and comparison from forty to four hundred, per MeasuringU in twenty twenty-five. So moderated sessions suit diagnosis and early prototypes, often five to ten people, while unmoderated runs suit benchmarking, often thirty to forty. Strength: matching method to goal gives credible evidence. Pitfall: generalizing from five users to the whole market, or testing only what is easy to reach. Pause and imagine the consequence: a confident roadmap built on the wrong question. The fix is to connect findings to prioritized design changes, not an unstructured issue list. Next, we extend these patterns to diary, survey, and field methods.nngroup.com pmc.ncbi.nlm.nih.gov measuringu.com+22 min
05Patterns Across Methods: Diary, Survey, and Field ExamplesLet's compare three methods side by side. First, the diary study. A researcher asks twelve commuters to log every transit app they open over two weeks. Strength: you see in-context behavior over time. Pitfall: people drop off, so later entries thin out. In a class project, that's like asking classmates to track their study habits daily, and watching half of them quit by week two. Second, the survey. A team tests question wording on fifty people before scaling to a thousand. Strength: careful design scales insight and shows prevalence. Pitfall: when scales lead the questions, you measure your assumptions, not users. Think of a course feedback form where every item nudges students toward one answer. Third, the field study. An observer watches support agents build workarounds in their real tools. Strength: it surfaces unmet needs nobody reported. Pitfall: your presence can change what people do. So the rule is simple. Match the method to your question, then triangulate to offset each blind spot. And remember the warning from practice: the biggest predictor of study quality is still recruitment quality. Next, we'll look at extracting reusable patterns from cases.handbook.gitlab.com github.com github.laiyagushi.com+22 min
06Extracting Reusable Patterns from CasesNow let's look at how we turn individual cases into reusable patterns. The first move is to cluster findings by user goal, context, and barrier, not by project or date. Consider a researcher who reorganizes a repository so that onboarding friction from three different studies sits side by side. The strength is that cross-study themes surface; the pitfall is that re-sorting by theme can strip away the study context that made each finding trustworthy. So pause and ask what could go wrong. Second, use pattern languages such as jobs-to-be-done, journey friction points, and mental model gaps. When one team tags a checkout drop-off as a mental model gap, the strength is shared vocabulary across functions; the pitfall is that a convenient label can flatten evidence that does not fit. In a classroom, this is like grouping three case summaries by the user problem, not the assignment week. Third, run the exercise: from three case summaries, name one shared and one divergent finding. Try it with three usability cases. The strength is that divergence keeps you honest; the pitfall is that only the loudest cases get picked. Before naming any pattern, actively seek contradictory evidence. A guardrail here is to find at least one case that pushes against your emerging theme. Finally, run synthesis with pre-defined frameworks and cross-functional partners, as Revue notes for twenty twenty-six. The strength is consistency; the pitfall is that a rigid framework can hide the unexpected. Next, let's examine strengths that hold up and what makes an example convincing.handbook.gitlab.com github.com github.laiyagushi.com+22 min
07Strengths That Hold Up: What Makes an Example ConvincingLet's look at what makes an example convincing. Strong cases share three traits: a precise question, a method that actually fits that question, and transparent limitations. Take a study asking whether a redesigned checkout reduces abandonment. The team used usability testing, not a broad survey. And they named their constraint: only mobile users, only five sessions. Precise question, matched method, honest limits. Here's the strength. Findings link to evidence, decisions link to findings, insights link to the source. Here's the pitfall. When that chain breaks, a polished deck hides the gap instead of closing it. Pause on that consequence. Also, what drives action is stakeholder involvement and timing, not slide polish. Stakeholders who helped shape the questions recognize their own decisions in the findings. And a strong case preempts the objection we already knew that by showing the specific evidence that changed the decision. For students, a simple recap: the strongest project write-up is the one where a reader can trace every claim back to something you actually observed. So keep this as a reusable checklist. Apply it to any case you read, write, or inherit. Next, we'll map the pitfalls taxonomy, where research examples go wrong.handbook.gitlab.com github.com github.laiyagushi.com+22 min
08Pitfalls Taxonomy: Where Research Examples Go WrongLet's break down where research examples go wrong, because most failures fall into four buckets. Design pitfalls show up when the method doesn't match the question. A team asks why users abandon checkout, then sends a survey, and the survey tells them what people believe, not what they did. Execution pitfalls happen in the room. A facilitator asks, wouldn't you find this feature helpful, and the participant agrees. Now the finding is contaminated. One note-taker means zero inter-rater reliability, so missed observations stay invisible. For students, think of a group project with one person taking all the notes. If nobody compares them, nobody knows what got missed. Synthesis pitfalls follow. Cherry-picking quotes, ignoring disconfirming evidence, and treating frequency as importance. As UX Planet puts it, directional data is not definitive. Then impact pitfalls. Late delivery, findings without implications, reports with no action items. Prevention is straightforward. Write a pre-study plan, then add a post-study limitations section. Next, we will work through Case Clinic A, diagnosing a generative interview study.uxmatters.com blog.uxtweak.com uxplanet.org+22 min
09Case Clinic A: Diagnosing a Generative Interview StudyLet's move into our first case clinic, where we diagnose a generative interview study together. We'll read an anonymized interview case against the anatomy template you've learned. But here's the discipline: check sample quality and moderator skill before you touch any findings. Those upstream choices shape everything downstream. A strength that often survives is careful, neutral questioning, because it lets participants reveal what they actually do, not just what they say. The paired pitfall is a moderator who interrupts too often, breaking concentration and pushing people back into interview mode. Pause and think about the consequence there. Then we do a whole-room diagnosis: which pitfalls show up, and which strengths survive scrutiny? Our verdict asks whether this evidence supports a decision, a hypothesis, or only a story. In practice, the earliest defects usually hide in the research question itself, not in the data. If you're a student or teacher, think of it like grading a lab report: a weak question undermines even clean results. Next, we take on case clinic B: diagnosing a usability test and a survey case.uxmatters.com blog.uxtweak.com uxplanet.org+22 min
10Case Clinic B: Diagnosing a Usability Test and a Survey CaseLet's work through Case Clinic B, where we diagnose two short cases side by side: a moderated usability test and a scaled survey. Here is the paired contrast. A moderated test with eight participants can diagnose why people struggle, because the moderator probes in real time. That is its strength. Its pitfall is treating eight people as if they estimated prevalence across a whole population. Now the survey: a sample of two hundred can estimate how common a behavior is, with a stated margin of error. That is its strength. Its pitfall is using it to explain why something happened, since it captures what people report, not what they do. So keep the sample size tied to the goal. Discovery ranges from five to twenty. Estimation, thirty to three hundred. Comparison, forty to four hundred, per MeasuringU in twenty twenty-five. Plain-language recap for students and teachers: match the method to the claim, then ask which case is safe to act on now and which needs triangulation first. The same method can be a strength in one context and a pitfall in another. Next, we move into the Practical Workshop: Critique a Case, Avoid the Pitfalls.nngroup.com pmc.ncbi.nlm.nih.gov measuringu.com+22 min
11Practical Workshop: Critique a Case, Avoid the PitfallsNow let's put the anatomy template, the strengths checklist, and the pitfalls taxonomy to work. Take a short case and critique it in small groups. Researchers and designers focus on method and bias. Product managers focus on decision traceability, whether each finding links back to real evidence. Students and teachers focus on the critique write-up itself. In the debrief, follow one rule: name one strength and one risk, and cite the evidence for each. So rather than saying the study felt thin, you might say it used five moderated sessions, which is solid for discovery, though it under-samples users with assistive technology. Pause there and ask what that gap could cost. Then close with a personal action plan: one pitfall you will avoid in your next study or reading. For students, that might simply mean checking whether the sample matched the research question before accepting a conclusion. Next, we look at making examples travel through repositories, evidence layers, and review.handbook.gitlab.com github.com github.laiyagushi.com+21 min
12Making Examples Travel: Repositories, Evidence Layers, and ReviewNow let's talk about making examples travel, so a study done six months ago stays useful today. A workable repository has three layers. The evidence layer holds the raw data, such as transcripts and recordings. The insight layer holds tagged findings. The connection layer links insights across studies. That structure has a clear strength: when a stakeholder asks whether users really said something, you can trace straight back to the source. The pitfall is that repositories decay, because tagging is tedious and nobody wants to maintain them. So add governance. Keep your taxonomy to three broad dimensions: product area, user segment, and research type. Require every insight to name what was learned, its evidence, and the implication. Adoption comes from demonstration: answer a live stakeholder question from the repository during their meeting. Traceability is the difference between a finding and an opinion. AI helps triage and search, but read transcripts before changing a roadmap. In a classroom, this is your shared project archive with a clear labeling rule. Next, bringing it back: transferring patterns to your own practice.handbook.gitlab.com github.com github.laiyagushi.com+22 min
13Bringing It Back: Transferring Patterns to Your Own PracticeNow let's bring it back to your own practice. First, build a personal case library, organized by pattern, strength, and pitfall. Second, use pre-study, during-study, and post-study checklists. At the pre-study stage, a checklist catches unclear goals and the wrong method. During the study, it catches leading questions and missing notes. Post-study, it catches rushed analysis and missing follow-up. These checklists matter because repository research shows insight gets lost without a system. Practitioner guidance is consistent here, so plan a home for findings before data collection begins. Add summaries in plain language and a consistent naming structure, since too many tags or jargon makes a repository unusable. Third, go deeper with public research libraries, open datasets, and case retrospectives. Fourth, remember the human edge. Tools now handle transcription and first-pass coding, but people frame sharper questions, interpret nuance, and defend findings. Very simply put, keep your own folder of examples and a short checklist, just like you would for a class project. Finally, recap the three lenses: patterns, strengths, pitfalls. Use all three, every time. Next, let's apply them in the assessment, Spot the Strength, Name the Pitfall.handbook.gitlab.com github.com github.laiyagushi.com+22 min
14Assessment: Spot the Strength, Name the PitfallLet us close with assessment, because spotting quality is the skill. Take four short case snippets. For each, name one strength and one pitfall. Example: a team runs five moderated sessions on one prototype. Strength, tight scope reveals common problems. Pitfall, directional data presented as definitive. Pause there. What consequence follows if leadership reads it as proof? Next, write a five-line critique using the anatomy template: context, method, evidence, bounded claim, limitation. Then rate your case from exploratory to decision-grade confidence, and cite evidence for every answer. The knowledge base reinforces this. Nielsen's five-user rule applies to formative discovery, roughly eighty-five percent of common issues, not estimation or comparison, which need thirty to three hundred or more. UserTesting notes exploratory work uses about eighty percent confidence, while higher-stakes studies need ninety. For students and teachers, a plain recap: in a class project, say what five users can and cannot tell you before claiming a design is solved. Finally, reflect. Which lens is weakest in your own practice? Sampling, moderator neutrality, evidence citation, or bounding claims? Thank you for working through all fourteen slides. You now hold a practical pattern library and a critical eye. Keep testing, keep citing evidence, and keep your claims honestly bounded. Well done.handbook.gitlab.com github.com github.laiyagushi.com+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.15 pages · 3.1 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.15 pages · 15.9 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.15 pages · 3.0 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.