What Is In Vivo Coding? A 2026 Guide
Qualitati Research Team · 2026-09-12 · 10 min read
Last updated: September 12, 2026
Short answer
In vivo coding is a qualitative coding method that labels data using the participant's own words, placed in quotation marks, rather than the researcher's terminology. It is a first-cycle coding technique described by Johnny Saldaña, used to keep participant voice intact before any abstraction happens. It is especially useful for early analysis, jargon-rich domains, and studies where whose language wins actually matters.
Key takeaways
- In vivo coding means coding in the words of the participant —
"it just fights me", not Usability frustration.
- It is a first-cycle method, not a whole analysis. Saldaña positions it as an early pass that later feeds a second cycle of higher-order coding.
- Its main value is anti-drift. Because the code is the participant's phrase, you cannot quietly substitute your own framing in week one and then forget you did.
- AI coding tools are structurally biased against it. Language models paraphrase by default; paraphrase is the one thing in vivo coding forbids.
- 2026 evidence is mixed on interpretive depth. A CHI 2026 study of an on-device LLM coding tool found researchers trusted it for surface-level extraction but not for implicit, distributed meaning.
- Use the In Vivo Fidelity Checklist and the coding-method selection table below before you decide whether to run this method manually or with AI assistance.
What is in vivo coding?
In vivo coding is a qualitative data analysis method in which each code is a word or short phrase taken verbatim from the participant's own speech or writing. The Latin sense of in vivo — "in that which is alive" — is the point: the code stays inside the living language of the data instead of being translated into academic or product vocabulary.
The method is one of the best-known first-cycle coding techniques in Saldaña's The Coding Manual for Qualitative Researchers, and it appears across the methods literature under names including verbatim coding, literal coding, and indigenous-term coding (see the Wiley International Encyclopedia of Communication Research Methods entry on In Vivo Coding). Convention is to wrap in vivo codes in quotation marks so that anyone reading the codebook can see at a glance which labels came from participants and which came from the analyst.
A worked example
Take one line from a hypothetical onboarding interview:
"I didn't finish setup. I kept waiting for it to tell me what it wanted and it never did, so I just closed the tab and went back to the spreadsheet."
| Coding method | Code applied | What it preserves | What it loses |
|---|
| In vivo | "waiting for it to tell me what it wanted" | The participant's mental model: they expected to be led | Comparability across participants who said it differently |
| Descriptive | Setup abandonment | Where in the journey the event sits | Why it happened, in their terms |
| Process | Reverting to prior tool | The action and its direction | The affective texture of the giving-up |
| Concept / analytic | Guidance expectation violation | A construct you can theorize with | All original wording; the abstraction is now yours |
Note that the concept code is not wrong. It is simply a claim — and in vivo coding's discipline is that you make that claim in cycle two, on the record, rather than in cycle one by accident.
Who this is for
UX researchers and product managers running discovery interviews; market and customer-insights teams working in categories with strong in-group vocabulary (clinicians, developers, traders, gamers, teachers); academic qualitative researchers whose method section has to survive review; and ResearchOps leads defining how a team codes so that two analysts produce comparable codebooks.
When in vivo coding earns its cost
In vivo coding is slower per transcript than descriptive coding and produces a messier, larger initial code list. That trade is worth making in four situations.
- Early, exploratory studies where imposing your categories too soon would foreclose the finding. If you already know the categories, you are doing deductive coding — see inductive vs deductive coding.
- Jargon-dense or subcultural domains. When a participant says "shadow IT" or "the dirty list" or "vibe check", the term itself is data. Flattening it into
Informal process destroys the signal.
- Studies about language. Naming research, positioning, messaging tests, support-ticket taxonomies, and anything that will ship as copy should code in the customer's words — because the deliverable is words.
- Power-asymmetric or sensitive research. When participants are being described by an institution that has historically named them badly, keeping their terms is an ethical position and not only a methodological one. It pairs naturally with reflexivity practice.
When not to use this approach
Skip it, or demote it to a spot check, when you are coding at scale against an established framework; when your transcripts are machine translations (the "verbatim" wording is already the translator's, not the participant's — see whether to translate interviews before AI analysis); when the research question is frequency-shaped rather than meaning-shaped; or when the transcript quality is poor enough that verbatim phrases are unreliable artifacts of the ASR rather than of the speaker.
Choosing a first-cycle coding method
| If your goal is… | Use | Why |
|---|
| Hearing how participants themselves frame the problem | In vivo | Codes cannot outrun the data |
| Mapping what happened, in order | Descriptive / process coding | Comparable across cases |
| Testing a pre-existing framework | Deductive / a priori codebook | Coverage and reliability |
| Building theory from the ground up | In vivo → then focused / axial coding | Grounded-theory sequence; see thematic analysis vs grounded theory |
| Counting themes across hundreds of responses | Content analysis or LLM-assisted coding | In vivo does not aggregate; see LLMs vs ML for open-ended coding |
In vivo coding meets AI: the paraphrase problem
Here is the tension worth naming plainly. Large language models are trained to produce fluent, normalized, abstracted language. In vivo coding requires the opposite: unpolished, non-normalized, participant-owned language. Ask a general-purpose model to "code this transcript" and it will overwhelmingly return analyst-voice concept codes — Onboarding friction, Trust barrier, Feature discoverability — because that is what coding looks like in its training data. The model is not malfunctioning. It is answering a different question than the one an in vivo pass asks.
The 2026 empirical picture supports being specific about what you delegate. In a CHI 2026 study of ChatQDA, an on-device open-source LLM coding tool, researchers reported what the authors call conditional trust: they valued the system for explicit content extraction but doubted it on deeper interpretation, observing that the open-source models "often only identify surface-level, direct statements that are close together in the conversation" and could not reliably connect meaning across separated excerpts. That is a small study — four participants, one 5-page transcript each — so treat it as a signal about failure modes, not an effect size.
Read against in vivo coding, that limitation is unusually convenient. Surface-level, locally-grounded extraction is exactly the shape of the in vivo task. Finding the phrase a participant actually used, anchored to its line in the transcript, is a retrieval-flavored job. Deciding that three different phrases are one construct is an interpretive job, and it is the one the same study suggests you should keep.
Broader work points the same direction: a 2025 Sociological Methods & Research study on qualitative coding with generative LLMs found models can approach supervised-ML performance at matching hand-coded output, while the QualAnalyzer work argues the practical requirement is process auditability — every code traceable to the span that produced it. For in vivo coding, span-level traceability is not a nice-to-have; it is the method's definition of correctness.
A prompt pattern that actually yields in vivo codes
If you do use a model for a first in vivo pass, constrain it against its defaults:
For each meaningful segment, return: (1) the code as an exact verbatim span copied from the transcript, 2–8 words, no paraphrase, no synonyms, no reordering; (2) the line or timestamp it came from; (3) the speaker. Do not create categories, themes, or analytic labels. If no span in the segment carries the meaning on its own, return NO_VERBATIM_SPAN rather than inventing a label. Preserve the participant's grammar, slang, hedges, and profanity exactly as spoken.
The NO_VERBATIM_SPAN escape hatch matters. Without it, a model asked for verbatim codes will fabricate near-verbatim ones, which is the worst outcome available — a quote-shaped string that is not a quote. That is the same failure class covered in our piece on hallucinated quotes in qualitative analysis.
The In Vivo Fidelity Checklist
An original Qualitati asset. Run it over any in vivo pass — human or AI-assisted — before the codebook goes to a second cycle. Score one point each; 8+ is defensible, 5–7 needs a repair pass, under 5 is analyst-voice coding wearing quotation marks.
- Verbatim check. Every code string appears character-for-character in the transcript. Spot-check 10% with a literal text search, not by eye.
- Provenance check. Every code carries transcript ID, speaker, and line or timestamp.
- Speaker check. No code is drawn from the interviewer's or moderator's turn. This is the most common silent error, and it is worse with AI moderation, where the moderator's phrasing is fluent and quotable.
- Register check. Codes retain hedges, repair, slang, and disfluency where those carry meaning. A corpus of grammatically clean codes is a corpus of edited codes.
- Abstraction check. No code is a noun phrase that no participant would say out loud.
"it just fights me" passes; "usability friction" does not, even in quotes.
- Coverage check. Segments with no codable verbatim span are marked as such rather than force-fitted.
- Distribution check. Codes are not concentrated in the first third of each transcript — a signature of both fatigued human coders and truncated model context.
- Duplication check. Near-identical phrases are kept distinct at this stage. Merging is a cycle-two decision, made explicitly.
- Translation check. For non-source-language data, codes are stored in the original language with a gloss, not replaced by the translation.
- Second-reader check. A second person can re-derive at least 80% of the codes from the marked spans. If they cannot, the spans are doing less work than you think. On reliability generally, see intercoder reliability in AI qualitative coding.
Where Qualitati fits
Qualitati is an AI user research platform for product, UX, and customer insights teams. Two parts of it touch in vivo coding directly.
- QDA Workspace supports AI-assisted inductive and deductive coding, codebook generation, and theme visualization — which is where a first-cycle verbatim pass lives and where you promote it into higher-order codes in a second cycle you control.
- ThemeLens runs a map-reduce thematic analysis across up to 100 transcripts at once, mapping codes to research questions and synthesizing themes with participant-anchored quotes. The participant-anchored part is the relevant discipline: themes that keep their quotes attached can be audited back to the speaker.
Data collection matters too. In vivo coding is only as good as the language it has to work with, so AI-moderated interviews that probe rather than accept the first answer produce more codable verbatim material — and Active Listener mode keeps a human interviewer in the room with real-time prompts when the wording is the point. Multilingual research across 10 languages means the original-language requirement in checklist item 9 is practical rather than aspirational.
Qualitati publishes per-credit usage rates and starts free with 30 credits on signup, no credit card required.
Limitations and trade-offs
Three honest caveats.
In vivo coding does not scale, and that is partly the design. A hundred transcripts of verbatim codes is not an analysis; it is a concordance. The method's output has to be reduced by a human who is willing to own the abstraction. Teams that adopt in vivo coding and then skip cycle two end up with rich, unusable data.
Verbatim is not the same as authentic. A phrase is only the participant's if the transcript is accurate, the moderator did not supply it first, and the translation did not create it. ASR error rates are not uniform across accents — see transcription accent bias — so verbatim fidelity is unevenly distributed across your sample in a way that can quietly bias whose language survives coding.
The AI evidence base is thin and recent. The 2026 studies cited here are small-N user studies and exploratory comparisons, not benchmarks with established construct validity. Human-review note: if your method section will claim that an AI-assisted pass preserved participant voice, that claim needs your own documented verification on your own data — a citation to somebody else's four-participant study will not carry it.
FAQ
Is in vivo coding the same as quoting?
No. A quote is evidence you present; an in vivo code is a label you analyze with. The same phrase can be both, but the code has to be short enough to recur across the dataset and is attached to a span rather than to a paragraph of illustration.
How long should an in vivo code be?
Short enough to be a label, long enough to carry meaning on its own. Two to eight words is the working range. A full sentence is usually a quote that has not yet been coded.
Can I combine in vivo coding with a pre-existing codebook?
Yes, and it is a common hybrid: apply your a priori codes for coverage, and run an in vivo pass in parallel to catch what the framework has no slot for. The in vivo layer is your early warning that the codebook is out of date.
Does in vivo coding work for open-ended survey responses?
It works, with a caveat: written survey answers are already self-edited, so their language is less spontaneous than interview speech. Voice responses sit in between — richer wording, more nonresponse, as covered in our post on voice answers in surveys.
Can an LLM do in vivo coding reliably?
It can do the extraction step usefully under tight constraints — exact spans, line references, an explicit refusal option — and it should not be trusted to decide which distinct phrases mean the same thing. The CHI 2026 ChatQDA study found precisely that split: acceptable on surface extraction, weak on meaning distributed across a transcript.
What comes after in vivo coding?
A second cycle: pattern, focused, or axial coding that groups in vivo codes into categories, then theme development. In Saldaña's framing the first cycle is deliberately provisional; treating it as final is the method's most common misuse.
Bottom line
In vivo coding is a small, strict discipline with an outsized effect: it forces the first pass over your data to be in the participant's language, so that every later abstraction is a visible decision rather than an invisible one. That discipline becomes more valuable, not less, as AI enters the coding workflow — because a fluent model's default is to abstract immediately and never show you where the words went. Use AI for exact-span extraction with provenance. Keep the judgment about what those spans mean.
Start free with 30 credits and run a first-cycle coding pass in QDA Workspace, or view transparent pricing. If you are comparing tools, see how Qualitati sits against NVivo, ATLAS.ti, MAXQDA, and AI-native research platforms, or create an account and code a transcript today.