# Research Record Checklist: Keep Every Finding Recoverable

> A one-page operating record for consent, transcript corrections, evidence units, interpretation, access, retention, and handoff.

- Author: Rishikesh Ranjan · Published: Sep 18, 2026
- Type: Playbook
- Tags: AI, Resources, User Behaviour
- Growth levers: Retention (primary), also Activation
- ~2255 words

---

A transcript is not yet a research record. It becomes useful evidence when a teammate can recover the permitted source moment, see what was corrected, understand the question and participant context, distinguish observation from interpretation, and find the owner of the next decision. This checklist keeps those pieces together.

It is the implementation companion to the [AI transcription tools for user researchers](https://www.productgrowth.blog/p/ai-transcription-tools-user-research) comparison. That review helps a team choose the capture and retrieval workflow. This page defines the minimum record that should survive whichever tool the team selects.

> **This is an operating checklist, not legal advice:** Consent, lawful basis, special-category data, retention, and participant rights depend on your jurisdiction, organization, and study. Use your approved policy and involve a privacy or legal adviser when the study requires it. The checklist helps the team record the decision; it does not make the decision for you.

![Five connected stages show permission and source, transcript correction, an evidence unit, interpretation with a caveat, and a decision handoff, with a stop condition when the source cannot be recovered.](https://www.productgrowth.blog/media/posts/research-record-checklist/00-research-record-evidence-chain.webp)
*The record should make the path from permitted source to decision recoverable. If a teammate cannot recover the source moment, correct the record, mark it unverified, or remove it from the finding.*

## The one-page research-record checklist

Copy the table into the study brief, repository template, or ticket system your team already uses. Complete the first three groups before the session, the correction and evidence groups after each session, and the interpretation and handoff groups during synthesis. A field may contain a link to an approved system rather than duplicating sensitive data.

| Record group | Required fields | Stop condition |
| --- | --- | --- |
| 1. Identity and minimal data | Study ID; participant code; segment relevant to the question; session date; researcher; approved source location | Do not place names, contact details, or unrelated personal data in the analytical record. |
| 2. Consent and permitted use | Consent version and date; recording permission; permitted internal or external uses; withdrawal route; any quotation or clip restriction | Do not record or reuse material beyond the permission and policy that apply to the study. |
| 3. Source and capture | Recording or notes link; tool and settings; language; speakers; start and end time; known audio or capture problems | Do not treat a generated transcript or summary as the source when the underlying permitted record is unavailable. |
| 4. Correction state | Transcript version; speaker labels checked; names and numbers checked; unclear spans marked; reviewer and review date | Do not mark the transcript verified if the relevant passage has not been checked against the recording or approved notes. |
| 5. Evidence unit | Exact quote or observation; timestamp or note location; interview question; tag; participant context needed to interpret it | Do not detach a memorable line from the prompt, surrounding exchange, participant segment, or correction status. |
| 6. Interpretation | Finding; supporting evidence units; contradicting evidence; confidence boundary; sample scope; unanswered question | Do not turn one vivid example, generated summary, or analyst assumption into a general claim. |
| 7. Access, retention, and handoff | Permitted roles; system owner; retention review date; deletion or archive action; decision owner; next action; final destination | Do not leave the record without an owner, access boundary, or end-of-life decision. |
*Minimum research-record fields. Adapt the labels to your approved research and privacy process.*

## 1. Give the record an identity without copying the participant

Start with a study ID and participant code that can be resolved only by authorized people in the approved system. Add the segment information that matters to the research question, such as new customer, administrator, or recently churned user. Do not turn the analytical record into a second contact database. Names, email addresses, account details, and unrelated demographic information create risk without improving most analysis.

Name the session date, researcher, and source location. A stable source link prevents a quote from becoming an orphaned line in a slide deck. If the link uses an expiring token or a personal drive, fix the storage path before analysis. The goal is not broad access. It is reliable access for the people who are permitted to review the evidence.

## 2. Record permission as usable constraints

Store the consent version and date, then translate permission into fields the team can act on. Was audio or video recording allowed? May a quotation appear in an internal report, a customer-facing article, or neither? May a clip be shared with a product team? What route can the participant use to ask a question or withdraw where that choice applies? A PDF in a folder is not enough if nobody can tell which use is permitted.

GOV.UK and Department for Education guidance both emphasize explaining the research and what will happen to participant information. Your organization may use different wording or a different legal basis. Keep the approved explanation and the operational restrictions together. When permission is ambiguous, pause the intended reuse and ask the research or privacy owner. Do not interpret silence as permission.

## 3. Preserve the source and the capture conditions

A transcript can look precise while hiding a weak recording. Record the capture tool, relevant settings, language, speaker arrangement, and known problems such as cross-talk, an unstable connection, room noise, or a participant joining by phone. These details tell a later reviewer why a sentence is uncertain and whether a new transcription pass is likely to help.

Keep the recording or approved contemporaneous notes as the source of record according to policy. A generated summary is a derivative. It may help somebody navigate the session, but it should not replace the material needed to verify an exact statement. If the source must be deleted before the finding, record what approved derivative remains, who verified it, and the resulting limitation.

## 4. Make correction status visible

Do not label a transcript simply complete. Store the version, reviewer, review date, and the checks that were performed. At minimum, verify speaker labels and the names, numbers, product terms, and quotations that influence a decision. Mark unclear spans instead of silently guessing. If a participant correction changes meaning, preserve the corrected wording and enough history to explain why the record changed.

Correction effort is also a tool-selection signal. Track how many central passages require repair and how long the review takes. A transcription tool that produces an attractive summary but repeatedly confuses speakers or product terms may increase the cost of trustworthy evidence. The record lets the team see that burden rather than debating impressions after the trial.

## 5. Build evidence units that travel with context

An evidence unit is the smallest piece another person can inspect without guessing what it means. It contains the exact quote or observed behavior, a timestamp or note location, the question or task that prompted it, a tag, the relevant participant context, and the correction state. For a usability session, it may also contain the interface state and whether the participant completed the task.

Keep observation and interpretation separate. “Participant selected Back after reading the price” is an observation. “The pricing page destroys trust” is an interpretation that needs support from the session and, usually, other evidence. This separation is especially important when an AI feature generates themes. Save the theme as a candidate, then attach the evidence units that support or contradict it.

## 6. Put a boundary around every finding

A finding should name what the evidence supports in this study, not what all customers believe. Attach the supporting units, contradictory or complicating evidence, sample scope, and an honest confidence boundary. Write down the unanswered question that would most change the interpretation. These fields make it harder for a vivid quotation to become a general market claim simply because it is easy to remember.

A useful confidence note is concrete: “Observed in four of six first-time administrators completing the setup task; not tested with experienced administrators.” That sentence says more than high confidence. It tells the next reader what happened, where it happened, and what the study did not cover. If the team uses a confidence scale, keep this plain-language boundary beside the score.

## 7. Give the record an owner and an end

Name the people or roles allowed to open the source, the system owner, the decision owner, and the next action. Then add a retention review date and the action due on that date: delete, archive under an approved rule, renew the need with justification, or retain a safer derivative while removing the source. “Keep until no longer needed” is difficult to operate because nobody knows when the decision occurs.

The Information Commissioner's Office describes storage limitation as keeping personal data no longer than needed for its purpose, with research provisions depending on safeguards and conditions. Your policy determines the actual period. The checklist makes that policy executable by putting the review date and owner where the research team will see them.

## Fit the checklist to the systems you already use

In a research repository, make the seven groups fields on the study or evidence-unit template. Keep the participant identity mapping in a separate restricted area. Use stable links from a finding to its evidence units and from each unit to the permitted source. Do not paste recordings or sensitive transcript passages into several projects merely for convenience. Duplication makes access changes, corrections, withdrawals, and deletion harder to carry out consistently.

In a document-based workflow, begin each study with one record table and give every evidence unit a short identifier. A finding can then cite units such as P04-Q7 or U03-T12:18 without exposing a participant name. Lock the final readout to approved viewers, but preserve the source links for authorized reviewers. A document can support disciplined research if the naming, permissions, ownership, and retention steps are explicit.

In a ticket or product-management system, store the interpretation and decision handoff rather than copying raw participant data into a broadly visible issue. Link to the approved research record, state the finding and caveat, name the decision owner, and describe the next action. Check what happens when the ticket is exported, mirrored, indexed, or shared with a vendor. The destination's normal visibility may be wider than the research system's access boundary.

## Five failure modes the record should expose

The first is the orphaned quote: a sentence reaches a presentation without a source moment, question, or correction state. The second is the invisible rewrite: a transcript is corrected, but a clip, summary, or earlier finding still carries the old wording. The third is permission drift: material collected for one internal study appears in a new use nobody checked. Each failure is easier to repair when the record names the source, version, permitted use, and owner.

The fourth is interpretation collapse. An AI-generated theme, researcher's inference, and participant observation are stored as if they were the same thing. Preserve the observation first, then attach the interpretation and its supporting and contradictory units. The fifth is endless retention. A recording remains available because no person owns the review date. Add the owner and intended action when the source is created, not when a cleanup project begins years later.

Audit for these failures with a sample, not a promise. Once a month or at the end of a study, select one finding that influenced a decision and one that was rejected. Trace both records from consent to source, correction, evidence, interpretation, handoff, and retention. The rejected finding matters because it shows whether the system preserves contradiction and uncertainty, rather than only the neat evidence that reached a roadmap.

If the checklist feels heavy, reduce collection before removing traceability. Store fewer low-value recordings, limit the number of fields copied into analytical tools, or define which studies need clips. Keep the fields that let another person recover permission, source, correction, context, interpretation, ownership, and the record's end. The aim is a smaller reliable evidence trail, not a larger archive that nobody can safely interpret or maintain.

## A 20-minute handoff review

Before a finding leaves the research team, ask a teammate who did not conduct the interview to trace it backward. They should open the finding, locate one supporting evidence unit, recover the source moment, see the correction state and permission, and explain the confidence boundary. Then they should trace it forward to the decision owner, next action, and retention date.

1. Pick one decision-relevant finding, not the cleanest example in the study.
2. Ask the reviewer to recover a supporting source moment without verbal help from the researcher.
3. Ask what the evidence supports, what contradicts it, and which population or context remains outside the study.
4. Check that the intended audience and use are permitted and that access is limited to the right roles.
5. Confirm the decision owner, next action, source owner, and retention review date.

Any failure becomes a repair task. Add a missing timestamp, correct the speaker, narrow the claim, restore the source link, clarify permitted use, or assign the owner. If the source moment cannot be recovered and no approved alternative exists, mark the evidence unverified or remove it from the finding. The point of the review is not paperwork compliance. It is to stop unsupported certainty from reaching a product decision.

Keep a short repair log for the first five interviews. Note which field was missing, when the team noticed, how long reconstruction took, and what decision was delayed or weakened. This turns the template into an operating tool instead of a fixed form. If researchers repeatedly search for the interview question, add it closer to the evidence unit. If reviewers never use a field and policy does not require it, simplify the field or remove it. If a stakeholder keeps copying quotes into slides without context, change the export or review step rather than adding another reminder. The checklist should make the safe path the easy path. After the pilot, assign one owner to maintain the template, publish the approved definitions, and sample completed records. A template with no owner slowly accumulates obsolete fields, broken links, and conflicting conventions. A small record that the team can complete and audit is more useful than an exhaustive record that people bypass.

Introduce the checklist in a real study kickoff, not as a separate documentation project. Fill the consent, source, access, and retention fields together, assign the correction reviewer, and create one example evidence unit before the first session. People adopt a record more easily when they can see how it supports the decision they already need to make. At the study close, keep the completed example as the local reference and archive obsolete templates so the team does not choose between competing versions.

## Frequently asked questions

#### Should the checklist contain participant names?

Usually the analytical record should use a participant code and only the segment details required for the research question. Keep identity and contact information in an approved, access-restricted system according to your policy. Ask your research or privacy owner when identity is necessary.

#### Can an AI summary be the evidence unit?

Treat it as a candidate interpretation or navigation aid. Attach the relevant corrected transcript passage, timestamped recording moment, or approved observation so another person can inspect what the participant actually said or did.

#### How long should research recordings be kept?

There is no universal period in this checklist. Use the purpose, organizational policy, jurisdiction, consent, and qualified advice that apply to the study. Record the chosen review date, owner, and deletion or archival action so the rule is carried out.

#### Where should the record live?

Use the approved system your team can maintain. A research repository, structured document, database, or ticket can work if it preserves stable links, access control, correction state, evidence context, ownership, and retention. Avoid duplicating sensitive source material merely to complete the template.

**Next job: Use the record before the evidence spreads.** Add this checklist to the next study before the first interview, then run the backward-and-forward handoff review on one finding. Use it for five interviews. After the fifth, remove fields nobody used and add any correction or handoff field the team repeatedly had to reconstruct.

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog