Rapid Qualitative Analysis: How to Get From Interviews to Findings in Days

Rapid qualitative analysis is a structured way to get from interview transcripts to findings in days or weeks instead of months. Rather than coding every line, analysts summarise each interview into a short template organised by topic, then lay those summaries out in a participant-by-topic matrix and read across it to find patterns. Developed by Alison Hamilton for health services research at the US Department of Veterans Affairs, it has been tested head to head against traditional in-depth analysis, and the two usually reach very similar conclusions.

If you need answers while a decision is still open, this is the method to know. This guide covers how it works, what the evidence says about its trade-offs, and how to run one, by hand or with AI interviews doing part of the work.

What is rapid qualitative analysis?

Most qualitative analysis starts with coding. You read each transcript line by line, tag passages with codes, group the codes into themes, and only then write up. It's thorough, and on a large study it can take months. For a product team choosing what to build next quarter, or a health system deciding whether to keep a pilot running, months is too slow.

Rapid qualitative analysis (sometimes called rapid analysis, RQA or the Hamilton method) skips the line-by-line coding step. Instead it relies on two tools:

• A summary template. One page per interview, divided into a small number of domains, usually one per interview question or topic. The analyst reads or listens to the interview and writes short summary points under each domain, with the odd key quote.
• A matrix. A grid with one row per participant and one column per domain. Each cell holds that participant's summary for that domain. Reading down a column shows how everyone answered one question; reading along a row keeps each person's story intact.

The structure is the point. Because every interview is summarised against the same domains, you can compare people quickly and see where answers agree, split or surprise you.

Where the method comes from

Hamilton described the approach in a 2013 VA Health Services Research and Development cyberseminar on qualitative methods in rapid turnaround health services research. It grew out of implementation science, where evaluators need to report back to clinical leaders while a programme is still running and changes are still possible.

It has since spread well beyond healthcare. Any team that runs interviews against a known set of questions and needs to act on the results soon, including UX researchers, product managers and customer success teams, can use it.

Does rapid analysis give the same answers?

This is the question everyone asks, and it has been studied directly.

• Gale et al. (2019, Implementation Science) ran a rapid analysis of interviews from an evaluation of academic detailing in the Veterans Health Administration, then analysed the same transcripts in depth, coding them against the Consolidated Framework for Implementation Research (CFIR). The findings were consistent, and the authors judged rapid analysis sufficient for the evaluation's main goals. They also noted a caveat: the framework shaped the interview guide and the summary templates, so some agreement was built in.
• Taylor et al. (2018, BMJ Open) had two separate teams analyse the same data from an NHS home birth service evaluation, one using rapid analysis and one using thematic analysis. The rapid findings overlapped with 79% of the thematic analysis findings, and the thematic findings overlapped with 63% of the rapid ones. Overlap in recommendations was lower, around 55 to 59%. The rapid approach took 100 hours against 126.5 hours for thematic analysis. The saving was modest because, although the rapid team was much faster at managing the data, it spent far longer on interpretation and write-up.
• Nevedal et al. (2021, Implementation Science) compared a rapid deductive approach, working from notes and audio rather than full transcripts, with traditional analysis using CFIR, and again found consistent results.

The honest summary: rapid analysis reliably finds the main themes, especially when the questions are well defined in advance. It's weaker at catching what you didn't think to ask about, and the time saving depends on your team as much as the method.

When to use it, and when not to

Rapid analysis fits when:

• You have a clear set of questions or topics before the interviews start.
• A decision is waiting on the results, with a date attached.
• You're evaluating something (a feature, a programme, an onboarding flow) rather than exploring an open space.
• Several people need to share the analysis work.

Reach for a fuller method when:

• The study is exploratory and you don't yet know what the domains should be. Start with thematic analysis instead.
• You're building theory or publishing work where every analytic step needs an audit trail.
• Small differences in language matter, as in discourse or narrative analysis.

Rapid analysis is close kin to framework analysis, which also uses a matrix. The main difference is that framework analysis codes and indexes the data before charting it, while rapid analysis goes straight from interview to summary.

How to run a rapid qualitative analysis, step by step

Here is the method as it's usually taught, with the practical details that make it work.

1. Write a neutral domain for each question

Go through your interview guide and give each question or topic a short, neutral label. "Reasons for cancelling" works; "Pricing complaints" doesn't, because it assumes the answer. Add a domain for anything else worth noting, and one for overall impressions. Most templates end up with somewhere between six and twelve domains.

2. Build the summary template

Put the domains into a one-page document with space under each. Add a header for the participant ID, date and anything you'll want to filter by later, such as plan, role or segment.

3. Pilot the template on a few interviews

Have two or more analysts summarise the same two or three interviews separately, then compare. You're checking that the domains catch everything important, that people agree on what goes where, and how much detail a summary needs. Adjust the template now. Changing it after twenty interviews is painful.

4. Split the interviews and summarise

Divide the remaining interviews among the team. Each analyst reads the transcript, or listens to the recording, and fills one template per interview. Keep the points short and specific, and copy across the quotes you'd want in a presentation. Meet regularly while you work to catch drift.

5. Move the summaries into a matrix

Put every template into one grid: participants as rows, domains as columns. A spreadsheet works well. Add your header fields as extra columns so you can sort by segment.

6. Read across the matrix

Now analyse. Read down each column and note where participants agree, split or surprise you. Sort by segment and look for differences. Read each row to make sure a theme isn't hiding a contradiction within one person's story. Write findings as clear statements with the number of participants behind each.

Running a rapid analysis as a team

Rapid analysis is often a team sport, which is part of why it's fast. A few habits keep it reliable:

Photo by Mad Fish Digital on Unsplash

• Agree a summary style in the pilot. Bullet points, past tense, participant's own words in quotes. Consistency makes the matrix readable.
• Hold short check-ins. Fifteen minutes twice a week to compare edge cases keeps analysts aligned.
• Note the surprises. Give unexpected material its own domain so it doesn't get squeezed into a column it doesn't fit.
• Keep the transcripts. The summaries are for speed. When a finding is contested, go back to the source.

How Koji helps with rapid analysis

Koji runs AI-moderated voice and text interviews and analyses each one as soon as it ends, which covers a large part of the rapid analysis workflow automatically.

• Your interview guide becomes your domains. Each question in your study brief is a natural domain. Koji captures every participant's answer to each question, including what they said in follow-ups, so the per-question summaries arrive already sorted.
• A summary for every interview. Each completed interview gets a short summary, key findings, grouped insights such as pain points, sentiment and quotes linked back to the transcript, which is roughly what a filled-in summary template holds.
• A matrix you can export. Export responses as a CSV with one row per participant and one column per question, the same shape as a rapid analysis matrix. CSV export is included on every plan.
• Structured questions for the countable parts. Where a domain is really a choice or a rating, ask it as one of Koji's structured questions and you get the distribution without reading anything.
• A cross-interview report. Koji's research report groups themes across participants and shows how many people back each finding, with supporting quotes you can trace.

Treat Koji's per-interview summaries the way you'd treat a colleague's template: a fast first pass that you check against the transcript when a finding matters. The value is that you start reading across the matrix on day one instead of week three.

Common mistakes

• Leading domain names. A domain called "Frustrations with onboarding" will collect frustrations and miss praise.
• Too many domains. Past about a dozen, summaries get thin and the matrix gets unreadable.
• Skipping the pilot. Most consistency problems show up in the first three interviews, if anyone looks.
• Treating summaries as data. They're a lens on the data. Quote from transcripts, not from summaries.
• Counting without context. "8 of 20 mentioned price" means little without knowing whether you asked everyone about price.

Related Resources

• Structured questions in AI interviews: turn countable domains into charted answers
• Thematic analysis guide: the fuller method for open, exploratory studies
• Framework analysis in qualitative research: the matrix method with coding and indexing
• Coding qualitative data: when line-by-line coding is worth the time
• Generating research reports: Koji's cross-interview report
• Tracing report findings to evidence: check any finding against the quotes behind it