Back to docs
Analysis & Synthesis

The Study-Level Description: How to Make Research Findable Without Reading It

Repositories are tagged at the item level and described at no level. A nine-field study record, adapted from the archival description standard.

Short answer: most research repositories are tagged at the item level and described at no level at all. That is why nobody can find prior work — not search quality, not taxonomy design. A colleague evaluating whether your six-month-old study answers their question needs a paragraph that tells them who was in it, what was asked, what it concluded, and what it cannot support. Almost no repository stores that paragraph. It stores four hundred tagged quotes, which is the wrong unit for the decision the person is actually making: is it worth opening this at all?

Archivists solved this problem with a document type called the finding aid, and with a standard for writing one. This article translates that standard into a nine-field study record you can write in ten minutes.

The level you never describe

Ask what your repository describes and the honest answer for most teams is: individual quotes, tagged with themes. Then ask what a stakeholder actually searches for, and it is something like "did we ever look at why enterprise trials stall?"

Those are different levels. The stakeholder is looking for a study. Your repository indexes fragments. A search returns eleven quotes from five studies, and the person now has to reverse-engineer, from fragments, what each study was and whether it applies to them. That reconstruction is expensive enough that most people skip it and commission new research instead.

The Society of American Archivists describes a finding aid as a surrogate for a collection — a description that provides intellectual control and, in Walch's formulation, should proceed from the general to the specific. The point of a finding aid is to let someone decide whether to consult the material without consulting the material. That is exactly the artifact missing from research repositories.

Four rules from the archival description standard

The international standard for archival description, ISAD(G), sets out four rules for multilevel description. They map onto research repositories almost without modification.

ISAD(G) ruleWhat it saysWhat it means for your repository
2.1 Description from general to specificDescribe the whole first, then its partsWrite the study record before anyone tags a single quote
2.2 Information relevant to the levelEach level carries only what belongs at that levelRecruitment criteria belong on the study, not repeated on every quote
2.3 Linking of descriptionsEvery unit is explicitly linked to its parentEvery quote must resolve to its interview, and every interview to its study
2.4 Non-repetition of informationGive common information at the highest appropriate level and do not repeat it lower downStop denormalising study context onto four hundred nuggets

Rule 2.4 is worth quoting from the standard directly, because it is the one that saves the most work: at the highest appropriate level, give information common to the component parts, and do not repeat at a lower level what has already been given higher up.

That rule is the answer to the most common objection to describing research properly — that it is too much work. It is less work. Teams currently attempt to make each nugget self-sufficient, which means every quote needs its own context blob, which means the context is written four hundred times, badly, or not at all. Describe once at the study level, link, and the problem disappears.

The study-level description: nine fields

This is the research equivalent of a scope-and-content note. Nine fields, most of them one line.

  1. Title — a plain-language sentence naming the decision, not the method. "Why enterprise trials stall before the security review", not "Q3 Enterprise Research".
  2. Date range of fieldwork — start and end, not the publication date. A reader needs to know the world the answers came from.
  3. Extent — how many interviews, how many completions, average length. The archival equivalent is a shelf measurement, and it serves the same purpose: scale at a glance.
  4. Who was in it — the recruitment criteria as executed, not as planned. Segment, tenure, plan tier, role, region.
  5. Who was not in it — the exclusions and who never made it through the screener. This field costs one line and prevents more misreadings than the other eight combined.
  6. What was asked — the question set, or a link to it, including which questions were structured and which were open.
  7. What it concluded — three to five sentences. Findings, not a summary of activities.
  8. What it cannot support — the scope limitations, stated in the affirmative. "This cannot tell you anything about self-serve customers, and does not measure willingness to pay."
  9. Related studies — explicit links to prior or successor work on the same question.

Fields 5 and 8 are the ones nobody writes and the ones that make the record trustworthy. A description that only advertises what a study proves is marketing. A description that states its own limits is a finding aid.

What belongs at which level

Rule 2.2 in practice. Put each fact exactly once, at the level where it is true:

LevelWhat is described here
StudyPurpose, brief, recruitment criteria and exclusions, fieldwork dates, question set, conclusions, limitations
InterviewWho this participant was against the criteria, mode used, duration, completeness, quality signals
AnswerThe question stem, the response, the follow-ups that were triggered
QuoteThe verbatim text and its position — and nothing else, because everything else is inherited

Read the bottom row again. A quote should be almost bare. Every property teams currently stamp onto nuggets — segment, study, date, method — is inherited from a parent level and should be resolved through the link, not copied. That is what makes descriptions stay correct when a fact changes, and it is why a repository built on copied context degrades within about two quarters.

The thirty-second test

A study-level description works if a colleague who was not involved can read it in thirty seconds and correctly answer three questions:

  1. Does this bear on my question?
  2. Do I trust it enough to act without reading further?
  3. If not, what is the first thing I should open?

If the answer to (3) is "the whole transcript folder", the description has failed. If the reader has to open the study to find out whether the study is relevant, you have a repository with no finding aid — which, functionally, is a warehouse.

How to write one in ten minutes

Do it at debrief, not later. The single biggest predictor of whether a study is findable in a year is whether its description was written in the week fieldwork closed, while the exclusions and the caveats are still in someone's head.

The ten-minute version:

  • Minutes 1–2: fields 1–3 from the study record; these are facts, not writing.
  • Minutes 3–5: fields 4 and 5, copied from the screener and the recruitment log.
  • Minutes 6–8: field 7, lifted from the top-line findings, cut to five sentences.
  • Minutes 9–10: field 8, which you write by asking one question — what would I stop someone from claiming with this?

Field 6 and field 9 are links, not prose.

How Koji removes most of the typing

Seven of the nine fields already exist as structured data in Koji before anyone opens a document, which is the difference between a description that gets written and one that is perpetually on the backlog:

  • The research brief carries the purpose, the decision at stake, and the planned criteria — fields 1 and 4 in draft form on day one.
  • Fieldwork dates and extent are recorded automatically as interviews complete, so fields 2 and 3 are never stale and never estimated.
  • The question set is the study configuration, so field 6 is a link to a live object rather than a copy of a Google Doc that has since been edited. All six structured types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — are stored with their exact stems and options.
  • Screener and completion data give you field 5 for free — who was excluded and who dropped out are properties of the study, not a memory.
  • Automatic reports draft field 7. Findings, themes, and the distributions from structured questions are generated as interviews land, so the conclusions field starts from real output instead of a blank page.
  • Cross-study search populates field 9, because finding prior work on the same question is a query rather than an act of recall.

That leaves field 8 — what the study cannot support — as the one thing a human must write. It should be. It is a judgement about scope, and it is the field that earns the reader's trust.

The compounding effect

A description costs ten minutes once and is read every time someone considers commissioning work in that area. Repositories fail not because teams do not tag enough, but because they describe at the wrong level and then wonder why retrieval does not translate into reuse. Describe the study, link the parts, and stop repeating yourself downward — the standard has been settled since 1994, and it transfers to research almost word for word.

Frequently asked questions

Is a study-level description the same as a research report?

No, and conflating them is why the description never gets written. A report argues findings to an audience that has decided to engage. A description helps someone decide whether to engage at all — it is shorter, more factual, includes limitations prominently, and is written for a reader who may have no context. A good research report still needs a description in front of it.

We already have a taxonomy. Isn't that description?

A taxonomy is a controlled vocabulary for classifying things; a description is prose about a specific thing. They do different jobs and you need both. Taxonomy answers "what is this about?" and helps you retrieve candidates. Description answers "what is this, who is in it, and what can it support?" and helps you judge candidates. Repositories with excellent taxonomies and no descriptions still fail the thirty-second test.

Which level should we describe first if we are backfilling?

The study level, always, and only for studies that have been cited at least once. Descriptions have value proportional to how often someone is choosing whether to open the material, so start with the studies people already bump into. Backfilling item-level tags on old research is almost always wasted effort.

How does non-repetition work if quotes are shared out of context?

It works if — and only if — every quote resolves to its parent. Non-repetition assumes rule 2.3, linking, is honoured. If your repository lets a quote exist without a working link back to its interview and study, you cannot apply non-repetition and you are stuck copying context forever. Fix the linking first.

Does AI auto-summarisation replace this?

It drafts most of it and cannot finish it. A model can summarise what was said and even what was concluded, because both are in the transcripts. It cannot reliably state who was excluded from the sample or what the study should not be used to claim — those depend on the recruitment reality and the decision context, not on the interview text. Draft with AI, then write field 8 yourself.

How long should a study-level description be?

Under 250 words for the prose fields, plus the structured ones. If it is longer, the reader who was deciding whether to spend fifteen minutes on your study now has to spend three minutes deciding whether to read your description, and you have moved the problem rather than solved it.

Related Resources

Related Articles

How to Write a Research Brief: Templates, Examples, and AI-Assisted Generation

A step-by-step guide to writing an effective user research brief. Covers the 7 essential components, participant targeting, methodology selection, and how Koji's AI generates briefs automatically from a plain-language goal.

Insight Repository Methodology: How to Build, Tag, and Activate a Research Insight Library (Beyond Just Storage)

The methodology layer most repository guides skip — taxonomy design, atomic insight structure, governance, freshness/decay rules, and the insight-to-action workflow that turns a static archive into a decision engine. Includes a 2-week setup plan and how AI auto-tagging from Koji eliminates the librarian bottleneck.

Research Debrief: How to Synthesize and Share Findings After Every Study

A complete guide to running research debriefs — turning raw interview data into stakeholder-ready insights. Includes a debrief template, synthesis techniques, and how Koji automates the hardest parts.

How to Build a UX Research Repository: The Complete Guide

A research repository transforms scattered insights into a searchable organizational asset. Learn how to build one that teams actually use.

Structured Questions in AI Interviews

Mix quantitative data collection — scales, ratings, multiple choice, ranking — with AI-powered conversational follow-up in a single interview.

User Research Report Template: How to Present Findings That Drive Action

A complete guide to writing user research reports that stakeholders actually read — with a proven structure, templates for key sections, and how AI-generated reports change the game.