Qualitative Research

Numbers in a log tell you what happened and stop there. The fact that half the people on Pagedeck's invite screen leave without sending an invitation is right there in the logs. Why that half left is written nowhere.

At that point the meeting turns into a guessing contest. Pagedeck's did. Mia thought people arrived without the email addresses they needed. Theo thought the permission field was confusing. Noa thought the button was easy to miss. Five hypotheses came out and all five sounded reasonable. Five reasonable hypotheses don't tell you which one to fix first.

Qualitative research collects the why from people directly. Instead of gathering more numbers, it cuts the number of people and stays with each one longer. When Mia met eight teams, the most common situation was not knowing the work email address of the person being invited. That answer wasn't among the five, and no amount of staring at logs would have produced it.

You meet or watch a few people, hear what they actually did recently, then group those remarks and actions by theme to find what repeats. Five steps.

1. Write what you want to know as one question. Not "understand our users," but something answerable — how do teams that create folders and never use them find a document?
2. Pick a method. To hear about an experience, a customer interview spends about an hour with one person. To see where someone gets stuck, a usability test puts a real task in front of them. Everyday usage that people forget in interviews gets caught by a diary study, where they log their own activity for about two weeks, and when what sits on the desk matters, field research goes to where the work happens.
3. Write down who you'll ask as a condition, then recruit. Something like administrators of teams of five or more who created ten documents in the past month, picked by that condition. Research recruiting is this step, and it eats about half the schedule.
4. Meet and ask. Not "would you use a feature like this," but how did you do it the last time you did it, which was probably last week. Split the person asking from the person taking notes — alone, you lose what was just said while thinking up the next question.
5. Sort the material and connect it to a decision. Group remarks by theme and note how many people each theme came from. A theme marked six of eight gets handled differently from one marked one of eight. Two people naming something and six naming it are different findings. Then write what changes, what needs more looking into, and what you decided not to change. Without that last line, all you have is a report.

Fewer people are needed than teams expect. Meet five to eight users who match the same condition and the same statements usually start repeating, and past that point new findings drop off fast. Two more interviews after that mostly confirm what the first six already said. What you can't do is turn the result into a percentage.

The highest value comes before it's clear what to build. When the direction splits two ways and nobody knows which, when a shipped feature goes unused for reasons nobody can name, when new users stop somewhere and the team can't say where. In each case the team holds a number or a hunch and no mechanism.

It also attaches behind a number. That churn went up 8 percent from last month is in the record; the reason isn't. Meet six users who left and one or two reasons usually repeat.

Three places call for something else.

1. Questions the record already answers — what percentage abandons the signup screen is a log query. Sit eight people down for that and two weeks later you still won't have the number.
2. Things you can't change — research the checkout screen in a quarter where the payment module is frozen, and all you end up holding is a list of problems you can't fix.
3. Too late to matter — findings that arrive after the decision are a report, not an input. So the schedule runs backward from the date the team has to choose, and a question too big to answer by then gets narrowed until it fits.

"The logs won't tell us why. Let's meet eight people and then decide."

The question needs a reason, so go talk to people.

"That number came out of qualitative work. It means six people, not 75 percent."

A correction: don't convert a small sample into a proportion.

"Don't ask whether they'd use it. Ask how they did it last week."

Answers about the future don't hold up, so ask about actual behavior.

Pagedeck solved the invite screen this way. Mia wrote the one-sentence question and spent an hour each with eight administrators who had created a team in the past month, and Theo took notes.

By the sixth interview the same statements were repeating. Not knowing the work email address came up five times; the permission field came up once. So the next quarter's work wasn't the permission field — it was letting someone type a name and pull the address from the company directory.

The most common reading is that a sample this small can't be trusted. Speaking about everyone on the strength of eight people does sound off, so the reaction is a fair one. But what this research produces is a mechanism, not a proportion. Eight people cannot size a problem, and they can explain one. Not knowing an email address holds up as a finding from a single person, and the moment it holds up, what to fix is decided. Leave the misreading in place and the team sends a problem it doesn't understand out as a survey, then gets unusable answers to questions it didn't know how to write.

The other common belief is that the work amounts to asking users what they want. It's research that meets users, so that reading comes easily. But people don't remember their own behavior precisely, and they shade answers toward whoever is sitting across from them. Answers about what someone will do in future are the least reliable of all: of ten people who say they'd use something, two actually do. So questions point at what was actually done recently, and anywhere words and behavior might diverge gets confirmed by watching.