Creating global and project tags for your research repository

Back in 2015, I remember creating a research repository. I used a WordPress template and begged my developers to help me with custom coding. It was painstaking work. I filled out an extensive form for each research project, and eventually, I had one and a half year's worth of research in our repository.

I was so excited. Aside from the developers helping me with code, I worked on this independently, wanting a big reveal in the end. It took some nights and weekends to catch up, but it was worth the work because I solved my teams' pain point of not finding research. Huzzah, I had leveled up and cured the forever headache of the black hole of insights.

Gathering all my teams into a physical and virtual room, I was buzzing with excitement. A few minutes in, I unveiled my work. I turned into a salesperson conducting a demo with all the enthusiasm in the world. My colleagues were happy, and I left them to explore this new wonderful world I created.

Except, people didn't. I got constant slack messages or emails asking where this or that project would be and how to find a particular insight they had thought they heard. That's when I learned two essential lessons:

1. Don't do big reveals—get feedback early and often on your work, especially if it involves other people

2. I didn't employ my user research hat as I would for any other project—stakeholders are my users, and I failed them

Eventually, I went back and undid most of my work. I included stakeholders in tests, sat down with them to discuss tags, and collaborated on creating a repository made for them. Although the work was slower, we created a fantastic taxonomy that enabled teams to find research more effectively and efficiently—the cornerstones of usability.

Why create a research repository in the first place?

For a while, I was hesitant to jump on the repository train. I was unsure about the value of repositories. If people weren't taking the time to search through Google Docs for research, why would they search in a repository? However, at the time, I worked in a start-up of about thirty people. I quickly funneled results to the one designer and product manager I worked with and the entire company.

Once I moved to a medium-sized company, things changed. Colleagues had done some research before I arrived, but it was difficult for me to find. As I added to the mess and people pinged me with questions, I realized the frustrations colleagues felt trying to find something in the depths of Google Drive.

The value of research repositories came rushing forward:

• Fewer questions from colleagues and less link-copying-and-pasting from the same documents over and over and over

• Less time spent digging through Google Drive to find that one sentence from that one user one month ago

• More infrequent meetings about the research we should do, but we have already done before

• A place of knowledge for the organization that hosts everything, despite anyone leaving

• Information becomes more accessible to colleagues, meaning they are less reliant on researchers to find and use insights

Start a research repository

Even with all the signs pointing toward "collaboration" and "do your research," I still managed to create my first repository in a vacuum. As painful as the flop might have been, I learned the crucial steps to creating a research repository.

Start with tags

Good tags are an important component of a successful research repository. These tags enable you and your colleagues to effectively and efficiently search through the masses of data to find what you need. Without proper tags, you will end up with a similar mess that I made above, where no one can find anything, and you resume the never-ending copy-and-pasting links.

There are two main ways I start to differentiate and build a tagging system:

Global tags

Global tags are used across an entire organization to describe something that happened in a research project. We use global tags outside of the scope of a single project, feature, or product. They allow us to see patterns across the entire product(s).

These types of tags might sound familiar to researchers since we commonly use them during synthesis sessions. The most common global tags I use are:

• Pain points

• Bugs

• Usability issues

• Need

• Goal

• Motivation

• Competitor

• Habit/task

• Feature requests

Project-based tags

Project-based tags are much more specific than global tags, and we base them on a single project. These tags come from analyzing the data after a particular project and seeing what themes develop. They allow you and your colleagues to dive deeper into specific data and insights, much more so than global tags allow.

For example, we are running a research study about how people find new travel destinations. As we synthesize the data, we find the following themes that will turn into tags:

• Language barriers

• Reviews

• Instagram inspiration

Multi-tagging will be your best friend, so it is okay to tag an insight with several different tags, including global and project-based tags.

From the above example, we find the following insights and use multiple tags to make them accessible:

1. People tend to look at Instagram to get inspiration for their next trips because of the pictures and trusting the people who post #instagram inspiration, #habit, #motivation

2. Reviews are difficult to find and believe since people aren't sure if a negative review without text has anything to do with them, and they are also unsure of paid positive reviews #reviews #pain points

3. People are concerned about the language barriers they will encounter in specific destinations and are unsure how easy/difficult it will be to navigate, so they won't go unless they have a way to easily translate what is going on #language barrier, #pain point #need

Test (constantly) with your stakeholders

There are four ways I use to test taxonomies with stakeholders in the different stages of the repository creation:

1. 1x1 interviews. Before I go off and create a whole taxonomy, I have 1x1 interviews with colleagues, asking them about how they would search and categorize particular insights. In this session, I give them many insights and understand what words they would use to search for them. We then discuss global tags, and they give me preliminary feedback on these.

2. Card sorting. Once we have feedback for the global tags, I conduct card sorting sessions to understand the hierarchy of the tags. These sessions give me an idea of what global tags might commonly go together. I also use this opportunity to throw in some project-based tags to see how people respond.

3. Usability testing. After we establish our preliminary tags, I will conduct several rounds of usability testing to ensure the search, filtering, and overall experience makes sense.

4. Constant feedback. Once there is research in the repository, I give colleagues a feedback form to constantly log any bugs, usability issues, or confusing tags.

Create a taxonomy dictionary

After brainstorming and conducting several rounds of tests, it is time to create a taxonomy dictionary. I bring together stakeholders during this session, and we make (an ever iterative) taxonomy dictionary. This dictionary has all of the global tags we use with a definition and examples. If we need to make changes to the global dictionary, they have to be discussed and agreed upon by the entire group.

The dictionary also gets updated with project tags, so it is constantly growing and evolving. At the end of every project, the team will agree on the specific project tags, which we will then add to the dictionary. Although it seems like a lot of work to continuously update the dictionary, it is a fundamental document. It allows people to peek in and serves as a vast knowledge reference for the organization.

Patience and constant iteration are vital for taking on a research repository with a proper taxonomy. The most thriving research repositories enable colleagues to get what they need whenever they need it. By taking the time to create a collaborative taxonomy dictionary, you are saving work for yourself and making research more accessible across your organization.

Written by Nikki Anderson, User Research Lead & Instructor. Nikki is a User Research Lead and Instructor with over eight years of experience. She has worked in all different sizes of companies, ranging from a tiny start-up called ALICE to large corporation Zalando, and also as a freelancer. During this time, she has led a diverse range of end-to-end research projects across the world, specializing in generative user research. Nikki also owns her own company, User Research Academy, a community and education platform designed to help people get into the field of user research, or learn more about how user research impacts their current role. User Research Academy hosts online classes, content, as well as personalized mentorship opportunities with Nikki. She is extremely passionate about teaching and supporting others throughout their journey in user research. To spread the word of research and help others transition and grow in the field, she writes as a writer at dscout and Dovetail. Outside of the world of user research, you can find Nikki (happily) surrounded by animals, including her dog and two cats, reading on her Kindle, playing old-school video games like Pokemon and World of Warcraft, and writing fiction novels.