In Vivo Coding: How to Code Qualitative Data in Participants' Own Words

Short answer: In vivo coding is a qualitative coding method where the code is a word or short phrase taken straight from what the participant said, usually written in quotation marks. A customer who says their old tool "felt like doing taxes" gets the code "felt like doing taxes", not "usability issues". Use it when the way people talk about a problem matters as much as the problem itself: early discovery work, research on language and identity, positioning and copy, and any study where you don't yet know the right categories. Pair it with descriptive or conceptual codes later, because a pile of vivid quotes is not yet an analysis.

This guide covers what in vivo coding is, where it comes from, how to do it step by step, how it compares with other first cycle methods, the mistakes that make it fail, and how Koji keeps participants' exact words attached to every finding.

What in vivo coding is

"In vivo" is Latin for "in the living". In qualitative research it means the label for a piece of data comes from the data itself. The term is most closely tied to grounded theory and to Anselm Strauss, who argued that an interviewee's own term often expresses a meaning better than any word an analyst could supply (Strauss, 1987).

Johnny Saldaña's The Coding Manual for Qualitative Researchers, the standard reference on coding methods, places in vivo coding among the "elemental" first cycle methods alongside structural, descriptive, process and initial coding. His working definition of any code is a useful starting point:

"A code in qualitative inquiry is most often a word or short phrase that symbolically assigns a summative, salient, essence-capturing, and/or evocative attribute for a portion of language-based or visual data." (Johnny Saldaña, The Coding Manual for Qualitative Researchers)

In vivo coding simply insists that the word or phrase is the participant's. Saldaña's convention for telling them apart is quotation marks: in his worked examples, a code "taken directly from what the participant himself says" is placed in quotation marks so readers can see at a glance that it is an in vivo code and not the analyst's label.

Why participants' words matter

The case for in vivo coding is not sentimental. It rests on a well-documented gap between the words analysts choose and the words people use.

In a classic study of how people name things, George Furnas and colleagues found that two people independently chose the same term for an object with a probability below 0.20 in every domain they tested (Furnas et al., 1987). They estimated that relying on one designer's favourite word would fail 80 to 90 percent of the time in many common situations.

The same gap shows up when you code interviews. If you relabel "felt like doing taxes" as "complexity", you keep the topic and lose the feeling, the comparison and the exact phrase a prospect would type into a search box. In vivo codes protect three things analyst labels tend to lose:

• Emotion and intensity. "I was ready to throw my laptop" and "mild frustration" are not the same finding.
• Insider vocabulary. Teams, professions and communities have their own terms. Those terms tell you who someone is and which group they belong to.
• Reusable language. Product names, onboarding copy, sales scripts and landing pages work better when they use the phrases customers already use.

When to use in vivo coding

In vivo coding works best when:

• You are early in discovery and don't want to force your own categories onto the data.
• Language is part of the research question, for example how people describe a job to be done, a condition, a role or a workaround.
• You are feeding marketing, positioning or UX writing, where the exact phrase is the deliverable.
• Participants are an underheard group and keeping their voice in the write-up matters ethically as well as analytically.
• You are doing grounded theory, where in vivo codes often become the names of core categories.

It is a weaker fit when you are testing a fixed framework (use deductive or structural coding), when you need clean counts across hundreds of short answers (descriptive codes aggregate better), or when participants answered in very short phrases with little texture.

How to do in vivo coding, step by step

1. Collect data that gives you participants' words

In vivo coding can only be as good as the language in your transcripts. Ask open questions about specific past events ("Tell me about the last time you..."), follow up on vague answers, and let people finish their thought before you move on. Closed questions and leading prompts produce your words echoed back, not theirs. Record and transcribe verbatim; summarised notes are useless for in vivo coding.

Photo by Mina Rad on Unsplash

2. Read for phrases that stand out

On a first pass, read each transcript without coding. On the second pass, highlight words and phrases that do one of these things:

• carry strong feeling ("dreading Monday reports")
• use a metaphor or comparison ("like herding cats")
• are repeated by the same person or across people
• are insider terms the participant clearly expects you to know
• sum up the point of a whole answer in a few words

3. Write the code in quotation marks

Copy the phrase exactly, including slang and grammar, and put it in quotation marks next to the passage. Keep codes short: a few words, not a full sentence. If you have to trim, trim from the edges, never the middle.

4. Keep a record of where each code came from

Note the participant and the location in the transcript for every in vivo code. You will need it when you check whether a phrase is one person's idiom or a pattern, and when stakeholders ask "who actually said that?".

5. Compare codes across interviews

After a handful of interviews, list your in vivo codes side by side. Different people often describe the same experience in different words: "drowning in tickets", "the queue never ends" and "always behind" may belong together. Group them, but keep each original phrase visible under the group.

6. Move to second cycle coding

Group related in vivo codes under a broader category, often named with the strongest participant phrase. This is where in vivo coding hands over to pattern coding, focused coding or theme development. See first and second cycle coding for the full progression.

A worked example

A product team interviews operations managers about month-end reporting. One participant says:

"Honestly the last three days of the month I'm just a human copy-paste machine. I pull from four systems, fix the dates by hand, and pray nobody asks for a breakdown by region."

The descriptive codes would let you count how many people mention fragmented data. The in vivo codes tell you how it feels, and "human copy-paste machine" might end up as the name of the core category, or on the product's landing page.

How much data do you need?

Saturation research gives a rough guide. In a study of 60 interviews, Guest, Bunce and Johnson (2006) found that 92% of the codes developed for one country's 30 transcripts had already appeared within the first twelve interviews. Hennink, Kaiser and Marconi (2017) found that in their study code saturation came at nine interviews, but 16 to 24 interviews were needed to reach "meaning saturation", a rich understanding of each issue.

In vivo coding sits on the meaning side of that line. You will hear the main topics early. The phrases that explain what those topics mean to people keep arriving for longer, which is a good reason not to stop at the first point where nothing new seems to come up. For more detail, read how many interviews are enough.

In vivo coding compared with other first cycle methods

Most studies combine two or three of these. A common pairing is in vivo plus descriptive: the descriptive codes give you the map, the in vivo codes give you the quotes that bring each region of the map to life.

Common mistakes

• Coding everything in vivo. If every line gets a quote as a code, you have highlighted the transcript, not analysed it. Be selective.
• Paraphrasing and calling it in vivo. "Felt overwhelmed" is not in vivo if the participant said "drowning". Copy exactly.
• Losing the source. An in vivo code without a participant and a location can't be checked or reused.
• Stopping at first cycle. In vivo codes are raw material. Without a second cycle you report a collection of quotes, not findings.
• Cherry-picking the colourful. Memorable phrases are tempting. Check that the vivid quote represents a pattern and isn't one person's outlier.

"Any researcher who wishes to become proficient at doing qualitative analysis must learn to code well and easily." (Anselm Strauss, Qualitative Analysis for Social Scientists, 1987)

How Koji helps

Doing in vivo coding by hand means scheduling calls, transcribing, re-reading and copying quotes into a spreadsheet or sticky notes. Survey tools make it harder in a different way: open-text boxes often get a few words, and nobody asks a follow-up, so there is little rich language to code. Koji covers the collection and first-pass work so more of your time goes into interpretation.

• Interviews that produce quotable language. Koji runs AI-moderated interviews by text or voice. Open-ended questions get follow-up probing, so participants explain in their own words instead of stopping at "it's fine".
• Every code comes with the participant's exact words. Koji codes each answer, question by question, with short analyst-style labels, and attaches a verbatim quote from the participant to each one. Koji checks the quote against the transcript, and a label with no supporting quote is left out. Quotes stay in the participant's original language. Those attached quotes are your in vivo candidates, already linked to who said them.
• Patterns across interviews. In the report, related phrasings from different interviews are grouped into themes, with a count of how many interviews mention each. You can open the supporting quotes behind any finding and go back to the transcript, which makes step 5 above much faster.
• Notable quotes. Each report also pulls out notable direct quotes, chosen for substance over filler.
• Structured questions where you need them. Add scale, choice, ranking or yes/no questions to the same study when you also want numbers, and Koji still codes the reasons people give for their answers.

Koji's labels are conceptual, not in vivo, so treat them as a starting point. Read the attached quotes, lift the phrases that carry meaning, and use them to name your categories.

Related Resources

• How to Code Qualitative Data
• First and Second Cycle Coding
• Structured Questions Guide
• Verbatim Analysis
• Open, Axial, and Selective Coding
• Grounded Theory in Qualitative Research

FAQ

What is an example of in vivo coding? A participant says, "By Friday I'm running on fumes." An in vivo code for that passage is "running on fumes", written in quotation marks. A descriptive code for the same passage might be "end-of-week fatigue".

Why are in vivo codes put in quotation marks? Quotation marks show that the code is the participant's exact wording, not the analyst's label. Saldaña uses this convention so anyone reading the codes can tell the two apart.

Is in vivo coding inductive or deductive? Inductive. The codes come from the data rather than from a framework you bring to it, which is why the method is popular in grounded theory and early discovery research.

Can you combine in vivo coding with other methods? Yes, and you usually should. In vivo coding pairs well with descriptive, process and emotion coding in the first cycle, and its codes often become category names in second cycle methods such as pattern or focused coding.

How do I code interviews in another language in vivo? Code in the original language and add a translation next to the code. Translating first and then coding loses the exact phrase, which defeats the purpose of the method.

Sources

• Saldaña, J. The Coding Manual for Qualitative Researchers. SAGE (2nd ed. 2013; 4th ed. 2021; 5th ed. 2025).
• Strauss, A. L. (1987). Qualitative Analysis for Social Scientists. Cambridge University Press.
• Furnas, G. W., Landauer, T. K., Gomez, L. M., & Dumais, S. T. (1987). The vocabulary problem in human-system communication. Communications of the ACM, 30(11), 964–971.
• 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.