How to Build a Qualitative Research Repository

Years of usability sessions, interviews and customer calls tend to end up spread across decks and shared drives, so questions that were already answered get researched again. A research repository turns those individual studies into one body of customer knowledge the whole product organization can search and question. Each new study adds to it, so what the team knows compounds.

What is a research repository?

A research repository is a centralized, searchable home for research data, artifacts and insights, organized so that someone who never ran the study can find what it found and check the evidence behind it. Most of what goes in is qualitative research: interviews, usability sessions, customer calls, open-ended survey answers and the findings drawn from them.

A working repository holds more than reports. The contents fall into six kinds:

• Recordings: The video or audio of each interview, usability session or customer call, kept where consent allows.
• Transcripts: Searchable text of every recording, with speakers labeled and identifying details removed where needed.
• Reports: The decks and summaries each study produced, including agency deliverables.
• Highlight clips: Short excerpts, often 15 to 45 seconds, that show one finding in a participant’s own words.
• Tagged insights: Individual findings saved as their own entries, each linked to the clip or transcript line that supports it.
• Metadata: The study’s date, method, segment, product, market and the decision it informed, which is what makes everything above findable.

How is a research repository different from a document library?

A document library stores files. A research repository stores structured, tagged findings that teams can query and trace back to the evidence. A spreadsheet that lists every study is a third thing, a register, and it says what happened without saying what was found.

The difference shows up in what a search returns. A product manager who types “cancel” into a shared drive gets a stack of decks, each named for a project, and has to read them all to learn whether customers cancel or downgrade. In the repository, the same search returns the finding itself, the studies it came from and a short clip of a participant saying it in their own words.

Folder libraries are easy to add to and hard to search. Insight databases are the reverse. Teams can combine the two, with an insight layer on top of the study folders it links to. An academic or institutional data repository is a different thing, an archive where researchers deposit datasets so that outside researchers can download and cite them.

How does a team build a research repository, step by step?

The six steps run in this order for two reasons. Tags have to exist before anything is uploaded, because retagging past studies later rarely gets done. Consent has to be settled before search, because a recording the team was not permitted to keep should never appear in an answer.

Step 1: Decide what goes in

The inventory covers every artifact kind listed above, from every team, not only the research team. Past agency work and customer calls belong in it alongside new studies. A folder of recorded customer-service calls that nobody labeled as research can turn out to hold the most useful findings on a topic.

Anything a customer said that someone made a decision on goes in. Analytics tables and closed-ended survey counts stay in the dashboards they came from.

Step 2: Design a tagging taxonomy

Tag by the business question, never by the project or the person who ran it. A tag called “Q3 Jen onboarding study” dies when Jen leaves; a tag called “decision: onboarding redesign” is still true in five years. A workable set has five dimensions, each with a short list of allowed values and a one-line definition. For a software product, they might look like this:

• Decision: The choice the study fed, such as an onboarding redesign, a pricing change or a new checkout flow.
• Customer segment: The group the participants belong to, such as new customers and churned customers. Long-tenured customers are another allowed value.
• Product area: The part of the product under study, such as onboarding or billing. Search is another allowed value.
• Journey stage: The moment in the customer’s experience the study covers, such as sign-up or the first week. Renewal is another allowed value.
• Study type: The method used, such as AI-moderated interviews, usability tests, prototype tests or recorded support calls.

With those tags, a product manager redesigning the first week filters to decision equals onboarding redesign and journey stage equals first week. A handful of dimensions with short value lists tends to be enough.

Step 3: Set access and governance

Give everyone the right to read. Give a defined group the right to add, and one person the right to change the tags. The Nielsen Norman Group’s 2024 survey of more than 400 UX and research-operations professionals found that 29% of repositories had no owner at all. It also found that repositories without an owner tend to become disorganized and neglected (NN/g). A typical split of roles across product, design, research and marketing teams looks like this:

• Viewers: Everyone in the company can search and read, including sales and support.
• Contributors: Researchers and product managers add studies under the existing tags. The marketing team can also add calls and clips.

The research lead serves as the tag editor. This person owns the taxonomy and approves new tags. The editor also merges duplicates and checks changes with product and design leads.

The taxonomy owner is a named person rather than a committee, because a tag set nobody is responsible for grows by a few tags a week, added just in case, until nobody can find anything. Contributors propose a tag through a short form, and the owner decides within the week.

Step 4: Handle consent and data

Settle the questions below before the first recording goes in:

• Reuse consent and identifying detail: The original consent has to cover storing the recording and using it beyond the one study. Where it did not, the team keeps an anonymized transcript and the findings and deletes the video. Faces, voices, names and addresses come out before a recording is widely shared. In-home interviews, for example, can show faces, front doors and street names, so a team might blur the video, anonymize names and voices, and keep the full transcripts with addresses removed.
• Retention: Recordings usually get a shorter window than anonymized findings, which can stay as long as they remain true. The team writes the windows down per artifact type and reviews them yearly.

Strella is SOC 2 and GDPR compliant, and study data, transcripts and results are never used for model training. Recordings that go into the repository can have video blurred and names and voices anonymized.

Step 5: Make it searchable and queryable

Search starts with filters on the tags from Step 2 and becomes useful when a team can ask the repository a question in plain words and get an answer that cites its sources. Filters let a designer narrow to recent usability tests of onboarding. Querying lets the product manager ask one question across all of it.

In Strella’s research repository, teams upload past interviews, customer calls and research documents, and new AI-moderated studies land there as they finish. A team member chats with the repository, across selected sessions or everything in it, and gets answers linked back to the interviews they came from. Teams can also query the repository from inside Claude and ChatGPT through the Claude and ChatGPT connector. A product manager asking why customers stop coming back gets each reason tied to its source studies and a highlight clip, including support calls uploaded from past work.

Step 6: Launch and drive adoption

Launch with one team’s live question rather than a full migration. A team can open the repository to one product team with only the studies on its current question loaded, such as onboarding usability tests and churn studies, answer that question the same day, and use the answer to recruit the design and marketing teams.

Onboarding for cross-functional teams takes one session. It covers how to search and how to read a finding with its clip. The team also learns how to add a customer call. From then on the repository is the first stop before anyone commissions new research, and the brief for any new study states what the repository already says and the gap the new study fills.

What are the best practices for a repository taxonomy?

Keep the tag set small and defined, with one owner. The conventions that hold up across years of studies and several rounds of team turnover are short:

• One canonical name per concept, with synonyms mapped to it; “sign-up” and “registration” are one tag.
• A one-line definition and an example for every tag.
• Few broad tags over many narrow ones; a new value gets added only when a search fails without it.
• Free tagging inside a project, controlled tagging at the global level.
• A single editor who decides, and a suggestion form anyone can use.

The tag editor checks for sprawl every quarter. The editor reviews use counts and merges tags applied fewer than a handful of times. The editor also splits tags that have swallowed hundreds of entries. For example, a tag like “payments” might split into “invoices” and “payment methods”, while “beginners” merges into “new customers” once nobody can say how the two differ.

Durability through team changes comes from a one-page document that explains the purpose of the taxonomy, each dimension, who edits it and how to propose a change. With that page, whoever replaces the person who built the tags can run the quarterly review in their first month. If a new hire can’t learn the tag set from the one-page doc in an afternoon, cut tags until they can.

Should a team build, buy or repurpose?

Three options exist, and the right one depends on how many teams commission research and how often interviews run.

• Repurposed tools: A shared drive, wiki or spreadsheet fits one or two people running a few studies a year, because the person who built it still remembers what is in it. Its limits show the first time a second team asks what the research found rather than whether it happened, since tags apply to whole files and nobody can search inside a recording.
• Dedicated repository: A tool whose only job is storing, tagging, clipping and searching research fits an organization where agencies and several internal teams commission studies but the interviews run elsewhere. It depends on someone uploading and tagging each study consistently, so the tagging hours need a budget, or the repository goes stale.
• Research platform with a built-in repository: Each new study lands in the repository automatically with its findings and clips. Past work is uploaded once so old and new can be searched together. It fits teams whose interviews run continuously on that platform, and the back catalog is best uploaded in the first month. Studies run elsewhere still have to be uploaded.

How does a team keep a repository alive?

The owner retires stale findings on a schedule, and three plain rules of thumb are enough to start:

• Review findings about a year after the study.
• Retire prototype findings once the feature has shipped and changed.
• Archive retired findings with a date and a label rather than deleting them, because the next researcher can use a retired finding to see what the team already tried.

The owner checks these adoption signals monthly:

• Searches and queries that come from outside the research team
• New-study briefs that cite what the repository already says, along with studies the team did not commission because the answer was already there

A team is too small to need one while it can name every study from memory and everyone who needs the findings sits in one room. The day someone asks a question the team knows was answered and cannot find, it is time to build.

How does this apply to consumer insights teams?

Consumer insights teams build the same thing. They usually call it insights management or an insights hub. The six steps above apply unchanged. The difference is what goes in and who reads it.

Their inputs are agency decks, brand trackers, recorded customer calls and AI-moderated interviews. They have fewer usability sessions and prototype tests. Their tags run on decision, segment, product and market rather than product area and journey stage. The people searching are brand managers, marketers and commercial teams as often as researchers. A brand manager preparing a retail pitch, for example, filters by decision and market and finds the agency work and customer interviews from the last time the question came up.

Bring your research question to us and we will talk it through.

FAQ

What is an example of a research repository?

One example is a product team’s repository holding onboarding usability sessions, prototype tests, AI-moderated churn interviews and recorded support calls. Each study is tagged by decision, customer segment, product area and journey stage, with every finding linked to its clip. Before a pricing change, a product manager can filter to decision equals pricing change and segment equals churned customers and get every study on why those customers left in one list.

What is another name for a research repository?

Insight repository, insights hub, research library and research knowledge base all describe the same thing. UX teams say repository or library and use the two interchangeably.

What should go in a research repository?

A research repository should hold recordings, transcripts, reports, highlight clips, tagged insights and the metadata that makes them findable: date, method, segment, product, market and the decision each study informed. Past agency work and recorded customer calls belong in it alongside new studies, since those are the findings most often lost.

Is a shared drive or wiki enough for a research repository?

For one or two people running a few studies a year, yes. Beyond that, the limits show quickly: a wiki page can link to a 90-minute recording, but nobody can jump to the two minutes where a participant explains why she cancelled her subscription. Once a second team needs findings rather than a file list, the drive becomes an archive people stop opening.

When does a team need dedicated research repository software?

A team needs dedicated software once several teams commission research and the findings have to be reused by people who never attended the sessions. The strongest signal is a repeated study, such as a new churn study on a question that recorded support calls had already answered. Another is a new brief that cites a past study nobody can locate. A team whose interviews run continuously gets further with a platform whose repository fills itself as studies finish.

How do teams get people to use a research repository?

Make the repository the first stop before any new study, and make the first answer fast. Every new-study brief states what the repository already says, and the first team to use it should get a live question answered within a day.

After launch, one named owner keeps the tags clean and everyone can read without asking permission.

Do consumer insights teams need a research repository or an insights management platform?

They are the same thing by a different name, and the same six steps apply. Market research teams tend to call it insights management, an insights hub or an insights platform.

What changes is the inputs (agency decks, brand trackers, customer calls) and tags that run on decision, segment, product and market.