Walking through the traditional QDA workflow
A traditional QDA workflow usually begins before any analysis happens. The researcher creates a project, decides how the case structure should work, and brings source material into the tool. Audio is imported, transcripts are attached or generated, notes are organized, and a working codebook is either created from the research design or allowed to emerge during reading. This setup gives the study a stable place for documents, cases, memos, code definitions, and exports.
From there, the audio has to become text. Depending on the team and the product, that may mean an integrated transcription service, an external service, or a researcher listening and typing by hand. The choice can be shaped by consent language, budget, language quality, and the sensitivity of the material. In a careful study, the transcript still needs review. Names, ambiguous words, inaudible phrases, and overlapping speech have to be corrected or at least marked before the transcript becomes a dependable base for coding.
The central gesture of the manual workflow is familiar: read a sentence or passage, drag across the relevant words, highlight the span, right-click or use a coding panel, assign the code, and keep the codebook coherent as the material accumulates. Codes may be organized as a tree, with broad categories above more specific labels. The researcher may also write memos, compare coded passages, and revisit earlier documents as definitions sharpen. Careful researchers need that interpretive practice to remain visible.
The hard part is that codebook iteration creates rework. When a code is merged, split, renamed, or narrowed, the team often has to revisit already coded material to see whether earlier choices still hold. A theme that looked useful early in the study may become too broad once more interviews arrive. A code that seemed separate may turn out to be a subcase of another concept. Traditional tools provide ways to organize that work, but the researcher still carries much of the burden of finding every affected passage and deciding what should change.
Recent versions of the major QDA suites have added AI assistance. NVivo has autocode, ATLAS.ti has AI coding, and MAXQDA has AI Assist. Those additions matter, and they should be described fairly. They can accelerate parts of the work and may fit well inside teams that already rely on those products. The distinction is architectural rather than moral: these are assistive features bolted onto a manual-first, desktop-first workflow. The main path through the project is still organized around human line-by-line operation, with AI speeding selected moments rather than serving as the design starting point for the whole workflow.
Synthesis follows the same pattern. Researchers write memos, compare coded material, use matrices or maps, and gradually form themes that can survive scrutiny. The export step then turns that interpretive work into reports, tables, quoted excerpts, or materials for a paper or client deliverable. The rigor can be real while the record remains scattered across actions, notes, exports, and memory.
Walking through the OpenVerbatim workflow
OpenVerbatim begins with the project brief. The researcher creates a project, names the research question, and records the methodology that should guide the analysis. That context gives the system a starting frame for transcript handling, coding suggestions, and later theme work. The researcher is still responsible for interpretation, while the declared intent makes suggestions easier to inspect against the study's purpose.
After audio upload, preview transcript text begins to scroll as the pipeline processes the material, and coding suggestions can emerge while the transcript is still becoming reviewable. The researcher can start inspecting partial output before every downstream step has finished. In our internal end-to-end test, five hour-long interviews produced a reviewable first-pass codebook and draft themes in under ten minutes of pipeline time. [NEEDS-HUMAN-VERIFICATION] Treat that as an internal exercise that shows workflow shape, not as a universal promise.
Each review unit carries a verbatim quote, a reason for the proposed code, a confidence signal, and a way to return to the corresponding audio. The reviewer can move through the queue with keyboard actions: A to accept, E to edit, and R to reject. A suggestion that looks plausible can be checked against the raw recording before it becomes part of the confirmed evidence base. A suggestion that is too broad can be edited without losing the history of what was proposed.
The autonomy dial changes how much of that queue requires direct human attention. In review mode, every suggestion is inspected manually, which is closest to a traditional workflow with better preparation. In cruise mode, low-confidence suggestions and newly appearing codes are routed into an exception queue while routine suggestions can be confirmed according to project policy. In full-auto mode, the system can proceed with far less manual interruption, which may be appropriate for exploratory or lower-risk work. Autonomy stays visible as a policy choice.
Codebook iteration is also designed as a stateful process. When a code changes, the system can keep that decision attached to the affected evidence and route uncertain material back for attention. Theme clustering works the same way. AI can propose groups, names, and draft themes, but the researcher decides whether those groupings are analytically defensible. Ask-your-data then operates over reviewed material and returns answers with citations and timestamps, so a generated response is not separated from the passages that support it.
The audit model is append-only. Accepting, editing, rejecting, routing, clustering, and confirming leave a trail. That matters when a final report has to be defended. A conclusion stays connected to the original words, the audio moment, the suggested interpretation, and the human or policy decision that allowed it to become part of the final record.
What it feels like
From the researcher's chair, the difference is practical. You upload the audio, step away to make coffee, and come back to the beginning of a working review queue rather than a blank project waiting for manual setup. The transcript is not perfect, and the codes are not treated as final. But the material has started to organize itself into units you can inspect.
The review rhythm feels closer to clearing an inbox than building every link by hand. J and K move through the queue. A accepts a suggestion that fits the evidence. E opens a correction when the wording is close but not right. R rejects the item when the passage does not support the label. The researcher is not passively watching automation. The researcher is making decisions at the point where judgment matters.
When a suggestion feels uncertain, the source is close. You can play the original audio segment, hear the participant's tone, and decide whether the transcript and proposed code capture what was meant. That small loop changes the texture of review. The evidence becomes a path back to the moment where the claim begins.
Export feels different for the same reason. A final theme can be traced back to the passages that support it, and each passage can be traced back to who or what confirmed it and when that state changed. The team can follow the chain from conclusion back to reviewed evidence instead of relying on a polished summary alone.