I built a research repository in Jira and wanted to get my process down in writing for those in the same boat I was in: weighing the pros and cons of Jira without a guide.

UX repositories are critical, but selecting the right platform for your organization is not easy. Since I created our repository I have heard from many people wondering specifically about using Jira and whether it can work despite not being designed as a research repository.

I wanted to get my process down in writing for those in the same boat I was in: weighing the pros and cons of Jira without a guide.

This article is two parts: in Part One I share our selection process, in Part Two our steps for creating the actual Jira project. I hope you find something useful here and it saves you some time.

Why a research repo?

When I joined my current organization I found there was really valuable research data already coming in from our user base through multiple feedback channels. But if it didn’t find its way into a current project it was just getting lost. We were not only losing opportunities to know our products and users better, but we were also wasting time (and frustrating stakeholders) by asking them the same questions again and again times.

A repository for our research data was clearly needed. We set out to research and build a solution.

Without a repository we were losing opportunities to know our products and users better, and wasting time asking the same questions over and over again.

Our goal was to support continuous user research, build a repository of “timeless” data that would increase in value and usefulness over time, and make it easily searchable and available to all members of the team.

Part One: Why we selected Jira for our research repository

It’s an exciting time to do User Research. There is so much innovation happening right now and new tools coming on the market. At the same time the field is still rather new and there is no established user research taxonomy (though it’s one of the topics the wonderful Research Ops project is trying to address). Every organization that goes down this road is in some ways forging their own new path.

Selecting the right platform for a repository, one that will serve your organization over the long term, is not easy. Kate Towsey curates this great list of tools, and it’s a wonderful place to get started thinking about your software needs, but even this list has limited options for research repositories.

In the end, it’s just a database

One important point to keep in mind is that a research repository is a database, pure and simple. It might be bedazzled with features and options, but at it’s heart its a big ol’ table. There are a lot of software options for creating a database table (an excel document or custom sql among them), the question is simply how to make sure you have the fields you need, that it’s manageable for your team, and you can create the views that give you insight into the data.

Our decision table

There is a lot to weigh when selecting the software for your organization’s research repository. How much data will you eventually store, and how quickly will it be coming in? What is the technical expertise — and size — of the team who will be managing the repo? What custom needs does your organization have? And what is your budget?

We asked all those questions and more, as well as considering the deliverables we would need to extract from the data. Who will be reading it, what kinds of questions will they want to answer, and how quickly can they glean that information?

We explored many software options in our quest for the right fit. Below is our decision table with the “Final 7” software options that made the cut for more testing:

Jira: the imperfect best choice

Ultimately Jira emerged as the best — if imperfect — fit for our research repository. The strongest draw for our team was distributed access to the data: the entire organization is already heavily invested in Jira for handling software tickets. We all use the platform on a daily basis, reducing barriers to shared entry.

Here is how Jira held up against our most important criteria:

Cost: Jira was a good fit for our organization on cost because we were already using it for software development tracking. No additional cost.

Data security: Jira cloud encrypts all their data and uses industry-standard accounts management.

Will it be sustainable by a small UX team? We felt we would be able to harness our existing experience using Jira — and it’s integrations with other software — to get more out of this tool with a small team.

Will it integrate well into our workflow? Because of our existing Jira use for software development this was a yes.

Distributed access to data: This was the strongest point for us, and ultimately the reason why we chose Jira. Our entire team is already invested in, and interacts daily with, the Jira interface. Switching to a different project to view relevant research data is a fairly easy step, even for a busy designer or developer.

If the data isnt seen when it’s needed — by the people that need it — then it’s useless, no matter how great the software or how well the data is organized. Using Jira would bring the data closer to the teams that need it.

Creating actionable items: Another important benefit was the ability to turn insights from the UX repo into actionable backlog items right within Jira. They would immediately be seen by our development team in a language native to their workflow, no further translation necessary.

Stability: Similar to data security, we felt secure in Atlassian’s size and category dominance.

Export/Import data: Especially at this early stage in the development of Research Ops, import/export functions will help you preserve your data beyond any one software solution. Its also a huge timesaver when working with large data sets.

Directly contact users: Jira does not have this capability, even with marketplace addons. I havn’t yet found a good solution that offers both research repo and CRM functions at a high level, it’s the unicorn of UX repos I suppose. We opted for separate solutions.

AI-assisted insights: We also ended up not meeting this criteria. Nice, but not a dealbreaker)

Is the software UX focused? Jira is not UX focused, we had to bend it to our will, but it ultimately did what we needed. I share our tips in detail in the second part of this article; They might save you time.

Data types: Jira met our primary need for storing atomized and qualitative feedback. We found our quantitative data had a shorter lifespan than descriptive feedback so that was not our primary focus.

Data source fidelity: We can use Jira’s linking function to link back to original observations in bug and feature tickets. Linking back to the original research right within the ticket provides further context for developers, as well as validation. Jira’s linking function is a simple way to chip away at the discovery-knowledge gap.

If you think Jira is a good fit for your team’s research repository but arent familiar with customizing a Jira project, Part two of this article shares a step-by-step of how we created our user research repository.