User Research for Beginners: what to ask, and what to do with the answers

What is user research, and what is it not?

User research is the habit of checking with real people before you commit to a design. Not a survey of a thousand strangers, not a focus group in a rented room — just short, honest conversations with the kind of people who would actually use what you are designing.

It is not asking people to design for you. "What features do you want?" produces wish lists; people are bad at predicting what they will use. Research is about understanding their current behaviour and their real problems, so *you* can decide what to design.

And it is not a one-time ceremony before the "real work". The cheapest time to learn that a checkout step confuses people is before you have built it. The most expensive time is after it is live.

Which research method should you start with?

There are several methods, and they are not equal for a beginner:

Start with interviews because they need no tool, no budget and no existing design. You can do your first one today, with a pen and five questions. Usability testing is the natural follow-up: once interviews tell you what the problems are, you design something and watch people try it. (There is a whole skill page on it: Usability Testing (/skill/usability-testing).)

How do I write questions that get real answers?

Good questions sound like curiosity; bad questions sound like a pitch. Four rules:

1. Ask about the past, not the future. People describe what they actually did far more honestly than what they imagine they would do.

• Bad: "Would you use an app that reminds you to drink water?"
• Good: "Tell me about the last time you tried to build a habit and it fell apart."

2. Keep questions open. An open question cannot be answered with "yes" or "no", so the person has to think out loud — and thinking out loud is where the insights live.

• Bad: "Was the checkout confusing?"
• Good: "Walk me through the last time you ordered food on your phone. What happened at each step?"

3. Never lead the answer. A leading question smuggles your opinion into the question, and people politely agree with it.

• Bad: "Don't you think the delivery fee is too high?"
• Good: "How did you feel about the total when you saw it?"

4. One question at a time, in plain words. "How do you order food, how often, and what do you hate about it?" is three questions wearing a trench coat. Ask the first one, wait, then ask the second. And drop the jargon: say "the screen where you pay", not "the payment interface".

Write five to eight questions before the interview and bring them on paper. You will not ask all of them — the person's answers will open better follow-ups — but the list stops you from freezing.

How many people do I need to talk to?

Five to eight conversations. That is the practical beginner answer, and here is why it is enough: after about five interviews on the same topic, you stop hearing new problems and start hearing repeats. The repeats are the point — a problem three people describe in their own words is a pattern, not an anecdote.

Two important notes:

• Talk to the right people. Five conversations with people who would actually use the product beat twenty with whoever happened to be free. If you are designing for students, talk to students — not to your designer friends.
• One topic per round. Five interviews about "ordering food on a phone" is a round. Five interviews where each person talks about a different app is five anecdotes.

How do I run the interview itself?

The mechanics matter more than beginners expect. Follow this order:

1. Set the frame (2 minutes). Say what this is: "I'm learning to design, and I want to understand how you do X. There are no wrong answers, and I'm not selling anything." People relax when they know the rules.
2. Ask permission to take notes. "Is it okay if I write while we talk?" Almost everyone says yes. Notes are fine; a recording you never listen to is not a plan.
3. Start with an easy, concrete question. "When did you last order food on your phone?" beats "Tell me about your relationship with food delivery."
4. Write down their words, not your summary. If they say "I always get nervous at the payment step because the total changes", write exactly that. Your summary ("user dislikes fees") loses the useful part — *the total changes*.
5. Follow up with "why" and "tell me more". When someone says something interesting, do not move on. "Why was that frustrating?" and a few seconds of silence will get you the real answer. Silence feels awkward; use it anyway.
6. End by asking what you missed. "Is there anything about this I should have asked?" regularly produces the best answer of the whole interview.
7. Thank them, specifically. "That story about the changing total was really useful" costs nothing and means they will say yes next time.

Total time: twenty to thirty minutes per person. Longer than that and both of you start performing instead of talking.

What do I do with the answers?

This is the step most beginners skip — and it is the whole point. Raw notes help nobody. Turn them into decisions in four steps:

Step 1 — Pull out the quotes. After each interview, read your notes and copy the exact sentences that describe a problem, a behaviour or a feeling onto separate lines or sticky notes. One observation per line. Six interviews should give you roughly 30–50 observations.

Step 2 — Group them. Put observations that say the same thing together. "I get nervous when the total changes", "the final price was different from what I saw", and "I double-check the total three times" are one group: *price surprise at payment*. Do this physically or in a spreadsheet — the grouping is the analysis.

Step 3 — Name the patterns. Each group gets a plain-language name and a count: how many of the six people mentioned it. "Price surprise at payment — 4 of 6." The count is not a statistic; it is a rough signal of how common the problem is.

Step 4 — Turn each pattern into one design change. A pattern without a change is trivia. "Price surprise at payment — 4 of 6" becomes: *show the full total, including delivery fee, on the screen before the payment button — not after.* Write the change next to the pattern. If a pattern suggests no change, it was probably not a real problem.

Expected result: a one-page table — pattern, count, exact quote, design change. That table is the research output, and it is what you bring to the wireframing stage. The UX Design & Figma Prototyping course calls the next step "Personas and User Journey Maps": the patterns you found are the raw material for both.

Worked example: six conversations about a practice checkout

The scenario is imaginary and for practice only: a food-ordering app called QuickBite (not a real product). You want to redesign its checkout, so you interview six people who order food on their phones at least twice a month.

The questions (five, on paper):

1. When did you last order food on your phone? Walk me through it.
2. What were you doing while you ordered — at home, at work, in a hurry?
3. Tell me about a time an order went wrong or annoyed you.
4. How do you decide the order is "done" and it's safe to pay?
5. Is there anything about ordering food on a phone I should have asked?

What the answers grouped into (three patterns):

Reading the table: the first pattern is the strongest (four of six, with near-identical wording) — it becomes the first design change. The third is weaker (two of six) but cheap to fix, so it stays on the list below the first two. None of these came from an opinion question; all of them came from "tell me about a time…".

Expected result: three specific screen changes, each traceable to quoted words from real conversations, ordered by how often the problem appeared. That is what "doing something with the answers" looks like.

Common mistakes

• Asking "would you use this?" People say yes to be kind. Ask what they did last time instead.
• Interviewing friends about your own idea. Friends praise; strangers describe. If you must use friends, ask about their behaviour with existing apps, not your concept.
• Writing summaries instead of quotes. "User finds checkout confusing" is your interpretation; their sentence is the evidence. Keep the sentence.
• Stopping at the notes. A notebook full of observations that never becomes a pattern table is research theatre. The grouping step is the research.
• Researching to confirm, not to learn. If every answer conveniently supports the design you already made, your questions were leading. Rewrite them and try again.

Frequently asked questions