User Research

Someone has to decide what gets built, and when there is no evidence in the room the most confident voice becomes the evidence. The sentences that stand in for proof are usually the same three: everyone I know uses it this way, I personally would never use this, our competitor already ships it. None of them is a lie. What is missing is how many people the claim covers, and whether those people resemble the product's actual users.

Pagedeck had exactly that meeting about folders. Noa said none of the teams she knew touched folders. Mia said the teams she had met went looking for folders the moment they signed up. Half an hour later nothing was settled. Counted afterward, Noa had seen four teams and Mia had met five. Both were reporting facts, and neither had enough people to speak for the whole base. Meetings like this usually end on whoever outranks the room, and two months later, when the feature nobody uses ships, the same argument runs again.

User research puts a checkable record where that argument sits. What changes is not that someone meets users, which already happens, but that the meeting leaves a trail. What did we want to find out, who did we talk to and how many, how were they picked, what were they asked, and how many of them said the same thing. Six months later, when a new hire doubts the conclusion, there is a document to open instead of a debate to repeat.

Inside the Product axis this term sits in the branch that checks whether something is worth building before it gets built. That whole checking activity is called product discovery, and user research is its most-used instrument. What comes out of research does not stay raw. It gets shaped into working models: the job a customer hires the product to finish, a scattered user base compressed into one believable person, a single line tracing how someone finds the product, uses it, and leaves. User research supplies the material for all three.

Ten terms sit under this one, in three groups. The character of the answer you are after, the method that collects it, and the operations that make the whole thing repeatable. Choosing runs in that order too. Settle the character first, pick a method, and once the same work happens every month, build the operations.

Character splits by what kind of answer comes back. There are two.

1. Qualitative research — finds out why people behave the way they do, through what they say and what they are seen doing. It does not need many people. Meet five to eight users who match the same profile and the same observations start repeating, and past that point new information drops off fast. What it cannot produce is a percentage.
2. Quantitative research — measures how much or how often, in numbers. Percentages need volume, so these studies usually gather hundreds of responses. They tell you how big something is and say nothing about why.

The two are not competing options. They are a pair with an order. Qualitative work tells you what is happening and turns it into a hypothesis, and quantitative work measures how often that happens. Reverse the order and the first step stalls, because nothing says what the survey questions should ask about.

Method splits by how the answer gets collected. There are six.

1. Customer interview — forty-five minutes to an hour with one person, walking through their experience. The direction of the questions is fixed. You do not ask whether they would use a feature if it existed, you ask how they did that task the last time, last week. The first is a question about imagination, the second about something that actually happened.
2. Survey — the same question put to many people so the distribution shows. Badly written items can manufacture the answer someone wanted, so leading phrasing and option order get reviewed before anything goes out.
3. Usability test — hand someone a real task and watch where they stall. Do not ask for opinions, let them work. Five participants surface most of the serious blockers.
4. Diary study — users log their own activity over about two weeks. Everyday use that people forget to mention in an interview shows up here.
5. Field research — go where the work happens and watch it in context. Things invisible on a screen share are sitting on the desk: the sticky note on the monitor, the spreadsheet open beside the product.
6. Desk research — gather and organize what already exists. It is the cheapest and the fastest, so it usually goes first. It strips out the waste of recruiting people to answer a question someone already answered.

Operations is the group that keeps the work repeatable. There are two.

1. Participant recruiting — finding people who match the criteria. It is the longest step in practice, often half the calendar time of a study. Write the criteria as a sentence, set the incentive, and book more people than you need, because some of them will not show up.
2. ResearchOps — the scaffolding that keeps a team from rebuilding everything each time. Consent forms, a participant roster, one place where recordings and notes live, and a rule that stops the same people from being contacted too often.

One round of research runs in six steps.

1. Write down what you want to know as a single question. Not "understand our users" but something answerable, like how teams that create folders and then abandon them go about finding a document.
2. Choose the method that answers it. If the unknown is why, go qualitative. If the unknown is how many, go quantitative.
3. Decide who to ask and recruit them. Write the criteria first, something like admins of teams of five or more who created ten or more documents in the last month, and select against that.
4. Run it. Bring the questions in writing, and split moderating from note-taking. Working alone, you miss what someone just said while composing the next question.
5. Synthesize. Group what people said by theme and record how many people each theme came from. A theme marked six of eight gets treated differently from one marked one of eight.
6. Connect it to a decision. Write down what changes, what still needs looking into, and what the team decided not to change. Skip this and all that remains is a report.

Where it fits is fairly settled as well. The payoff is highest while the build is still undecided: two plausible directions and no way to tell which, a shipped feature nobody uses for reasons nobody knows, new signups stalling somewhere unidentified. Questions whose answers already sit in the record are the opposite case. The share of people who drop off the signup screen comes out of the logs, and sitting eight people down for it spends two weeks without producing the number. Researching something nobody can act on wastes the same way. Run a usability test on the checkout screen in a quarter when the payment module is frozen and what you hold afterward is a list of problems you cannot fix. Timing wastes the same way. A result that arrives two days after the decision was made is a report rather than an input, so the calendar for a round gets set backward from the date the team has to choose. If the question cannot be answered before then, it gets narrowed until it can. Eight interviews shrink to three, or a two-week diary study becomes a single task shown to five people, and a narrower answer delivered in time is worth more than a complete one delivered late.

The limits travel with the method. People do not remember their own behavior accurately, and they shade answers toward whoever is sitting across from them. Answers about future behavior are close to worthless: ten people say they would use it and two of them do. So the questions point at what someone actually did recently rather than what they would do next, and anywhere words and actions might come apart, observation settles it. The line against turning five people's comments into a percentage belongs here too.

"That came from five interviews. If you want to state it as a percentage, we need to run a survey."

Blocking a qualitative finding from being presented as a share of the whole base.

"Let's not ask for opinions this round. Just let them try it and watch where they stop."

Setting the format for a usability test.

"Recruiting takes two weeks. Having results ready for next week's meeting isn't realistic."

Asking to move the schedule because of how long finding participants takes.

The folder argument ended like this at Pagedeck. Mia set up a two-week diary study and attached a usability test with eight teams that had created more than twenty documents. Noa did not moderate, she watched from the side. When what a participant describes and what their hands do come apart, catching that gap is the observer's job.

Neither side had been right. Seven of the eight teams created folders, and six of those seven stopped using them within a week. When they needed a document they did not open a folder, they typed part of the title into search or scanned the recent list. That did not mean folders were unnecessary, and it did not mean folders needed to be better. It meant filing and finding happen at different moments. So what the team touched that quarter was the recent-documents list, not folders.

The most common misreading is that research means asking users what to build. Meeting users sounds like collecting requests, and interviews do sometimes surface feature names directly. But people are the foremost experts on their own problems and poor judges of what should solve them. The faster-horse request gets answered with a car by the product team, not by the research. Implement the request list as written and the product gains features without gaining users. The question to ask is not what do you want, it is how did you do this yesterday and where did it break. The team builds the answer out of that material.

The second is treating research as an expensive event. The picture that comes to mind is recruiting, incentives and a written report, so when the schedule tightens it is the first thing dropped. Large studies really do take weeks, but not every study is large. Showing a screen to five existing customers and giving them one task takes half a day. The cost worth calculating is not the time research takes, it is the price of skipping it. Two months building a feature that gets pulled because nobody used it, against half a day before the build: which one is cheaper is usually not close.