Analysis Workflow

I used AI to analyze the data collected via interviews and surveys. This page documents exactly how, in enough detail that another researcher could evaluate, critique, or adapt the method.

The short version: after each interview session, I take notes, feed those notes along with the transcript, survey data, moderator guide, and study proposal to multiple AI systems, iterate on the drafts each one produces, then synthesize the results into a final writeup that I edit before publishing. The whole pipeline is implemented as a set of three custom skills in Claude Cowork that I invoke in sequence. End to end, a session goes from raw Google Meet recording to published, coded, narrated writeup on this site in under an hour.

That turnaround time is new. Traditional qualitative analysis at this level of rigor (de-identification, iterative thematic coding with an evolving codebook, analytical narratives with pull quotes) used to take hours per session. The AI acceleration comes from eliminating the mechanical bottlenecks (transcription cleanup, passage retrieval, draft generation) so the researcher can spend their time on the work that actually requires human judgment.

Here is what happens after every interview session, in order.

1. I take notes. Right after each session I write down what stood out: surprises, tensions, patterns that connect to other sessions, things the participant said that I want to return to. These notes are messy and personal. They're not the analysis; they're my first reaction to it.

2. I feed the notes to several AIs. I take my post-session notes and provide them to multiple AI systems (I typically use Claude, Gemini, and ChatGPT), along with the moderator guide, the study proposal, the full session transcript, the participant's pre-interview survey responses, and a codebook of tags and themes I've been iterating as I collect data. Each AI gets the same inputs.

3. I prompt each AI to draft the analysis. Each AI is asked to write a background section (who is this participant, what's their context), a key findings section (what patterns emerged), and an emerging themes section (how does this session connect to the evolving codebook). This is a form of investigator triangulation: by having multiple systems independently analyze the same data, I can see where they converge, where they diverge, and where one catches something the others missed.

4. I iterate on each AI's draft.This is where I challenge the AI. I push back on claims that aren't grounded in the transcript. I flag passages where the AI is over- interpreting or projecting. I remove what I'm euphemistically calling "hallucinatory content" :-). Some of what the AIs produce is incisive. Some of it is generic filler dressed up in analytical language. Telling the difference is the researcher's job.

5. I synthesize the drafts in Claude Cowork. I collect the iterated drafts from each AI, add them to the project I've set up in Claude Cowork, and prompt it to draft the final background, findings, and emerging themes section. Cowork has context on the full project: previous sessions, the codebook, the skill definitions, the site structure. That project-level context helps it make cross-session connections that the individual AIs can't. I push back on this draft too.

6. I edit the content. Because "human in the loop" means "I have final edit." At least to me it does. Every finding, every pull quote selection, every theme assignment, every sentence in the published writeup passes through my review. The analytical framing, the emphasis, what gets highlighted and what gets downplayed: those are editorial decisions that stay with me.

7. I publish. The final writeup goes live on this site, cross-referenced in the theme explorer and accessible from the session writeup grid on the research page.

The process described above is operationalized as three custom skills in Claude Cowork. Each skill is a structured prompt with detailed instructions that I invoke in sequence. Think of them as runbooks for an AI research assistant: they specify what inputs to read, what operations to perform, what decisions require human approval, and what outputs to produce.

Documenting these skills publicly is intentional. If you're a researcher thinking about AI-assisted qualitative analysis, the skill definitions themselves are part of the method. They're the "how" behind the "what."

Input: A raw Google Meet transcript (.docx), exported by Gemini. These files include auto-generated front matter (meeting summary, next steps) that must be stripped, real participant names that must be replaced, and messy auto-transcription artifacts that must be cleaned.

What happens: The processing skill runs a multi-step pipeline:

• Scans the transcript folder for new .docx files and identifies unprocessed sessions.
• Extracts participant metadata (name, email, session date) from the raw transcript header.
• Looks up the participant in a de-identification spreadsheet and assigns or retrieves their participant ID (P1, P2, etc.). Writes the extracted email to the spreadsheet if not already present.
• Matches the participant's email against pre-interview survey responses and joins the relevant survey data.
• Strips the Gemini front matter, locates the transcript body, and identifies the interview start and end markers.
• Cleans the transcript: merges fragmented speaker turns, strips standalone listener backchannels ("Yeah," "Mhm"), removes filler dysfluencies ("um," "uh"), fixes obvious transcription errors, and flags unclear passages for human review.
• De-identifies the transcript by replacing all occurrences of the participant's real name with their ID. Flags employer names, other people's names, and potentially identifying details for a redaction decision by the researcher.
• Assembles the output as a clean MDX file with YAML frontmatter, survey responses formatted as a table, and the cleaned transcript with speaker labels and timestamps.

Output: A processed MDX file (e.g., P3-04-15-2026.mdx) ready for coding.

What the AI does vs. what I do:AI handles all the mechanical work: parsing, matching, cleaning, formatting. I review the de-identification decisions, resolve flagged passages, and confirm the transcript is accurate before moving to coding. The skill's cardinal rule is "DO NOT GUESS. DO NOT HALLUCINATE." When the AI is uncertain about a transcription or a de-identification decision, it stops and asks.

Input: A processed transcript MDX file and the project codebook (codebook.yaml).

What happens: The coding skill is interactive and collaborative. It runs in three layers:

Layer 1: Session overview.AI reads the full transcript and presents a 3-4 sentence summary of the session's key patterns, tensions, and distinctive contributions. This orients me to what I'm looking at before diving into codes.

Layer 2: Theme proposals.AI reads the current codebook and proposes themes one at a time. For each proposal, it states the theme and its codebook definition, presents 2-3 supporting passages from the transcript, and explains why the theme applies and how it connects to (or diverges from) previous sessions. I can approve, modify, reject, merge, or split each proposal. When AI proposes a new theme not yet in the codebook, it provides a suggested label, definition, and category, and explains why existing codes don't cover the pattern. New themes enter the codebook as "provisional" until I promote them to "active."

Layer 3: Quote selection and annotation. After all themes are approved, we go through each one again to identify the strongest pull quotes (for the published writeup and the theme explorer) and broader supporting passages (which get <ThemeAnnotation> markers in the MDX). Every proposed annotation is presented for my approval.

Output: An annotated MDX file with theme annotations embedded in the transcript, an updated codebook, and a coding worksheet that captures the session overview, approved themes, pull quotes, and analytical notes.

What the AI does vs. what I do:AI proposes themes, finds supporting passages, and suggests codebook updates. I make every coding decision: whether a theme applies, what it means, how to define it, and which quotes best represent it. This is the stage where human interpretive judgment matters most, and it's fully under my control.

Input: The coded transcript MDX, the coding worksheet, and the codebook.

What happens: The publishing skill generates the analytical narrative and assembles the final session page for the site. AI drafts three sections grounded in the transcript data:

• Background:Who is this participant, what's their professional context, what's distinctive about their relationship with AI. Drawn from the survey responses and the opening minutes of the interview.
• Key Findings:3-5 substantive patterns from this session, each supported by a pull quote. These are the session's contributions to the research.
• Emerging Themes: A summary table mapping themes to codebook definitions and pull quotes, followed by elaboration on each theme with additional supporting passages wrapped in <ThemeAnnotation> markers so they remain parseable for the theme explorer.

The final MDX file combines the analytical narrative, the survey data table, and the full annotated transcript into a single publishable document. This gets copied to the site's content directory and is immediately available on the research page.

Output: A published session page on this site, accessible from the session writeup grid and cross-referenced in the theme explorer.

What the AI does vs. what I do:AI drafts the narrative sections. I edit the drafts before they go live. The writing register is analytical, not promotional. Participants' own words carry the weight through direct quotes. The analytical framing, the emphasis, what gets highlighted and what gets downplayed: those are editorial decisions that stay with me.

The codebook is a YAML file that tracks every theme in the project. Each entry has a label, description, category, status (active, provisional, or retired), and a list of sessions where it appears. The codebook grows and refines as sessions accumulate.

At any point during coding I can request a full codebook listing, drill into a specific theme's history across sessions, merge themes that have converged, split themes that are covering too much ground, or retire themes that didn't hold up. The codebook is the backbone of the theme explorer on the research page.

One part of this workflow that deserves special attention is the multi-AI step. Before the data enters the Cowork pipeline, I feed the same inputs (notes, transcript, survey data, moderator guide, study proposal, codebook) to Claude, Gemini, and ChatGPT independently and prompt each to produce a draft analysis.

This is a deliberate methodological choice. In qualitative research, investigator triangulation means having multiple analysts independently code the same data to reduce the influence of any single analyst's biases. Using multiple AI systems serves a similar function: each system has its own tendencies, blind spots, and interpretive habits. Where they converge, I have more confidence the pattern is real. Where they diverge, I have a signal that something interesting is happening and warrants closer attention.

This isn't a rigorous inter-rater reliability check. The AIs aren't coding against the same scheme with the same granularity. But as a heuristic for catching things I might miss and challenging my own first impressions, it adds real value. I've caught myself over-weighting a finding because one AI flagged it prominently, and I've also caught all three AIs confidently asserting something the transcript doesn't actually support.

This is not "AI doing the research." The pipeline uses AI to accelerate the parts of qualitative analysis that are mechanical (transcript cleanup, passage retrieval, draft generation) while keeping the parts that require judgment (coding decisions, theme definitions, analytical framing, editorial control) firmly with the researcher. Every theme, every code, every published finding goes through human review and approval.

It is also not a fixed system. This is v1 of the workflow, and I'm refining it as I go. The skill definitions, the codebook structure, the publishing format, the multi-AI triangulation step: all of these are evolving based on what I learn from running sessions. Part of the value of documenting this workflow publicly is to show that these methods are accessible, adaptable, and worth experimenting with.

The pipeline runs in Claude Cowork using three custom skills built on top of Claude (Opus 4). The multi-AI triangulation step uses Claude, Gemini, and ChatGPT. The site itself is a static Next.js app. Session content is stored as MDX files. The codebook is YAML. There is no database, no CMS, and no server-side processing. Everything is files on disk.