Research Questions vs Interview Questions: How to Turn What You Want to Know Into What You Ask

A research question is what you want to learn. An interview question is what you actually ask a participant to get there. They are almost never the same sentence. "Why do trial users fail to convert?" is a good research question and a bad interview question: ask it directly and you get the participant's theory about themselves, which is often wrong. The skill is translation. Each research question becomes several interview questions about concrete experience, and the answer to the research question comes from your analysis of what people tell you, not from anyone answering it outright.

This guide explains the difference, why asking your research question directly fails, how to translate one into the other step by step, and how to check that the questions you ask actually answer the questions you have.

The difference in one table

Steinar Kvale and Svend Brinkmann, whose book InterViews is a standard text on qualitative interviewing, make the distinction clearly. Research questions are written in the language of your field and your decision. Interview questions are written in the participant's language, about their life. They suggest judging each interview question in two ways: "thematically with regard to producing knowledge and dynamically with regard to the interpersonal relationship in the interview." A good interview question has to do both. It has to feed your research question, and it has to be easy and natural to answer.

Why you can't just ask your research question

It is tempting to skip the translation. If you want to know why people churn, ask them why they churned. Two lines of evidence explain why that goes wrong.

People can't always report the causes of their own behaviour. In a classic study, Nisbett and Wilson (1977) asked shoppers to choose between identical pairs of stockings laid out in a row. People tended to favour the pairs on the right. When asked why they chose the pair they did, not one participant mentioned its position. They talked about knit, sheerness and elasticity instead. Their reasons were sincere and fluent, and they were not the cause. Ask a churned customer "why did you leave?" and you will get the same kind of answer: a plausible story assembled on the spot.

What people say they will do is a weak guide to what they do. Sheeran (2002) pulled together meta-analyses covering 422 studies and 82,107 participants. On average, people's stated intentions explained 28% of the variance in their later behaviour. That is a real relationship, and it leaves most of the behaviour unexplained. A follow-up meta-analysis by Webb and Sheeran (2006) found that even a medium-to-large change in intention (d = 0.66) produced only a small-to-medium change in behaviour (d = 0.36). So "would you pay for this?" is the research question wearing a disguise, and the answer will flatter your idea.

The fix is to ask about what people did, in specific recent situations, and to infer the "why" yourself from patterns across many such stories.

How to translate research questions into interview questions

1. Write the research question for your team

Start with the decision. "Should we rebuild onboarding or invest in the integration library?" leads to a research question such as "What stops new teams from reaching their first shared report in the first two weeks?" Keep it in your own language. Nobody outside the team will see it.

2. Break it into sub-questions

Most research questions bundle several things. "What stops new teams from reaching a first shared report?" contains: what they were trying to do, what they tried, where they got stuck, what they did about it, and who else was involved. Each of those is a sub-question, and each will get its own small cluster of interview questions.

3. For each sub-question, ask: what experience would show this?

This is the translation step. You are looking for a moment the participant actually lived through that would reveal the answer. "Where they got stuck" becomes "Tell me about your first week with the product. What did you try to do first?" followed by "Was there a point where you weren't sure what to do next? What happened?"

A few more pairs, from research question to the question you would actually ask:

• "Why do trial users not convert?" Don't ask "Why didn't you upgrade?" Ask "Walk me through your first few days. What did you set up first?"
• "Would customers pay for feature X?" Don't ask "Would you pay for this?" Ask "What do you use for this today, and what does it cost you?"
• "What drives churn in small teams?" Don't ask "Why did you cancel?" Ask "When the trial ended, what happened? Who was involved in deciding?"
• "How do teams share research findings?" Don't ask "Do you share findings with your team?" Ask "Tell me about the last time you shared a finding. What did you do?"

4. Rewrite in the participant's words

Strip out your internal vocabulary. "Activation", "onboarding flow", "workspace" and "seat" may mean nothing to the participant, or something different. Use the words they would use, and if you're not sure what those are, a pilot interview will tell you.

5. Order them from broad to specific

Open each topic broad and narrow it down, so the participant raises things before you do. This is the funnel technique. Keep yes/no and rating questions to the end of each topic, after the story.

6. Map every interview question back

Make a simple two-column list: each interview question and the research question it serves. Any interview question that serves nothing gets cut. Any research question with no interview questions under it has a gap. Milagros Castillo-Montoya (2016) puts this alignment check first in her Interview Protocol Refinement framework, before anything else is done to the guide.

Check the protocol before you run it

Castillo-Montoya's framework has four phases. They work as well for a product team's discussion guide as for an academic protocol.

Photo by Vitaly Gariev on Unsplash

1. Align interview questions with research questions. The mapping in step 6 above. Cut any question that serves nothing.
2. Build an inquiry-based conversation. Turn the list into something that flows: an opening, transitions between topics, follow-up prompts and a close. A participant should feel they are having a conversation, not filling in a form out loud.
3. Get feedback on the protocol. Have a colleague read it as if they were the participant. Ask them which questions are confusing, which feel leading, and which they would struggle to answer.
4. Pilot it. Run one or two real interviews and check whether the answers actually speak to your research questions. If a question gets blank looks or answers you can't use, rewrite it before the main round.

Worked example

Research question: "Why do small teams stop using the product after the free trial?"

Direct question to avoid: "Why did you stop using the product?" It asks for a self-diagnosis, and people will give you the easiest reason to say out loud, usually price.

Interview questions to ask instead:

• "Take me back to when you first signed up. What was going on that made you look for something like this?"
• "Walk me through the first few days. What did you set up first?"
• "Who else on your team used it? How did they come to start using it?"
• "Think about the last time you opened it. What were you trying to do?"
• "When the trial ended, what happened? Who was involved in deciding?"
• "What are you using for this now?"

None of those mention churn, value or price. Yet together they will tell you whether the product never reached the rest of the team, whether it lost to an existing habit, or whether price really was the issue. You find the answer to the research question in the pattern across 15 or 20 of these conversations.

Common mistakes

• Pasting the research question into the guide. The most common mistake, and the most expensive, because the answers look useful.
• Asking about the future. "Would you use...", "How likely are you to..." Ask about the past instead.
• One interview question per research question. One question gets one angle. You need several routes into each topic.
• Questions that serve nothing. If you can't say which research question an interview question feeds, it is taking time from the ones that matter.
• Skipping the pilot. The gap between what you meant and what participants hear only shows up when someone answers.

How Koji helps

Koji is built around this translation. You start a study by typing the research question, in your own words, on the home screen. Koji's research brief assistant then drafts a brief from it: a research goal and a set of interview questions written for participants, each tagged with its question type.

You keep control of the translation. The brief is fully editable. You can rewrite any question, reorder them, change their types, and ask the assistant for changes in plain language; it tells you exactly what it changed. If a draft question is just your research question in disguise, rewrite it as a question about a specific past moment. See how to write a research brief for more on getting the brief right.

Context makes questions sound like the participant's world. Upload context documents such as support tickets or onboarding notes, and the AI uses them for drafting and for sharper follow-ups during the interview.

Follow-ups go where your analysis needs them. For each question you set how many follow-ups the AI interviewer may ask, from none up to three, with instructions on what to probe. That is how you make sure a broad experience question gets pushed toward the detail your research question needs.

Piloting is free. The Preview tab lets you take your own interview in voice or text exactly as a participant would. Previews don't use credits, don't count as responses and don't appear in the report, so you can run the protocol yourself before any real participant sees it.

Analysis answers the research question, not each interview question. Koji's report groups what participants said into themes across all interviews and links each finding to the supporting quotes. That is the step where the research question finally gets its answer.

Related Resources

• Writing a research question
• How to write great interview questions
• The funnel technique
• Structured questions guide
• How to write a research brief
• Pilot studies in user research

Sources

• Brinkmann, S., & Kvale, S. (2015). InterViews: Learning the Craft of Qualitative Research Interviewing (3rd ed.). SAGE.
• Castillo-Montoya, M. (2016). Preparing for interview research: The Interview Protocol Refinement framework. The Qualitative Report, 21(5), 811–831.
• Nisbett, R. E., & Wilson, T. D. (1977). Telling more than we can know: Verbal reports on mental processes. Psychological Review, 84(3), 231–259.
• Sheeran, P. (2002). Intention–behavior relations: A conceptual and empirical review. European Review of Social Psychology, 12(1), 1–36.
• Webb, T. L., & Sheeran, P. (2006). Does changing behavioral intentions engender behavior change? A meta-analysis of the experimental evidence. Psychological Bulletin, 132(2), 249–268.