Using a Research Repository as a UXR Team of One

How I used a research repository to maximize my impact as a UX Research Team of One. | 2019

As a Research Team of One at an early stage startup, I’ve had equal parts opportunity and challenge. One of my biggest challenges over the last year and a half has also manifested into my biggest asset: researching, establishing and maximizing my use of a research repository.

As a team of one, I was struggling to effectively organize research being done while advocating for more generative research.

There was so much to build. So much to research. I was struggling to keep track of feedback coming in from the various sources and separate it from the looming roadmap work.

18 months ago, we were doing a lot of evaluative research. It felt impactful and it was slowly but surely helping us improve our products, but I felt that familiar feeling that we still weren’t necessarily building the right things. Sure, we were validating that what we did release was successful, but what if we were solving the wrong problems? What if there was more to know?

As I worked on making user research part of the every day at my company, I also worried about how to scale this practice as the only person focused on the doing of research and the operations of research, at least for the time being. I wondered how I’d communicate all the research already done to future-me and future researchers and product teams. I was lost in a pile of Google Docs in various Drive folders, not knowing which way was up. I needed a system that helped me succeed, not one that had me continually wondering where I saved that research report.

I had a few goals for this new system:

  • It must enable me to not re-do research by being able to easily search and find past data and insights in a single place

  • It must be accessible to other members of the product team

  • Multiple feedback sources must be fed into the same system

I wanted to be able to continue doing my job without needing to be constantly worried that all historical research knowledge was in my head or some long-gone Google Doc.

The ultimate goal, however, was to be as organized as possible so that I could feel confident speaking up and contributing to roadmap discussions. With all the research I was doing on a daily basis, it would be a disservice to our users to not have their voice be heard.

Researching the best tool for the job

I had been reading a lot about research repositories thanks to the Research Ops Slack group and it sounded like exactly what I needed to make my life a little less chaotic.

Airtable

From my initial research, it seemed like Airtable would be a good fit as someone who did not have the means to create an in-house tool. Airtable “works like a spreadsheet but gives you the power of a database to organize anything” and it was helpful in pivoting and grouping based on different values. As I started to build out the tables, I followed a method similar to WeWork’s Polaris or Zapier’s User Studies Database.

In the beginning, it made a lot of sense. I was able to use Zapier to send feedback from Slack and Intercom and could then add the appropriate tags on severity, frequency, and so on. I added my insights from usability tests, user interviews, and other research activities.

It was easy for the team to use and search keywords to understand, generally, what people were talking about. Research never felt lost, as all of our insights were in one database.

I would often refer to the Airtable repo as my child. I tended to this baby more than my skincare routine, and for those who know me… that’s a lot.

This tool was a game-changer, but we outgrew it very quickly. I was still being inundated with feedback, and while it now lived in one place, it didn’t help me be more efficient. If the only thing I did was tag and organize things, I’d fill my entire day. But I had sessions to run and plan and a research practice to build. By the time the Airtable repo hit 1000 lines, I knew it was time to look for an alternative solution that didn’t need a babysitter.

Our original research repo “Bits”

EnjoyHQ

I went back to the Research Ops community and asked for their recommendations. I was quickly connected with Sofia, one of the co-founders of EnjoyHQ (formerly Nom Nom), and we set up a demo.

What blew me away most was the search functionality and the integration options. It no longer felt so overwhelming to be including Intercom message or emails. I could easily search, highlight, create projects, tag documents and more. I decided to jump all in, with a lot of faith, and the budget was approved.

The most helpful parts of EnjoyHQ and those that I use daily are:

  • Intercom integration — I’m able to see full conversation to understand the context of each piece of feedback

  • Search — easily find documents from keywords, tags, properties and more

  • Tags — tag feature requests, usability issues, etc. I also rely on tags imported from Intercom to add properties to documents

  • Properties—easily categorize and search all documents

  • Rules — automate tagging and adding properties based on other tags, keywords, and more

  • Highlights — identify important quotes from any document

  • Projects — plan, organize, label, and track the status of all on-going projects

  • Analysis board — group like highlights together to create themes and stories

  • Project summary & stories — summarize and share research findings out to the team

  • Reports & dashboards — create a visual representation of research done

EnjoyHQ Document View (courtesy of their help documentation)

A year of grooming

The beginning

I started using EnjoyHQ as our research repository just about a year ago.

EnjoyHQ allows us to connect to Intercom and Slack, forward emails, as well as upload our internals notes, videos, or spreadsheets that have research-related information. I can tag documents, add documents to research projects, create dashboards, find project insights, and neatly summarize findings. This tool has taken a ton of manual labor out of maintaining a research repository and has allowed me to focus on running sessions, analyzing them, reporting on them, and doing more generative research.

In the first six months of using EnjoyHQ, I could already feel the impact. Everything was organized and their team was responsive and putting out new features often. But I didn’t feel like I was capitalizing on the fact that I had ALL of my research in a single place.

The current process

In the second half of 2019, I focused heavily on making sure I was making the best use of the various inputs of feedback about our products. It was around the same time I began to support all of our teams, not just one, and I knew a key to my success would be maximizing time spent with the team or talking to users, not sorting through data and tagging it appropriately. While it felt more robust than the Airtable version, I was still doing more manual work than I preferred.

Here is my current process, and what is working well for our team:

Feedback comes into EnjoyHQ in the following ways:

  • Intercom messages

  • Slack integration

  • Emails

  • Uploaded interviews

  • Uploaded usability tests

  • Uploaded survey results (via spreadsheet)

  • And more

Automation

I use tags, keywords, and properties to automate the classification of feedback.

When tags are added to a document, either by Research or Support, a rule is triggered that creates a series of properties for the document. I use these properties to aid in searching, tracking features, and creating reports.

Having a good taxonomy set up has been instrumental in creating rules to do the tedious work for me. I can easily find documents on research or feedback that I may have never seen before.

Grooming

I use saved searches and tags (feature request/enhancement, usability issue, etc) to catch any documents that are missing properties.

Tagging and adding properties to these documents allows me to:

  • Create projects to bucket trending feedback

  • Create reports to show trends over time

  • Create reports to show the volume of feedback in particular areas/teams/products/etc

  • Increase efficiency of searching qualitative data

  • Pull in historical data to a current project

Synthesis

I use EnjoyHQ to synthesize research related to a single project. By creating a project, I can add any feedback to the project and find & group like insights.

Projects may be current things I’m tracking, features tested, discovery interviews, or anything that is related to a research goal or question.

Sharing

After synthesis, I’m able to create a summary view that pulls in insights and user quotes. Each project summary can have one main summary and multiple “stories.” We use these summaries as our “source of truth” when looking back on past research. I have yet to determine a shelf-life for old research projects, but we’ll get there when we get there.

EnjoyHQ Report View (courtesy of their help documentation)

Finally organized

The past six months have felt more painful at times than I would have liked. There were days where I would just spend time combing through hundreds of documents to try to create these rules and patterns. I restructured our taxonomy, connected with Support to be in sync about our tags, and I accounted for 13,000 (and growing) documents in the database.

But by the end of the year, it was a well-oiled machine. I didn’t feel overwhelmed by the volume of data anymore; I felt inspired. To have so much (organized) information at our fingertips to make informed decisions felt great.

The big reveal

Remember at the beginning when I said I was concerned we were only validating feature requests but not digging into the true problems our users were facing? I now felt armed with the right mix of qualitative and quantitative data to join roadmap meetings to discuss these challenges in depth. I could now back up my research in a more visual way that stakeholders understood.

EnjoyHQ Dashboard created with top reports I was focused on presenting (specific data redacted)

Creating EnjoyHQ Dashboards from saved reports (courtesy of their help documentation)

I presented everything I’ve walked through here at a Design Review meeting with the stakeholders.

After a brief intro, I dove straight into EnjoyHQ. I showed them how they could find the information they were looking for, look at reports and dashboards I’d created, dig deeper into the documents that made up those reports or even create their own mini-reports based off the umbrella ones. I explained how easily we document research in an organized fashion.

EnjoyHQ Search example (courtesy of their help documentation)

The response was incredible. I finally got to hear “why aren’t we using this in roadmap discussions?!”

Onward!

With full buy-in on research repo life, I feel more motivated than ever to continue researching our users and advocating for them each day. I’ll continue to maximize how much EnjoyHQ can automate and organize for me, but I also look forward to using it as a better communication tool when working with the team. All of the to-dos and exciting improvements no longer feel so intimidating.