Qualitative Interviews and Discussion Guides: A Practical Guide for Business Analysts

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Some of the most useful information a Business Analyst will ever uncover will not appear in a spreadsheet, process map or system report.

It'll come from somebody saying:

“That's how the process is supposed to work, but it isn't what we actually do.”

Or:

“Customers keep getting stuck at this point, although we're not really sure why.”

Or perhaps:

“Nobody has ever asked me that before.”

Qualitative interviews give Business Analysts the opportunity to explore those answers properly. They allow us to understand experiences, behaviours, motivations, problems, workarounds and perceptions that quantitative data alone may struggle to explain.

But there is an important distinction between having a conversation and conducting a useful qualitative interview.

A badly run interview can reinforce assumptions the analyst already holds. Leading questions can manufacture apparent requirements. Poor sequencing can close down useful discussion. Asking stakeholders what solution they want can produce a shopping list of features while leaving the underlying problem untouched.

A well-run qualitative interview does something different. It creates enough structure to investigate the subject properly while leaving enough freedom for the participant to tell you something you did not already know.

A practical approach is:

1. Define the research objective → 2. Identify the right participants → 3. Decide what you need to learn → 4. Create the discussion guide → 5. Prepare the interview → 6. Build rapport and context → 7. Ask open questions → 8. Probe and explore → 9. Capture evidence → 10. Analyse across interviews → 11. Validate findings → 12. Turn insight into action

The interview itself is only part of the work.

1. Start with what you need to learn

Do not begin by writing questions.

Begin with the research objective.

Suppose a retailer tells you:

“Customers don't like our online returns process.”

That is too vague to interview against effectively.

What are you trying to understand?

Perhaps customer satisfaction data shows that people who use the returns journey are significantly less satisfied than other customers. Your research objective might therefore be:

Understand how customers experience the online returns journey, where they encounter difficulty or uncertainty, and what causes them to contact Customer Service rather than completing the process independently.

That gives the interviews purpose.

Another piece of work might be internally focused:

Understand how Claims Officers currently assess applications, which information they rely upon, where delays occur and which workarounds they use when the system does not support the task.

Now you can design an interview around what you need to learn rather than collecting a random assortment of stakeholder opinions.

A useful question before starting is:

What decision should this research help us make?

If you cannot answer that, the interview objective probably needs more thought.

2. Decide whether qualitative interviews are the right technique

Interviews are particularly useful when you need depth.

They can help you explore:

• experiences;

• behaviours;

• motivations;

• frustrations;

• perceptions;

• decision-making;

• workarounds;

• exceptions;

• unmet needs;

• how people understand a problem;

• why something happens.

They are less suitable for answering questions such as:

“What percentage of customers abandon the application?”

That is a quantitative question.

Analytics may tell you that 38% of customers abandon a journey at a particular screen.

A qualitative interview can help you understand why.

Perhaps customers do not understand the terminology. Perhaps they don't have the information being requested. Perhaps they are worried about sharing certain data. Perhaps they assume they can finish the application later but cannot.

The two forms of evidence can complement each other.

Quantitative evidence can tell you what is happening and how often. Qualitative research can help you understand why it is happening and what it means to the people involved.

3. Identify the right participants

Interviewing ten people who all have the same experience can give you ten variations of the same answer.

Participant selection matters.

Suppose you are investigating problems with a mortgage application process. Useful participants might include customers who completed successfully, customers who abandoned, customers who needed additional support, operational employees processing applications and perhaps brokers or advisers who regularly help customers through the journey.

The objective determines who you need.

For internal stakeholder research, avoid interviewing only managers. A manager can explain objectives, policy and performance. Someone performing the task every day may explain the actual process, exceptions and workarounds.

For customer research, think about relevant differences between users. Depending on the problem, these might include experience level, product type, route into the service, successful versus unsuccessful outcomes, accessibility needs or frequency of use.

You are not necessarily trying to create a statistically representative sample. That is not the purpose of most qualitative research.

You are trying to expose useful differences in experience and perspective.

4. Build the discussion guide around topics, not a script

A discussion guide is one of the most useful tools for a qualitative interview.

It is also easy to misuse.

The purpose is not to create a script that must be read word-for-word from beginning to end. It is to make sure the important research areas are covered while allowing the interviewer to follow useful information when it appears.

Imagine you are investigating why customers struggle with an insurance claims process.

Your discussion guide might contain:

Introduction and context

• Explain the purpose of the conversation.

• Explain how the information will be used.

• Confirm permission for recording if applicable.

• Establish relevant background.

Recent experience

• Tell me about the last time you made a claim.

• What were you trying to do?

• How did you begin?

Journey

• Talk me through what happened.

• What happened next?

• Was anything unclear?

• Was there anything you did not expect?

Problems and workarounds

• Was there any point where you became stuck?

• What did you do?

• Did you need help from anyone?

• Did you use anything outside the service to complete the task?

Decisions and expectations

• How did you decide what to do next?

• What did you expect would happen?

• Was that what actually happened?

Outcome

• Were you able to complete what you needed to do?

• What happened afterwards?

• Is there anything you would change about the experience?

That is a guide.

If the participant suddenly says:

“I actually phoned my daughter because I didn't understand what the question meant.”

you do not respond:

“Thank you. Question seven: How satisfied were you with the application process?”

You investigate.

Why didn't they understand it? Which question? What did they think it meant? Why did they call their daughter rather than the company? What happened after that?

That unexpected answer may be more valuable than half the questions on your guide.

5. Structure the interview from broad to specific

A useful qualitative interview often begins broadly and gradually moves deeper.

Start by allowing the participant to establish context.

For example:

“Tell me about the last time you applied for a refund.”

That is generally better than immediately asking:

“Did you find the refund form confusing?”

The first allows the participant to describe their experience.

The second has already introduced the idea that the form was confusing.

A useful flow is:

CONTEXT → EXPERIENCE → BEHAVIOUR → PROBLEMS → REASONS → NEEDS → REFLECTION

For example:

Context: Tell me about the last time you used the service.

Experience: Talk me through what happened.

Behaviour: What did you do when you reached that point?

Problem: Was anything difficult or unclear?

Reason: What made that difficult?

Need: What information would have helped you there?

Reflection: If you went through the process again, what would you do differently?

This progression feels much more like a conversation than an interrogation.

6. Ask open questions

Good qualitative questions invite explanation.

Compare:

“Was the application easy to use?”

with:

“Tell me about your experience completing the application.”

The first encourages a yes/no judgement.

The second invites a story.

Useful openings include:

“Tell me about…”

“Talk me through…”

“What happened when…”

“How did you…”

“What were you expecting…”

“What did you do next?”

“How did you decide…”

“What made you…”

“Can you describe…”

Open questions do not guarantee good answers, but they give participants space to provide them.

7. Avoid leading questions

Leading questions are particularly dangerous because they can make poor research look convincing.

Suppose you ask:

“Would it be helpful if the system automatically sent you a text message?”

The participant may say yes.

You now appear to have evidence for SMS notifications.

But what have you actually learned?

Very little.

You introduced the solution and asked whether it sounded useful.

Instead, investigate the underlying experience:

“How did you know what was happening with your application?”

“Was there any point when you weren't sure what was happening?”

“What did you do when that happened?”

Perhaps the participant checked their email. Perhaps they telephoned. Perhaps they did nothing. Perhaps status information was not actually important to them.

You can explore potential solutions later if that is part of the research.

But first understand the need.

A Business Analyst should be particularly careful here because stakeholders frequently arrive with proposed solutions already in mind. Your questions should not simply manufacture evidence for them.

8. Ask about real behaviour, not imaginary behaviour

People are not always particularly good at predicting what they would do.

Consider:

“Would you use an online dashboard to track your application?”

The participant may sincerely say yes.

That does not mean they actually would.

Where possible, ask about real experiences.

“How did you check the progress of your last application?”

Perhaps they say:

“I called Customer Service three times.”

Now ask why.

What information did they need? Why wasn't the existing email enough? What prompted each call?

Past behaviour is not a perfect predictor of future behaviour either, but it gives you much stronger evidence than asking somebody to imagine themselves using a hypothetical feature.

9. Learn to probe

The first answer is often only the beginning.

Participant:

“The process was frustrating.”

A weak interviewer records:

Customer finds process frustrating.

A stronger interviewer asks:

“What made it frustrating?”

Participant:

“I kept having to go backwards.”

Now we have something.

“Can you talk me through when that happened?”

Participant:

“It asked for my policy number, but I didn't have it. I went into my email to find it, and when I returned the form had reset.”

Now we have something potentially actionable.

Useful probes include:

“Can you tell me more about that?”

“What happened next?”

“Why was that important?”

“What do you mean by ‘difficult’?”

“Can you give me an example?”

“How often does that happen?”

“What did you do when that happened?”

“How did that make a difference?”

Probing turns opinions into understanding.

10. Become comfortable with silence

Interviewers often rush to fill silence.

Ask a question, receive no immediate answer and then rephrase it, explain it or ask something else.

Wait.

The participant may simply be thinking.

A few seconds of silence can feel considerably longer to the interviewer than it does to everybody else.

Allow people time.

You may find that the answer given after five seconds of thought is much more useful than the immediate response you would have prompted.

11. Don't turn the interview into your own story

This sounds obvious, but it happens surprisingly easily.

A participant describes a problem and the interviewer says:

“Yes! I had exactly the same thing when I used it…”

The next two minutes are now about the interviewer.

Rapport matters. Showing that you understand somebody is useful.

But the interview exists to understand their experience.

If you find yourself speaking for long stretches, reset.

Ask a question and listen.

12. Follow interesting evidence even when it wasn't in the guide

Suppose you are interviewing an employee about a payment process.

They casually mention:

“Obviously, we keep our own spreadsheet as well.”

Your discussion guide contains nothing about spreadsheets.

Investigate it.

Why do they have one? What does it contain? Who updates it? Who uses it? Why isn't the main system sufficient? What happens if the spreadsheet and system disagree?

You may just have discovered an important data problem, process workaround or missing requirement.

A discussion guide prevents you forgetting important topics.

It should never prevent you discovering something unexpected.

13. Distinguish what people say from what you conclude

This is an important analytical discipline.

A participant says:

“Nobody understands the new system.”

That is not evidence that nobody understands the system.

It is evidence that this participant believes people do not understand the system.

You might investigate further.

Who struggles? What do they struggle with? Have they seen examples? Does support data show an increase in queries? Do other participants describe the same problem?

Similarly:

“Customers hate the new form.”

should not automatically become:

Finding: Customers hate the new form.

Separate:

Observation/evidence → Interpretation → Finding

That reduces the risk of turning one strong opinion into an organisational truth.

14. Capture the interview properly

Relying entirely on memory is risky.

Depending on the context and appropriate permissions, you may use notes, recordings, transcripts or a combination.

If recording, make sure the participant understands and has consented to it, and follow the organisation's privacy, security and retention requirements.

During the interview, avoid spending the entire conversation staring at your notes.

Capture enough to preserve important information while maintaining the conversation.

Useful things to record include:

• key behaviours;

• specific examples;

• problems;

• workarounds;

• decisions;

• expectations;

• contradictions;

• strong quotations where appropriate;

• questions requiring investigation;

• potential themes.

Afterwards, add anything important while the conversation is still fresh.

15. Don't analyse one interview as though it represents everybody

One interview can reveal an important issue.

It cannot necessarily tell you how widespread that issue is.

Suppose one customer tells you that they abandoned an application because the identity-checking stage felt intrusive.

That is useful evidence.

After several interviews, perhaps four participants independently describe the same concern.

Now you may have a pattern worth exploring further.

Qualitative analysis should therefore look across interviews, not simply summarise each one separately.

You might create a simple analysis table:

Theme	Evidence	Participants	Possible implication
Status uncertainty	Customers unsure what happens after submission	6 of 8	Explore clearer progress information
Missing reference number	Users leave journey to find information	4 of 8	Investigate whether number is necessary
Form reset	Information lost after leaving page	3 of 8	Investigate session behaviour
Terminology	Customers misunderstand “beneficiary”	5 of 8	Review language/content

The numbers here are descriptive of your interviews, not population statistics.

Do not turn “six of eight interviewees” into “75% of customers” unless you have research capable of supporting that claim.

16. Look for themes, but don't erase differences

Patterns matter.

So do exceptions.

Perhaps seven customers complete the journey easily, while one customer using assistive technology encounters a major accessibility barrier.

That issue should not disappear because it was only mentioned once.

Likewise, a rare operational exception may create enormous financial or regulatory risk.

When analysing qualitative interviews, consider:

Frequency — how often did this appear?

Severity — how serious is it when it occurs?

Impact — what does it prevent or affect?

Context — does it affect a particular group or scenario?

Evidence — what supports the finding?

The most frequently mentioned issue is not automatically the most important.

17. Combine qualitative findings with other evidence

Interviews become more powerful when combined with other forms of analysis.

Suppose customers repeatedly tell you:

“I wasn't sure whether my application had been submitted.”

Analytics show that a large number of customers return to the confirmation page.

Customer Service data shows frequent calls asking whether applications were received.

Three different forms of evidence now point towards the same problem.

This is sometimes described as triangulation: using different sources or methods to build a stronger understanding.

A BA might combine interviews with:

• analytics;

• surveys;

• process maps;

• support data;

• complaints;

• observation;

• system data;

• document analysis;

• workshops.

You are building an evidence base, not collecting quotes.

18. Turn findings into insights

A list of interview comments is not yet analysis.

Suppose you have:

“I didn't know what documents I needed.”

“I had to stop and find my policy number.”

“I thought I could save it and come back.”

“I wasn't expecting to need my bank details.”

Those comments may point towards a broader insight:

Customers begin the application without understanding what information they will need, causing interruptions, abandonment and avoidable rework.

That insight is more useful because it describes the underlying pattern.

You can then ask what should change.

Perhaps customers need clearer preparation information before starting. Perhaps some information can be retrieved automatically. Perhaps the journey should support save-and-return.

Notice the order:

Evidence → Pattern → Insight → Need → Potential change

Not:

Interview → Feature request.

19. Translate insights into Business Analysis

Qualitative interviews should ultimately influence something.

That might be a process, requirement, user story, business rule, service design, prioritisation decision or further investigation.

For example:

Evidence: Several customers leave the application to find their account number and lose their progress.

Insight: Requiring information customers do not readily have creates avoidable interruption and abandonment.

Need: Customers need to complete the application without losing entered information when additional information must be retrieved.

From there, the delivery team can investigate possible solutions.

The interview has now moved from conversation to change.

20. Validate before treating findings as fact

When findings have significant consequences, test them.

You might validate through additional interviews, analytics, stakeholder workshops, usability testing, operational data or further research.

You may also take findings back to relevant stakeholders:

“Customers repeatedly described uncertainty after submitting the application. Does Customer Service see the same thing?”

Perhaps they do.

Perhaps they have 3,000 monthly calls proving it.

Or perhaps they tell you that those calls dropped dramatically after a recent change your interview participants had not experienced.

Research should reduce uncertainty.

It should not replace one set of assumptions with another.

---

A Structured Qualitative Interview Method

For practical BA work, use this:

Stage	Key question	Typical activity	Output
1. Objective	What do we need to learn?	Define research question	Research objective
2. Participants	Who can help us understand it?	Participant selection	Interview sample
3. Topics	What areas must we explore?	Research planning	Topic areas
4. Guide	How will we structure the conversation?	Discussion-guide design	Interview guide
5. Prepare	What do we already know?	Review evidence/context	Interview preparation
6. Explore	What happened?	Open qualitative questions	Experiences/behaviours
7. Probe	Why does it happen?	Follow-up questioning	Deeper evidence
8. Capture	What did we learn?	Notes/recording	Interview evidence
9. Analyse	What patterns exist?	Thematic analysis	Themes/findings
10. Triangulate	What else supports this?	Compare other evidence	Stronger findings
11. Interpret	What does it mean?	Insight generation	Needs/insights
12. Act	What should happen because of it?	Requirements/change analysis	Actions/change needs

In shorthand:

OBJECTIVE → PARTICIPANTS → GUIDE → ASK → LISTEN → PROBE → CAPTURE → ANALYSE → VALIDATE → ACT

That is considerably more useful than walking into an interview with twenty questions and hoping something interesting happens.

A Practical Discussion Guide Template

A simple BA discussion guide can follow this structure.

1. Introduction

Explain who you are, why the research is happening, what the conversation will cover and how information will be used. Deal with consent or recording requirements where appropriate.

2. Background

Establish only the context needed to understand the participant's experience.

“Tell me a little about how you normally handle customer applications.”

3. Recent real experience

Move towards something concrete.

“Tell me about the last application you processed.”

4. Journey or behaviour

Walk through what happened.

“What did you do first?”

“What happened next?”

5. Problems and exceptions

Explore friction.

“Was there anything that made the task difficult?”

“What happens when information is missing?”

6. Workarounds

Find out what people do when the intended process fails.

“Do you use anything outside the main system?”

“What do you do when that doesn't work?”

7. Needs and expectations

Understand what is missing without immediately prescribing features.

“What information would help you make that decision?”

8. Reflection

Give the participant room to raise something you missed.

“If you could change one part of this process, what would it be?”

“Is there anything important that I haven't asked about?”

That final question is worth asking.

Occasionally the answer will change your entire understanding of the problem.

A Worked Qualitative Interview Example

Imagine an organisation wants to reduce calls to Customer Service about online mortgage applications.

Analytics show that customers frequently leave the journey after the document-upload stage.

The project initially assumes:

Customers find uploading documents difficult.

That is a hypothesis.

The BA conducts interviews with customers who recently used the journey.

Instead of asking:

“Why was the document upload difficult?”

the discussion begins more broadly:

“Talk me through what happened when you applied.”

Several participants explain that uploading itself was straightforward.

The problem occurred earlier.

They did not know which documents would be required before starting the application. Some had to stop to find payslips. Others needed information from their partner. One customer did not know whether a bank statement downloaded from their banking app would be accepted.

Several left the application to find documents and later called Customer Service because they were unsure whether their progress had been saved.

The original assumption was:

Document upload is difficult.

The emerging insight is:

Customers begin the journey without sufficient understanding of the information and evidence they will need, creating interruptions and uncertainty.

Those lead to very different potential changes.

The interview has done its job.

It has not merely confirmed what the project already believed.

It has made the problem clearer.

Common Qualitative Interview Mistakes

Starting without a research objective. The interview produces interesting conversation but little usable evidence.

Writing a questionnaire instead of a discussion guide. The interviewer becomes obsessed with asking every question in order.

Leading the participant. Questions accidentally suggest the answer the project wants.

Asking hypothetical questions too early. Participants are asked whether they would use features that do not exist.

Accepting vague statements. “It's frustrating” is recorded without exploring why.

Talking too much. The interviewer fills the space that should belong to the participant.

Ignoring unexpected information. Valuable discoveries are missed because they were not on the guide.

Interviewing only senior stakeholders. The research captures organisational opinion rather than operational reality.

Treating one interview as representative. One person's experience becomes “what users think”.

Counting qualitative findings as though they were survey results. Small samples are turned into misleading percentages.

Jumping from comment to feature. “I want notifications” becomes a requirement before the underlying need is understood.

Producing a research report nobody uses. Insights never influence requirements, priorities or design.

A Practical Qualitative Interview Checklist

Before starting, ask whether the research objective is clear, whether interviews are the right method and whether the participant can genuinely help you understand the problem. Make sure your discussion guide covers the important topics without becoming a rigid script, and remove questions that unnecessarily suggest an answer.

During the interview, start broadly, ask about real experiences, use open questions and probe vague answers. Listen for behaviours, workarounds, contradictions, expectations and exceptions. Give people time to think and follow unexpected evidence when it appears.

Afterwards, separate what the participant actually said from your interpretation. Analyse across interviews, look for both patterns and important differences, compare qualitative findings with other evidence where possible and turn the resulting insight into something the organisation can act upon.

Most importantly, ask:

What do we understand now that we did not understand before the interviews?

If the answer is nothing, either you already understood the problem extremely well or the research did not go deeply enough.

The Discussion Guide Is a Guide, Not the Interview

The best qualitative interviews have structure without feeling heavily structured.

The interviewer knows what they need to learn and has prepared the areas they need to explore, but they are not desperately trying to reach question 14 before the hour finishes.

They listen.

They notice when somebody says something unexpected.

They ask why.

They ask for examples.

They challenge assumptions without challenging the person.

And sometimes they abandon three carefully prepared questions because the participant has just revealed something considerably more important.

For Business Analysts, that is particularly valuable. We spend much of our working lives trying to understand situations that initially arrive as vague problems, confident assumptions and pre-selected solutions.

Qualitative interviews give us a disciplined way of getting underneath them.

The discussion guide provides the structure.

The quality of the analysis comes from knowing when to look beyond it.

Developing Your Qualitative Interview Skills

It is easy to learn a list of interview techniques. It is harder to recognise that your question is leading, resist filling an uncomfortable silence, notice the importance of an apparently casual comment and ask the follow-up question that exposes the real problem.

That comes with practice.

Elisto's Business Analyst training focuses on applying techniques such as stakeholder interviews and requirements elicitation to realistic Business Analysis situations, where people rarely explain their needs perfectly and the first answer is not always the useful one.

The Knowledge Hub can give you the structured approach.

The deeper capability comes from learning how to sit opposite another person, ask good questions, listen properly and leave the conversation understanding the problem better than you did when you entered it.