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:
Don't do big reveals—get feedback early and often on your work, especially if it involves other people
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 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:
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:
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:
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
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
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:
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.
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.
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.
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.