How to build a shared research taxonomy across product and design teams

Research teams in growing organizations often hit the same wall: someone runs a usability study, tags their findings, and files them in a repository. A few months later, a product manager on another team runs a separate study covering similar territory—without realizing the earlier work exists. The insights are there, but no one can find them because every researcher and team has their own way of labeling and organizing data.

A shared research taxonomy solves this problem. It gives product and design teams a common structure for classifying research so that findings are discoverable, comparable, and useful beyond the study that produced them.

Building a taxonomy that people actually use is harder than it looks. It requires negotiation across teams, thoughtful structural decisions, and ongoing maintenance. This guide walks through the process from start to finish.

Why a shared taxonomy matters

Without a shared taxonomy, research repositories become graveyards. Studies go in but nothing comes back out, because there is no reliable way to search across them.

The consequences are practical and measurable:

• Duplicate research. Teams unknowingly repeat studies because they cannot find prior work on the same topic. This wastes time and participant access.
• Inconsistent language. One team tags a finding as "navigation confusion," another calls it "wayfinding issue," and a third labels it "menu discoverability." All three refer to the same problem, but a search for any single term misses the other two.
• Lost institutional knowledge. When a researcher leaves the organization, their findings become difficult to interpret because the labels they used were personal shorthand.
• Inability to spot patterns. Leadership asks, "What do we know about onboarding across all our products?" Without consistent tagging, answering that question requires manually reviewing dozens of studies.

A shared taxonomy addresses each of these by creating a single organizational language for research. It does not require everyone to conduct research the same way—just to describe their findings using a common structure.

Principles of a good research taxonomy

Before choosing specific categories and tags, it helps to establish principles that guide your decisions. These principles prevent the taxonomy from becoming either too rigid or too sprawling.

Mutually exclusive, collectively exhaustive (MECE)

Categories at any given level of the taxonomy should not overlap. If you have a category called "Usability" and another called "Ease of Use," contributors will be confused about which one to choose. At the same time, the taxonomy should cover the full range of topics your teams research, so that no one is forced to use a catch-all "Other" tag for a substantial portion of their work.

Shallow over deep

Taxonomies with many levels of nesting become difficult to navigate and maintain. Three levels of depth is usually sufficient for most organizations: a top-level category, a subcategory, and individual tags. Going deeper than that tends to create decision fatigue for the person doing the tagging.

Descriptive, not interpretive

Tag names should describe what was studied, not what conclusion was drawn. A tag like "checkout flow" is descriptive. A tag like "checkout is broken" is an interpretation that may not apply to every study tagged with it. Keep interpretation in the insights themselves, not in the taxonomy.

Governed but not gatekept

Someone needs to own the taxonomy—to approve new tags, retire old ones, and resolve conflicts. But the process for suggesting changes should be lightweight enough that contributors feel comfortable proposing additions rather than creating workarounds.

How to build your taxonomy step by step

Step 1: Audit your existing research

Start by looking at what you already have. Gather a sample of recent studies, notes, and tagged data from across your product and design teams. You are looking for:

• What labels and tags are people already using?
• Where do labels overlap or conflict?
• What topics come up frequently?
• What important topics lack any consistent labeling?

This audit gives you raw material to work with. It also surfaces the pain points that will motivate teams to adopt the new system.

If your organization uses a research repository tool like Dovetail, you can export or review existing tags across projects to get a clear picture of current labeling patterns. If research is scattered across Google Docs, Confluence pages, and slide decks, the audit will take longer—but it is even more important.

Step 2: Identify your taxonomy dimensions

A research taxonomy is not a single flat list of tags. It typically consists of several independent dimensions, each describing a different aspect of a study or finding. Common dimensions include:

Research method — How the research was conducted: usability testing, contextual inquiry, survey, diary study, A/B test, card sort, etc.

Product area — Which part of your product the research relates to: onboarding, checkout, dashboards, notifications, admin settings, etc. This dimension is specific to your organization.

User segment — Who was studied: new users, enterprise admins, free-tier users, churned customers, internal stakeholders, etc.

Theme or topic — What the research is about at a conceptual level: trust, performance, accessibility, pricing perception, collaboration, etc.

Research lifecycle stage — Where the research sits in the product development process: discovery, evaluative, continuous, foundational.

Not every organization needs all of these dimensions. Pick the ones that reflect how people in your organization actually search for and think about research.

Step 3: Draft the structure collaboratively

A taxonomy built by a single person in isolation will reflect that person's mental model—and no one else's. The most durable taxonomies are co-created.

Bring together representatives from each team that produces or consumes research. This typically includes UX researchers, product designers, product managers, and possibly data analysts or customer success leads.

Run a working session where the group:

1. Reviews the audit findings
2. Agrees on which dimensions the taxonomy should include
3. Proposes categories and tags within each dimension
4. Resolves naming conflicts (e.g., should it be "new user" or "first-time user"?)
5. Defines each tag with a short description so its scope is unambiguous

Card sorting can be a useful technique here. Print or display the existing tags from your audit and ask participants to group them into categories. This reveals natural clusters and highlights disagreements about how things should be organized.

Step 4: Write clear definitions

This step is the one teams most often skip—and it is the one that matters most for long-term consistency. Every tag in your taxonomy should have a one- or two-sentence definition that explains what it covers and, where needed, what it does not cover.

For example:

• Onboarding — Research related to the user's first experience with the product, from account creation through completion of initial setup. Does not include research on feature adoption after initial setup (see: Feature Discovery).
• Enterprise — Research involving users or buyers at organizations with 500+ employees. For smaller business accounts, use: SMB.

Without these definitions, two people will interpret the same tag differently, and the taxonomy will drift toward inconsistency within months.

Step 5: Integrate the taxonomy into your tools

A taxonomy that lives only in a spreadsheet will not get used. It needs to be embedded in the tools where people actually do their research analysis and reporting.

Dovetail, for instance, allows teams to create structured tag hierarchies that are shared across projects. When a researcher highlights a passage in an interview transcript and applies a tag, they select from the shared taxonomy rather than inventing their own label. This makes the taxonomy the default behavior rather than an extra step.

Whatever tool your team uses, look for these capabilities:

• Shared tag libraries that apply across projects and workspaces
• Controlled vocabularies that prevent ad hoc tag creation without approval
• Search and filter by tag so that findings can be retrieved across studies
• Tag usage analytics so you can see which tags are being used and which are being ignored

Step 6: Socialize and train

Introducing a taxonomy is a change management exercise. People need to understand not just what the taxonomy is but why it exists and how to use it correctly.

Hold a brief training session for each team that covers:

• The purpose of the taxonomy and the problems it solves
• How to choose the right tags for a study or finding
• How to propose a new tag when the current taxonomy does not fit
• Where to find the taxonomy reference document (definitions, hierarchy, governance rules)

It can also help to tag a few existing studies together as a group exercise. This surfaces edge cases and gives people practice before they are on their own.

Step 7: Establish governance

Taxonomies degrade without maintenance. Designate a taxonomy owner—usually a senior researcher or ResearchOps lead—who is responsible for:

• Reviewing and approving new tag requests
• Conducting quarterly audits of tag usage
• Retiring tags that are no longer relevant
• Resolving disputes about tag scope or naming
• Communicating changes to all contributors

Keep a lightweight changelog so people can see what has been added, renamed, or removed. This builds trust in the system and reduces confusion.

Common pitfalls to avoid

Starting too granular

Teams frequently build a taxonomy with dozens of narrowly scoped tags before anyone has started using it. Begin with a smaller, broader taxonomy and add specificity only when you have evidence that people need it. A tag is worth adding when multiple people have independently asked for it or when a broad tag is being applied to findings that clearly need to be distinguished from one another.

Treating the taxonomy as permanent

A taxonomy is a living artifact. If teams feel they cannot change it, they will stop using it and invent workarounds. Make the update process visible and low-friction.

Ignoring cross-functional consumers

Researchers are not the only people who search for insights. Product managers, designers, and executives all need to find relevant research. If the taxonomy uses language that only researchers understand—like method-specific jargon—it will be less useful to the broader organization. Use plain language wherever possible.

Failing to distinguish tags from insights

A common mistake is creating tags that encode conclusions: "users hate the pricing page" or "search is confusing." These are insights, not categories. The taxonomy should describe the subject matter—"pricing page," "search"—while the insight is recorded in the analysis itself.

Measuring whether your taxonomy is working

After rolling out the taxonomy, track a few signals to determine whether it is achieving its goals:

• Tag adoption rate. What percentage of new studies are being tagged with the shared taxonomy? If adoption is low, the taxonomy may be too complex or the tooling too cumbersome.
• Search success. When someone searches for research on a topic, do they find relevant results? Survey your team periodically to gauge this.
• Reduction in duplicate research. Over time, you should see fewer instances of teams unknowingly repeating prior studies.
• Cross-team retrieval. Are teams outside the original research team finding and using insights from the repository? This is one of the strongest signals that the taxonomy is delivering value.

Building a taxonomy is an investment in compounding returns

The payoff of a shared research taxonomy is not immediate. The first few months involve negotiation, setup, and habit formation. But once the taxonomy is in place and consistently used, every new study added to the repository makes the entire body of research more valuable. Patterns become visible. Institutional knowledge survives team changes. Product and design teams stop duplicating effort and start building on each other's work.

The organizations that get the most value from research are not necessarily the ones that conduct the most studies. They are the ones that make their existing research findable and reusable. A well-built taxonomy is the infrastructure that makes that possible.