HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Talking to Users

Choosing the right research method and asking questions that don't secretly answer themselves.

⚡ Total XP: 0|💻 management XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.

🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.

It's easy to run a study, get a page of quotes, and still walk away having only confirmed what you already believed — user research only works when it's designed to be able to prove you wrong.

1Qualitative vs. Quantitative: When to Use Each

Qualitative methods — one-on-one interviews, moderated usability tests, contextual inquiry — are best early, when you don't yet know what the problem even is. They produce depth, not statistical confidence. Quantitative methods — surveys, A/B tests, product analytics — are best once you have a hypothesis and need to know how many users it applies to. Using a survey to discover an unknown problem, or a single interview to size a rollout decision, is using the wrong tool for the question.

2The Leading Question Trap

Questions like 'Wouldn't a faster checkout be better?' don't gather information — they gather agreement. Neutral phrasing ('Tell me about the last time you checked out on this kind of site') gets closer to reality because it doesn't hint at a preferred answer. It's also worth tracking the say/do gap: users often report intentions ('I'd definitely pay for that') that don't match their actual behavior, so pairing interviews with behavioral data catches the difference.

3Step-by-Step Breakdown

Introduction. User research is how a PM replaces internal opinion with evidence before committing engineering time to an idea. Skipping it doesn't mean you avoid making assumptions — it just means you never find out which of your assumptions were wrong until after you've shipped.

Qualitative vs. Quantitative. Qualitative research — interviews, usability tests — tells you why users behave a certain way and surfaces problems you didn't think to ask about. Quantitative research — surveys, analytics — tells you how many users share that behavior and at what scale. Use qualitative to discover the problem, quantitative to size it.

Avoiding Bias. The fastest way to get useless research is to ask leading questions that hint at the answer you want. 'Wouldn't a dashboard be useful?' invites agreement; 'Walk me through how you currently track this' invites the truth. Also watch the say/do gap — what users claim they'd do and what they actually do often diverge.

Knowledge Check. An interview question asks 'Wouldn't it be great if we added dark mode?' What's wrong with it?

→It's a leading question that nudges the user toward agreeing rather than revealing their actual opinion
→It uses a technical term the average user won't understand

Summary. Good research pairs the right method with the right question at the right time — qualitative to find the problem, quantitative to size it, and neutral phrasing throughout so the answers reflect reality instead of the interviewer's hopes.

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Asking leading questions that hint at the desired answer

// Wrong
'Wouldn't a one-click checkout make your life easier?'

// Correct
'Walk me through the last time you checked out on a site like this — what stood out?'

The Solution //

Phrasing a question so it nudges toward agreement produces flattering data, not accurate data. Rephrase questions to be neutral and open-ended so the user's real opinion has room to surface, including disagreement.

The Error //

Trusting what users say over what they actually do

// Wrong
Ship a paid tier because 80% of survey respondents said they'd pay for it

// Correct
Run a smoke test / fake-door test to see how many actually click 'Upgrade' before building the feature

The Solution //

Users routinely say they'd pay for a feature, use a tool daily, or care deeply about a problem, then behave completely differently once given the chance. Pair interviews and surveys with behavioral data — usage logs, A/B tests, purchase history — to catch the say/do gap before it drives a bad roadmap bet.