How to build a clean taxonomy for your UX repository
An introduction to tags & properties with concrete examples
A few years ago, I got hooked on continuous discovery research, read a lot on Atomic UX Research, set up a whole repository, and was ready to find strong patterns and insights across all my users’ feedback but then… I realized that I had no clue how to tag feedback efficiently and put together a good taxonomy. It was hard to find concrete taxonomy examples from other UX research practitioners, so I ended up doing a lot of trials, then errors, then creating a mess, and then cleaning up my mess. Consequently, this article aims to provide concrete examples and some tips to save time (and mistakes!) when building your taxonomy.
Before you start, I would recommend checking out my other article on How to set up a UX repository from scratch as a UX researcher. While it’s not essential to understanding this article, it can help you write your “UX questions to ask to your repository” which are directly tied to the taxonomy. So let’s dive in.
Why a taxonomy for the UX repository?
Imagine for a second going through the analysis of a semi-structured interview without creating any categories or clusters with your users’ feedback. Finding insights into your data is going to be pretty hard, right? It’s the same with a repository.
When working with a repository, the taxonomy is what makes it insightful.
It’s what we need to put in place to be able to search across all pieces of feedback, find patterns, keep track of frequencies in the different areas of your product, build long-lasting UX knowledge, and much more. The taxonomy is a bit like the set of categories that we use in the analysis phase of a classic research project, but what makes this set special is that it isn’t scoped to a single project: a taxonomy is scoped to all your users’ feedback and all your projects.
Start small
When building a taxonomy for a UX repository, the challenge is to simply start. Analysis paralysis is the worst enemy in that phase. It can be quite intimidating to start, but it would be a mistake to wait until the taxonomy is perfect to put it in place or start using it. A taxonomy will never be 100% perfect: it is meant to change, evolve and grow with time. What’s important to keep in mind is that it doesn’t have to be perfect to be efficient. You’d be surprised how much gold you can find in a UX repository with as little as 2 tags and 2 properties.
Think about it, how would you feel if you had to categorize an item in a set of 74 tags and 258 properties? Overwhelmed, right? That’s why it’s important to start your taxonomy small and clean at first. The more tags and properties you have, the longer it’s going to take, not only to categorize feedback but also to search through your repository.
⚠️Warning alert though: Please don’t fall into the trap of thinking that it takes an hour to build the repository and its taxonomy, and magically be done. It takes a lot of time and you will have to allocate resources to update and take care of the repository and its taxonomy. So that’s another reason to start small.
I found that it’s easier to start with a small set of clean tags and evolve the taxonomy with time instead of having no tags at all and tagging as feedback enters in. Tagging as you go can surely become a real mess in very little time, but the real danger is that your tags won’t be focused on what’s actually important. So I suggest starting with a first simple taxonomy. Even if it’s not perfect, you can start tagging feedback with it and refine it later on.
Tags as big categories of feedback
Tagging your pieces of feedback is essential if you want to discover strong insights. Tags are especially useful when searching for specific information or key areas inside the ton of feedback that is hosted in a UX repository. You can think of tags as high-level categories: they are meant to last through time and should be built accordingly. Therefore, before creating or adding any tags to your taxonomy, stop and ask yourself these two questions:
What is the usefulness of this tag?
My suggestion is to think about your goals and your UX questions. What do you want to get out of it? If you’re unsure what your questions are, feel free to take a look at this article. Then, only use tags that you are 100% sure that they’ll be useful to answer your questions. Leave the “just in case” tags behind for the sake of your future sanity. When starting, they are more likely to create a mess than to help.
What are the most descriptive terms for this? / If I were to search for this, what words would I type?
Clarity and simplicity are your best allies when working on a taxonomy. Try to use words that are easy to understand, so that all of your team will be able to search for them.
The rule of thumb is to ask yourself if a new employee on the team will be able to understand what this is about. It’s good practice to avoid abbreviations, acronyms, code names, or simply words that don’t stand alone (like “feedback”, “elements”, “V2”,”fdhsfjshk”, etc.).
Useful tags to start
“Feature request”: Use this tag to identify requests from users, express that something is missing, or would be better if a feature was added, modified, etc. This tag is great to discover what your users value, what they need or what users see as potential improvements for your product or features.
“Hard to understand”: Use this tag to identify the feedback where users ask for help, express they don’t understand something, have trouble finding an important element, have trouble performing a sequence, etc. This is great to discover areas of UX improvements and understand your users’ mental models.
“Device/Platforms” tags: If the product you are working on can be accessed from multiple places, use these tags to identify where the experience took place. Tags like “mobile app”, “desktop app”, “browser platform”, “website experience”, etc. can be useful to start.
In my experience, users will face different challenges and frustrations on different devices or platforms. So I feel it’s always good to be able to separate which feedback is related to which platform for the same product. If you have a lot of them, you can also consider using properties instead of tags.
→ Concrete example: Imagine your product is a calendar app that users can access via three different places:
- Their mobile phone or tablet via an installed mobile app
- Their computer via a web browser
- Their computer via an installed desktop app
Your users’ experiences with your product are probably much different on their mobile devices than on their computers because their context of usage changes. By separating your different platforms with tags, you might realize that users on their mobile have different needs than when they are on their computer, or that what’s important on the mobile experience is not the same as what’s important on the desktop experience.
“Personas” or “Segments” tags: If the product you are working on has clearly defined personas, use these tags to identify which feedback belongs to which persona. In some cases, it’s useful to separate what was mentioned by persona 1 vs persona 2. Here also, if you have a lot of them, consider using properties instead of tags.
→ Concrete example: Let’s imagine our calendar product again. You know that in your market, you have 2 main personas: 1) a healthcare practitioner who uses the calendar product to book appointments with patients, and 2) an entrepreneur who uses the calendar product to book meetings with potential partners. Both personas are likely to use your product pretty differently. So you might want to separate their feedback if you need a clear view between the two personas.
Other tags to consider depending on your product or company:
- Your North star metric (e.g. “Regular readers, so the number of subscribers consuming more than 7 articles per month¹”.)
- A specific phase of interest in the experience (e.g. “Onboarding”)
- An important user-centered metric (e.g. “Retention”)
Tags to avoid
Be careful to avoid tags that are too broad and that their significance can change over time. Here are two examples of tags I suggest avoiding.
Example of too broad:
“Product”: In some organizations, it can make sense to have that kind of tag if you have different types of services or products that are not related (e.g. a tangible product + an e-commerce website + a warranty service) and gather users’ feedback for all these. But if all your gathered feedback is about the same product or service, you’ll probably end up tagging every piece with the “Product” tag. Tagging everything with a tag is as useful as tagging nothing, it will not help you categorize and find what’s really important.
Other ones that are tempting but that you should remain cautious about are “General Feedback”; “Other”; “Data”; “UX”. Before creating such tags, remember to ask yourself: What is the usefulness of this tag? What will I be able to search and find with this?
Example of changing:
“Important”: When you look back 5 years, what you thought was important then is probably not what you find important today. It is no different when it comes to taxonomies. What’s important today will probably change through time, and what is important in your research practice today will maybe not be as important in three years. So this tag is a dangerous one to use: ironically it will not help you discover important themes or insights!
Also, keep in mind that “important” is a vague term, not everyone shares the same meaning of it. Chances are that some people who will use this “important” tag don’t even know what’s important and what’s not. At the end of the day, does this tag mean that it’s important for the researcher? For the company? For this quarter’s OKRs? For this specific project but not important for the other projects? That’s exactly why it’s better to avoid it.
Other ones that are tempting but that you should remain cautious about are “Urgent”; “Problems”; “Upgrades”; ”Update”; “Bug”, etc. Indeed, what’s a “problem” for one might not be seen as a “problem” for another.
Properties & Values as detailed answers to your UX questions
Not all repositories have tags AND properties but I want to cover both so that you have examples of how to use them depending on the repository solution you have chosen.
So what are properties? Properties are similar to tags but have different values attached to them. So they are great to go deeper into the details and categorize with more precision.
Based on what you want to find or discover in your UX repository, try to craft your properties in order to have the essentials to answer your UX questions. Again, start small with these because it’s pretty mesmerizing how fast you can create a mess in seconds with properties.
First, think of the tags you just set and ask yourself:
- In which areas do I need more details?
- Is there a theme that has multiple areas to it?
- What will I want to correlate with tags to have more granular answers/details to my UX questions?
The idea here is not to duplicate your tags but to add depth to them. One of the keys to success with properties is to set them so that you can cross-reference them with your tags.
Useful properties to start
“Features”: Use this property to dive deeper within areas of your product or find specific feedback on specific elements of your product. This is a good one to start with because you will know the values of this property. It’s not something you need to discover, it’s already existing.
The key with this one is to list the main high-level features only. Don’t trap yourself into listing all the tiny or specific features that will rarely be mentioned.
→ Concrete example: Let’s take our digital calendar again. Let’s say two of your key UX questions are: What’s my feature that has the most feature requests? and What are the feature requests for the main feature of my products? You’ll want to use your tag “Feature request” and your property “Features” together to get answers to these questions.
In your taxonomy, you will need a set similar to this one:
Tag: “Feature request”
Properties: “Features”
Values: “Add new event”; “Search event” ; “View event details” ; “Modify event” ; “Delete event”
Over time, you’ll go into your repository and assign a tag and/or properties to the pieces of feedback in your documents. In other words, every time you see a piece that talks about a feature, you’ll mark it with your “Feature” property and its associated value. Then, when you’re ready to search in your repository to get those concrete answers to your UX questions, you’ll build a search query that uses the set just above.
So, your search query in your repository could look like this:
Tag “Feature request” [AND] Property “Features” [IS] “Add a new event”
This way, you’ll have a thorough set in place to answer your UX questions. Plus, you’ll be in a good place to start analyzing your data and finding patterns.
“Users’ satisfaction”: Use this property to mix it with other tags or other properties so that you can discover the areas in which your users are the most satisfied or the most dissatisfied. I personally avoid the middle ground as it’s hard to say when someone is moderately satisfied. Extremes are much easier to spot with accuracy, it’s usually obvious when someone is really satisfied or not. This one is useful to identify places that wreck the user experience or identify features that users love. If you’re a fan of net promoter scores (NPS), you can use these to identify your detractors, neutral, and promoters. Essentially, it can look like this:
Property: “Users’ satisfaction”
Value: “High” ; “Low”
OR
Property: “NPS users segments”
Value: “Detractors” ; “Neutrals” ; “Promoters”
→ Concrete example: Here’s a more advanced one that mixes this property with a tag and another property. Still with our digital calendar product in which you have two personas: a healthcare practitioner and an entrepreneur. Let’s imagine that you have previously created two tags to identify these two personas. One of your UX questions is: What makes healthcare practitioners frustrated about your “modify event” feature?
Your search query in your repository could look like this:
Tag “Healthcare Persona” [AND] Property “Feature” [IS] “Modify event” [AND] Property “Users’ satisfaction” [IS] “Low”
This way, you’ll find all documents in which someone who fits your healthcare persona was unhappy about the “modify event” feature in your repository.
Another strategy with properties: Build your values as you discover
Use the strategy of adding to the taxonomy as you discover if you have a specific UX question but have absolutely no idea of the potential answer(s). The idea is to build your values as time goes, the more you discover, the more you can add to your property’s values. This strategy is especially useful for finding out what the blocking factors are, the reasons for canceling accounts, the elements your users value the most, etc.
→ Concrete example: Let’s say your UX question is What are my users blocking factors with my product? Maybe you know upfront that the lack of compatibility is a blocking factor, but you want to discover and see if there’s more than that.
So you might start your property like this:
Property: “Blocking factor”
Value: “Lack of compatibility”
Then, the idea is to expand the values of this specific property through time. You might find in an interview that your pricing model is a blocking factor. And then, during a user test, you might find that your platform not being available in French is a blocking factor. Or that a lack of access without an internet connection is another one, and so on. With time, you’ll be able to have a pretty accurate picture of what your users’ blocking factors are.
⚠️ Warning alert: Be careful with this strategy, it can get messy real fast. Make sure to frequently review the values of your properties. Ask yourself: Are they all relevant? Are they focused on important elements? Do you have synonyms that you can blend?
Other properties to consider depending on your product or company:
- “Initial motivation”: use this to have a better view of: Why did your users sign up initially? What was the reason why they decided to subscribe to our product? If we stay with our digital calendar again, values could be “Book meetings with multiple attendees” ; “Be more organized’’ ; “Centralize my meetings in one tool”, etc.
- “Product discovery”: use this to categorize how your product was discovered by users. Values could be: “Word of mouth” ; “Social media” ; “TV ads”, etc.
Document everything
Whatever you do, be prepared to change it many times. So document EVERYTHING and update your documentation as frequently as possible. This is essential for your research practice to live on and be viable even if the dedicated owner of the repository and/or taxonomy leaves. It sounds trivial to say but it’s also indispensable to keeping your taxonomy clean. Bonus point, this documentation is great for collaboration with others and our memory.
After a while, you will forget what some of the tags, properties, and values truly mean. Maybe today you’ll create a tag called “Date” to refer to a date in the calendar product, but in two years, your company might have launched a “Schedule a romantic date” feature in the calendar product and this tag might become chaotic.
To keep things really clean, try to take at least an hour every week to review, clean, and update the taxonomy for the first few months. If you have integrations in place and receive user feedback continuously, try to take at least an hour a day. This is going to avoid creating a mess from the very start. As you stabilize your taxonomy with time you’ll need less time to update it.
Better and stronger reports
As time goes by, you’ll tag a lot of feedback and, consequently, you’ll grow a huge knowledge base. The way you will have built your taxonomy will have a massive influence not only on your reporting capacity but also on the strength of your insights. That’s why it’s so important to start it clean and be consistent.
With a consistent and stable taxonomy, you’ll:
- Be strategic in your research practice. You’ll position yourself as a researcher who can conduct research on the big picture and connect the dots. So you’ll be able to report as much on short-term than on long-term themes.
- Increase the validity of your insights because they’ll all be supported by multiple pieces of feedback from different sources.
- Focus your research on what’s truly meaningful for your company or product because your taxonomy will only contain the important elements.
- Organize all your users’ feedback so that you can have clear answers when a product owner comes and asks you what we currently know about a certain feature.
- Be able to “quantify the qualitative” (don’t throw rocks at me please). You’ll be able to see which areas are discussed the most often, and what comes back consistently in your users’ feedback. Some examples: find which of your features has the most requests, find the most mentioned blocking factor, find how many times users have asked for help because they couldn’t find something, etc. So it’s more about having a sense of what’s frequent in the qualitative feedback and what’s not. Of course, that doesn’t mean that the most mentioned elements should be prioritized and the least should be ignored, quite the opposite, but that’s a conversation for another day, this article is already long!
- Etc.
To go further…
To go deeper into this topic, I suggest exploring the Atomic UX Research model to better understand how little pieces of feedback put together become something bigger, and how these together can become an even bigger and stronger thing. Just like atoms becoming molecules, that are subsequently becoming organisms (aka insights). This research model is often core to working with repositories and taxonomies, so it’s a great topic to explore in parallel.
Oh well, that was a long article
A lot has been covered and I believe there’s a lot more that can be covered on taxonomies for UX repositories. If you have two elements to remember from this article, may they be:
- Start small and try to start with what you already know, craft the rest with time.
- Clean is the key. Remember that having too many tags or properties is as useful as having none.
Have fun working on your taxonomy ✨
***
References
- North star metric example from Amplitude, The North Star Playbook
