How do I run user interviews on my own?

A user interview is a planned conversation about someone's real past behaviour. You do not ask what they want. You ask what they did, and why.

As a solo designer, the whole job fits in four steps:

1. Plan: write one clear goal and a short guide of open questions.
2. Recruit: find five or six people who actually have the problem.
3. Run: ask about specific past events, then stay quiet and listen.
4. Synthesise: tag what you heard and look for patterns, not quotes you like.

Nielsen Norman Group's line is the right mindset: "Think of an interview as a research study, not a sales session or an informal conversation."

I believe products start with the problem, not the design. If you build something nobody wants, it might be good in itself, but it is not a good product.

So interviews are not the first step for me. First I look for what people struggle with. I start with a problem I face myself, or I research a niche: Reddit, X, and research runs through Claude, ChatGPT, or Gemini. Only then do I dig into why the problem happens, through surveys, talking to people, and studying what others already tried.

That order matters. By the time you sit down with someone, you already know which problem you are asking about. The interview fills in the why, which no thread or AI summary can give you.

One honest mistake: early on, I did not talk to enough people. I waited until I felt ready. Do not wait. An imperfect interview this week teaches you more than a perfect plan next month.

NN/g's User Interviews 101 warns that broad goals produce vague findings. So write one goal you could answer with a yes, a no, or a clear story. "Understand students" is too broad. "Learn how students decide which freelance gig to take first" works.

Then write the guide:

• A few open questions, each with follow-ups nested under it.
• Easy questions first, so the person relaxes.
• Questions about specific events, not general habits. NN/g puts it simply: "Jog the memory by asking about specific events rather than about general processes."
• No leading questions. NN/g defines a leading question as one that "includes or implies the desired answer." Compare "Why did you have difficulty with the navigation?" with "What was easy or difficult about getting to the information you wanted?"

Pilot the guide with one friend before the real sessions, and fix any question that confused them.

There is no magic number. NN/g's guidance on interview sample size says to "start with a small representative sample (say 5-6), and analyze your interviews as you go." You stop when new interviews stop telling you new things. A narrow question with similar people can need as few as five. A broad question across very different people can need 20 to 30 or more.

Where a student can find people for free:

• The communities where you found the problem. If a Reddit thread showed the pain, the people in it are your first candidates. Ask politely, and follow each community's rules.
• Your own network, but only people who truly have the problem. A friend being nice is not data.
• People who tried other solutions. They already know what failed and why.

Screen for the behaviour, not the demographic. "Has paid for a design course in the last year" beats "is 20 to 25".

• Record, with permission. Ask first, every time. Taking notes and listening at once is hard on your own.
• Ask for a story. "Tell me about the last time you..." gets real detail. "Would you use..." gets a guess.
• Follow up on details: when, how long, what they tried, how it felt.
• Probe the why. "What made you choose that?" These probes are usually improvised, not scripted.
• Slow down. NN/g notes that "Talking slowly has a calming effect and indicates that you are not anxious and have time to listen."
• Do not pitch. If you catch yourself explaining your idea, stop. You are there to learn, not to sell.

NN/g also says "the quality of the data collected is very much dependent on the interviewer's skill." That skill comes from reps, so expect your first two interviews to be your weakest.

Synthesis is where most solo designers cut corners. NN/g describes thematic analysis as "a systematic method of breaking down and organizing rich data from qualitative research" by tagging observations and quotes with codes. A light version you can do in a spreadsheet or FigJam:

1. Read everything first, start to finish, before tagging anything.
2. Tag each note by topic: "pricing worry", "tried a workaround", "trust".
3. Group the tags and look for overlaps and contradictions. Those groups are your candidate themes.
4. Take a break, then come back with fresh eyes.
5. Test each theme. Does it show up across several people, or just one memorable one? If it is one person, it is an anecdote, not a theme.

AI can speed this up. My AI workflow guide covers pasting notes in for a first pass of patterns. Keep the final judgement yourself, and always check a theme against the raw notes.

1. Write one research goal for a problem you have already seen people complain about online.
2. Draft five open questions about specific past events, and cut any that hint at an answer.
3. Book three interviews this week with people who actually have the problem.
4. Tag your notes within a day of each session, while you still remember the tone.

Then test what you design with cheap usability testing, and show both steps in your UX case study.