Analytic Memos in Qualitative Research: What to Write and When

An analytic memo is a short, informal note a researcher writes during qualitative analysis to capture what they are starting to think about the data: what a code means, how two themes connect, a hunch that needs checking, a doubt about their own reading. Memos are written for yourself, not for stakeholders. They sit between your raw data and your final findings, and they are where interpretation actually happens. Write one after every interview and whenever an idea strikes during coding, keep each to a few paragraphs, date them, and reread them before you write your report.

This guide covers what analytic memos are, the main types, what to write in one, when to write them, an example, how memos help you judge when you have enough data, common mistakes and how Koji fits in.

What an analytic memo is (and isn't)

Analytic memos come from grounded theory, where Barney Glaser and Anselm Strauss treated memo writing as a core part of building theory from data. Since then, the practice has spread to almost every kind of qualitative analysis, including the thematic analysis most product and UX teams use. Johnny Saldaña gives memo writing its own chapter in The Coding Manual for Qualitative Researchers, alongside coding itself, because the two happen together.

An analytic memo is:

• Thinking on paper. You're working out what you believe the data says, not reporting it.
• Informal. Bullet points, questions, half-formed ideas and crossings-out are all fine.
• Dated and linked. Each memo records when you wrote it and which interviews, codes or quotes it refers to.

It isn't:

• A summary. "P4 said onboarding was confusing" is a note. "Three people who called onboarding confusing were all admins setting up for a team, which suggests the problem is the team setup step, not onboarding in general" is a memo.
• A finding. Memos can be wrong. Many of the most useful ones are later proved wrong by the next five interviews.
• Field notes. Field notes record what happened. Memos record what you think it means.

Types of analytic memo

Grounded theory texts commonly separate memos about codes, memos about emerging theory, and operational memos about what to do next. For everyday product research, five kinds cover almost everything.

1. Interview memo. Written straight after a session. What stood out, what surprised you, what you want to ask the next person. See the interview snapshot for a structured version.
2. Code memo. What a code means, where its edges are, and an example quote that fits and one that almost fits. These become your codebook.
3. Pattern memo. How codes or themes relate. "Every participant who mentioned the approval chain also mentioned their manager's travel schedule. Is the bottleneck the tool or the approver's availability?"
4. Reflexive memo. Your own position. What you expected, what you were hoping to hear, where you noticed yourself reacting. This is the memo most teams skip and the one that protects most against confirmation bias.
5. Method memo. Decisions about the study itself: changing a question that isn't working, adding a new kind of participant, dropping a topic. These make your process traceable later.

What to write in an analytic memo

Memos have no fixed format, which is part of what makes them hard to start. A few prompts help.

• What surprised me in this interview or this batch?
• What does this code actually mean, and what doesn't belong in it?
• Which participants does this apply to, and who is the exception?
• How does this connect to something I saw earlier?
• What did I expect to hear, and did I hear it because it was there?
• What would prove my current idea wrong?
• What should I ask or look for next?

You don't need to answer them all. Two or three honest answers are a memo.

An example

Memo, 14 March: "workaround" code

Started coding "workaround" as anything participants do outside the tool. After interviews 6 to 9 that's too broad. Two different things are going on: people who export to a spreadsheet because they don't trust the numbers (P6, P8), and people who export because a colleague without access needs to see them (P7, P9). Same action, different reason. Splitting into "workaround: trust" and "workaround: access".

Check: does anyone in 1 to 5 fit either? I think P2 is access. If the access group keeps growing, that's a sharing problem, not a data quality problem.

Reflexive note: I came in assuming exports meant distrust because that's what sales told us. Watch for that.

That memo changed the codebook, flagged a re-check of earlier interviews, raised a hypothesis and named a bias. It took five minutes.

When to write memos

Straight after each interview. Memory fades fast, and the impressions you have in the first hour are the ones you can't rebuild from a transcript.

Photo by Jodie Cook on Unsplash

Whenever an idea interrupts your coding. Stop and write it down, even in two lines. Ideas that wait for a convenient moment are usually lost.

At the end of each batch. After every four or five interviews, write a pattern memo: what's holding up, what's changing, what's missing.

Before you write findings. Reread every memo in date order. You'll see how your thinking moved, which early ideas survived and which didn't. That reading is often where the real story of the study becomes clear.

Using memos to judge when you have enough data

Memos are also one of the best tools for deciding when to stop interviewing, because they show you when new interviews stop changing your thinking.

The research on saturation gives a sense of scale. In a well-known study by Greg Guest, Arwen Bunce and Laura Johnson (2006), which analysed 60 in-depth interviews, about 73% of the codes eventually found had appeared within the first six interviews and about 92% within the first twelve. Monique Hennink, Bonnie Kaiser and Vincent Marconi (2017) went further and separated two kinds of saturation. Across 25 interviews, they reached code saturation, where the range of issues had been identified, by nine interviews. But they needed 16 to 24 interviews to reach meaning saturation, where they understood those issues in depth. In their words, code saturation may show when researchers have "heard it all", but meaning saturation is needed to "understand it all."

That gap is exactly what memos track. Your codebook might stop growing around interview nine. Your pattern memos will keep changing until you understand why things happen and for whom. When a new batch of interviews produces memos that only confirm what earlier memos said, you're close. For more, see data saturation and how many interviews are enough.

Keeping memos useful

• Keep them in one place. A single document or folder per study, with memos in date order, beats notes scattered across tools.
• Title them by idea, not by date alone. "Workaround: trust vs access" is findable in a month; "Notes 14 March" isn't.
• Link to evidence. Name the participant and paste the quote, so you can check the memo against the data later.
• Share selectively. Memos are private thinking, but a pattern memo is a good thing to read aloud at a synthesis session. Others will spot what you missed.
• Let memos feed the codebook. When a code memo settles a definition, update the codebook so everyone codes the same way.

Common mistakes

• Only summarising. If a memo just restates what participants said, it adds nothing to the transcript. Ask "so what?" at the end of each one.
• Waiting until all interviews are done. By then, early impressions are gone and you have no record of how your thinking changed.
• Writing for an audience. Polished memos are slow to write and tend to hide uncertainty. Write the way you'd talk to yourself.
• Never rereading them. Memos earn their keep when you read them back. Schedule time for it before synthesis.
• Skipping the reflexive ones. If you never write down what you expected, you can't tell when it shaped what you found. See reflexive thematic analysis.

How Koji helps

Koji runs AI-moderated interviews and analyses each one as it comes in. It won't write your memos for you, because memos are your own thinking. What it does is give you the raw material for them much faster, so the time goes into interpreting rather than transcribing and sorting.

A first read of every interview, ready when you are. As each interview finishes, Koji analyses it: key findings, pain points, sentiment and a quality rating, with the full transcript beside it. That's a solid starting point for an interview memo while the conversation is still fresh, even when you didn't sit in.

Codes with quotes attached. For open-ended questions, Koji tags themes in each answer, either with a descriptive label or in the participant's own framing, and ties each one to the exact words behind it. It then groups similar themes across interviews for each question. Your code memos can start from that list and argue with it: where the grouping is too broad, where two themes are really one.

Evidence one click away. In the report, clicking a finding or a number opens the participants and quotes behind it beside the report. When a pattern memo says "only admins mention this", you can check it in seconds.

Watch your thinking change. Reports are versioned, and the history shows each version with its date and interview count. Comparing versions as interviews come in is a quick way to see whether new data is still changing the picture, which is the same question your pattern memos ask.

Compared with coding transcripts by hand in a spreadsheet, you skip the hours of transcription and first-pass tagging. Compared with tools that only give you a summary, you keep every quote and every participant, so your memos can stay grounded in the data rather than in the summary.

Related Resources

• How to code qualitative data
• Grounded theory in qualitative research
• Building a qualitative research codebook
• Reflexive thematic analysis
• Data saturation in qualitative research
• Structured questions guide

Sources

• Glaser, B. G., & Strauss, A. L. (1967). The Discovery of Grounded Theory. Aldine.
• Guest, G., Bunce, A., & Johnson, L. (2006). How many interviews are enough? An experiment with data saturation and variability. Field Methods, 18(1), 59-82.
• Hennink, M. M., Kaiser, B. N., & Marconi, V. C. (2017). Code saturation versus meaning saturation: How many interviews are enough? Qualitative Health Research, 27(4), 591-608.
• Saldaña, J. The Coding Manual for Qualitative Researchers. SAGE.