User Research

User research is the practice of studying the people who use your product so design decisions rest on evidence instead of the loudest opinion in the room. It exists because your gut instinct about a stranger's behavior is usually wrong, and the cost of shipping the wrong thing is measured in quarters, not sprints. The methods split into two families: talking to people through interviews and surveys, and watching people through usability sessions, session replays, and analytics.

It is not asking users what features they want. People are unreliable narrators of their own behavior and worse at designing solutions, which is why Henry Ford's faster-horse line still stings. Research is not a focus group either, where five strangers perform opinions for a facilitator behind one-way glass. And it is not market research, which counts wallets and demographics. User research studies behavior and motivation, the why underneath the click.

The split that actually matters is generative versus evaluative. Generative research, also called discovery, happens before you build, when you still do not know what the real problem is: open-ended interviews, diary studies, contextual inquiry. Evaluative research happens after you have something to react to, even a rough Figma prototype, and asks a narrower question: does this work? That covers usability sessions, first-click tests, and A/B tests. Confusing the two is the classic rookie error, running a polished usability test on an idea nobody bothered to validate first.

In 2025 a working stack looks like this. You recruit with Great Question or dscout, run moderated sessions over Zoom or Lookback, and test prototypes unmoderated in Maze, which returns heatmaps and completion rates for a dozen testers overnight. You watch real behavior in PostHog or FullStory session replays, then dump every transcript into Dovetail or Notably, where AI clustering now drafts your themes in minutes instead of the two days tagging used to eat. Jakob Nielsen's 1993 rule still holds up: five users surface roughly 85 percent of usability problems, so you rarely need the sample size stakeholders demand before they will believe you.

Use generative research when you are entering a new market, when the metrics have gone flat and nobody can say why, or when a founder's pet idea has no evidence under it. Use evaluative research on every meaningful flow before it ships, because a thirty-minute session catches the confusing label that would otherwise arrive as a pile of support tickets three weeks after launch.

Skip formal research when the answer is cheap to test in production, when you are agonizing over two shades of blue, or when the deadline is tomorrow and a study would just be theater to justify a decision already made. Research has a real cost: recruiting drags for a week, synthesis eats days, and a badly moderated session teaches you nothing except how leading your own questions were. Bad research is more dangerous than none, because it launders opinion as fact and hands it the authority of a chart.

The cheapest useful move is five customer conversations this week, no deck, no script theater, just honest questions about the last time they hit the problem you think you solve. You will be wrong about something you were certain of, and that discomfort is the entire point of doing the work.

Raw sessions are not insight. The value only appears in synthesis, where you cluster loose observations into patterns, then translate those patterns into a journey map or a sharp problem statement the whole team can build against. Jobs to be done reframes the exercise around the progress a person is trying to make in their life, which keeps you from shipping features nobody actually hired your product to do.

User research does not tell you what to build. It tells you what is true, and the gap between those two things is every product that shipped confident and wrong.