# User Interview Analysis

Turns interview material into findings that can be traced back to what a named participant actually said.

## Deliverable

One Markdown document, `interview-findings.md`, in the structure set out under **Output** below. It takes the interviews run under the plan from **Research Plan Design** and feeds the decision that plan named.

## Required inputs

- **The transcripts or notes** — one record per participant, each attributable to the participant it came from.
- **The question the interviews were run to answer** — the question, and the decision that turns on it.

Without both, stop. Material with no question behind it can be coded in any direction, and the direction will be the analyst's. Never code from a recording you were given no transcript or notes for.

## Optional inputs

- The interview guide, and how closely each interview followed it
- How participants were recruited, and who that route excluded
- What each participant was told the research was for
- The participant characteristics the decision distinguishes between
- Earlier rounds of interviews on the same question, with their findings
- The consent each participant gave, and what may be quoted

Where the recruitment route is not supplied, the report states that the composition of the sample is unknown. An absent input is never replaced by an assumption about who the participants were or how typical they are.

## Execution

**1 — Prepare the material.** One record per participant, each with an identifier, the date, the format, and whether it is a transcript or a note written afterwards. Transcripts and notes are marked differently throughout, because a note is already an interpretation of what was said.

**2 — Code close to the words.** Work through each record and apply codes that stay near what the participant said rather than near what the question hoped for. A code that cannot be pointed at a passage is not a code. Record every passage each code was applied to.

**3 — Separate reported behaviour from stated intention.** What a participant says they did, and when they did it, is evidence about behaviour. What they say they would do is evidence about intention and nothing more. The two never merge into one code, and never into one finding.

**4 — Build themes from codes.** A theme is a group of codes that recur together across records. For each theme, record the codes it is built from, the participants it appeared in, and the passages that evidence it. A theme that appears in a single participant is labelled as such and kept, not rounded away.

**5 — Keep the disconfirming cases.** For every theme, record the participants whose accounts contradict it and what they said instead. A theme that was never searched for contradiction has not been tested, and the search is recorded even where it found nothing.

**6 — Count participants, never rates.** Report how many participants a theme appeared in, out of how many took part. Never convert those counts into a percentage, a proportion or a projection onto a population the sample was not drawn to represent.

**7 — State what the sample can and cannot support.** Who was interviewed, who the recruitment route reached, who it never reached, and which parts of the question this sample cannot answer at all.

## Output

`interview-findings.md`, in this order:

- **1. Question and decision** — the question, the decision that turns on it, and its owner
- **2. Participants** — one line each: identifier, date, format, `transcript` or `note`, and the consent given for quotation
- **3. Recruitment** — how participants were reached, who that route excluded, and what is therefore unknown about the sample
- **4. Codebook** — one line per code: the code, what it covers, and the records it was applied to
- **5. Themes** — per theme: the codes behind it, the participants it appeared in out of those who took part, and the quotes that evidence it
- **6. Behaviour and intention** — what participants reported doing, listed separately from what they said they would do
- **7. Disconfirming cases** — per theme: the participants who contradicted it and what they said instead
- **8. What this sample cannot answer** — the parts of the question the participants and the route cannot reach
- **9. Open questions** — the question, what it blocks, who can answer it

## Validation

The report is ready when all of these hold:

- Every theme in section 5 names the codes behind it and the participants it appeared in
- Every quote is attributed to a participant identifier and appears in that participant's record
- No theme is attributed to a participant who did not express it
- No count anywhere in the document is expressed as a percentage, a proportion or a projection
- Section 7 is present for every theme, including where the search for contradiction found nothing
- Reported behaviour and stated intention are never carried on the same line

Fail the run if a theme cites a participant whose record does not support it, or if any count appears as a percentage.

## Failure handling

- **No transcripts or notes supplied** — stop. Report that there is nothing to analyse, and name the form the material must take.
- **A recording with no transcript** — list the participant in section 2 as `not transcribed`, leave them out of the coding, and record in section 9 what is needed. Never code from memory of a recording.
- **Consent does not cover quotation** — record the theme and its participant count, mark the passage `not quotable`, and describe it without reproducing the participant's words.
- **Participants contradict one another** — carry both accounts, as separate themes or as a theme and its disconfirming case, and report the question as unsettled by this sample. Do not prefer the more articulate participant.
- **Partial material** — analyse the records supplied, list the missing ones in section 2 as `pending`, and mark the report `PARTIAL — <analysed> of <total> participants analysed`.