Using Jira as a research repository: pros, cons, and how-to
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 rather long 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 then read on to learn how we created our user research repository.
Part Two: How to build a research repository in Jira
Jira was not intended for the purposes of a research repo and requires a few workarounds (as well as ignoring certain aspects of Jira targeted to software development). Here is how we made it work for us.
Mapping the repo data fields
The most important step is to map out your fields before diving into Jira. Every field, field type, and select options. In mapping out our fields we drew inspiration from Kate Towsey, Tomer Sharon, Emma Boulton, the Research Ops community, and Brigette Metzler. These smart folks are very generous with their knowledge and ideas and I highly recommend a deep dive into their articles.
Our data is input as “observations”. Following Tomer Sharon’s atomized data philosophy the observation is the smallest functional size of a self-contained data unit. One user experience interview might generate anywhere from 1-20 — or more! — individual observations.
Here are a few highlights from our final field list that might help you start brainstorming what need:
- Summary (required by Jira): This field is prominent in Jira and we use it for the observation itself. It has a limit of 245 characters, so if its too long we let observations spill over into an additional description field.
- Context: How the data was gathered, for example a feedback form, survey, etc. We link to the original source whenever possible to maintain a clean audit trail.
- Description: We only use this field when the Summary field isnt long enough so its most often empty.
- Status: We dont use status for observations but it’s required by Jira. We hide it in as many views as possible but can’t make it go away entirely.
- Experience Vectors: For example Negative, Positive, and Mixed.
- Labels: Probably our most important field. This is where we tag observations for future searchability. In Jira this field is arbitrary so we ensure we use matching labels across observations by maintaining a shared reference list.
- UX gold: used rarely, only for the very finest, most highly valued observational wisdom!
- Cleared: This was a field we added later when we realized we were capturing some wonderful quotable quotes that we wanted to use in communications. We use this field to indicate which quotes we have permission to use.
This is what our Observation issue screen in Jira looks like:
Once you have mapped out your fields you are ready to dive into creating the research repo.
Creating a custom project
Confluence has good documentation on each step which I have documented the links below. It took some trial and error for me to figure out the right order because each step builds on the last. If you arent familiar with building Jira projects then following the order below should save you time.
Note that all instructions are for Jira classic projects only, not next-gen. Next-gen projects have fewer configuration options and are not appropriate for the purposes of a user experience repository.
- Start by creating a new classic Jira project.
- Next create all of the new custom fields you identified a need for in the mapping step. Name your custom fields something obvious and easy to find when you search for them in step 4, as you’ll need to constantly find them among a list of generic Jira fields as well as custom fields created for other projects. I prefix all of mine with ‘UX’.
https://confluence.atlassian.com/adminjiracloud/adding-editing-and-deleting-a-custom-field-776636410.html - Create the issue types you will need. I use two issue types in my repo: “Observation” and “Insight”. https://confluence.atlassian.com/adminjiracloud/adding-editing-and-deleting-an-issue-type-844500747.html
- Create a new custom field context to group an issue type with it’s relevant fields. Because Im using two issue types I needed two custom field contexts.
https://confluence.atlassian.com/adminjiracloud/configuring-a-custom-field-776636423.html - Create a screen to control how the fields display to your repo users. I have two issue types so needed two screens.
https://confluence.atlassian.com/adminjiracloud/defining-a-screen-776636475.html
For quickly editing your screens create a new issue, open it, then click “configure” in the issue window: https://confluence.atlassian.com/jirasoftwarecloud/configure-field-layout-in-the-issue-view-961798059.html - Optional: create boards for each issue type. I use a backlog view for Observations and a Kanban board for Insights. If you decided to go with a next-gen project you also have the option to create an agility board. I wish classic projects had the agility board option but they do not (yet!).
Jira Boards (Kanban and Backlog) for observations and insights
We use two different boards for viewing our data. For Observations, a simple backlog list view works best. For Insights we use a Kanban board so we can move them through stages of validation.
As patterns emerge within the user observations were collecting then we create Insights to group them. To group observations to an Insight we use the Jira linked issues field.
In our Insights Kanban board we use the following stages of validation: Dont know yet, Think we know, Yes we know, and All set. We also have a fifth column for insights that were proved incorrect: Invalidated/Wont Do. We don’t want to delete them because we might forget and repeat our work again.
Managing data via imports
Jira offers a helpful import function that can save you a lot of time. It uses the csv format, so it’s ideal if your data collection software can export into excel or csv. When we run a Qualtrics survey, for example, we export the data as a csv, map it to our Jira repo fields, and import it all at once.
Jira also offers the helpful option to bulk edit issues after retrieving the results you want to edit via JQL query: https://confluence.atlassian.com/jirasoftwarecloud/editing-multiple-issues-at-the-same-time-902499024.html. It’s perfect for Friday fuzz-brain ‘oops’ moments.
Filtering and displaying your data.
JQL is Jira’s proprietary query language. It is used to filter and return results. It looks and sounds a bit like SQL, but JQL has it’s own set of constraints.
In SQL, retrieving and displaying can be performed in the same function. JQL, on the other hand, is only for retrieval (‘order by’ being the one fuzzy exception). This is why JQL has no ‘group by’ function and why displaying and manipulating data right in JQL is extremely limited.
Jira intends data to only be retrieved via JQL, but then displayed by other means.
Displaying your data with Jira Widgets
One of the main options within Jira for displaying retrieved data are dashboard widgets. These are geared towards software development rather than data analysis so I found most of them irrelevant, but a few that were useful are:
- The ‘Count’ dashboard widget. It will display a dynamic number for any custom query you input. Want to know how many positive observations have been recorded for the label “search”? Count is the widget for you.
- I also use the heatmap with the ‘Labels’ field selected. The heatmap widget performs a “group by” function based on a selected field. I use the heatmap to display the most used labels (which we use to tag our observations). Its not a deep dive but does give a quick look at what labels have the most traction.
- Pie Charts also group by a selected field. Like heatmaps, we use pie charts to get a quick, broad strokes glance at what components or labels are most used.
In order to use the widgets above you will need to first save your own custom filters (search results). The steps are easy: Go to Issues and do a search, then click “save as” at the top of the results page, above the filter field. You can reuse your saved filters when configuring a dashboard, your sidebar, and the quick filters in your boards.
Useful JQL filters
Once you get the hang of the language setting up filters in Jira is easy. You can see the raw JQL of your queries anytime by clicking “switch to JQL” next to the search field. Below are a few examples of useful filters I use.
This query filters positive observations that have labels. I use it with the pie chart widget and group by label to see which are getting the most traction and are likely to yield insights:
project = AUXH AND issuetype = Observation AND “UX Experience Vector” = Positive AND Labels != none
This “triple fire alarm” query returns negative observations with a high magnitude that happen frequently:
project = AUXDH AND issuetype = Observation AND “UX Experience Vector” = Negative AND “UX Experience Magnitude” = High AND (“UX Event Frequency” = Often OR “UX Event Frequency” = Constant)
This filter selects a range of issues based on their key, which is useful for analyzing specific survey results. I always batch import them so they share a clean range of IDs:
project=AUXDH AND issuekey>=AUXDH-232 AND issuekey<=AUXDH-318 AND creator=currentUser()
There are endless permutations of filter options and techniques you can use. The best way to quickly become familiar with JQL syntax is just by playing around with your data and widgets.
Branching out with complementary analysis tools
When we need a deeper analysis we bump up against the limitations of JQL and Jira widgets and need to branch out. We can export the data as a csv from Jira and analyze it in various other tools. Some on our preffered list are Pandas, google charts, excel, and we recently added Tableau. First export the results you want to analyze as a csv file, then import it into the analysis tool of your choice.
Analyzing research is an artform in itself, as is visualizing data (just ask Edward Tufte). The real magic happens in your understanding of your research as it accumulates. Focus on finding the right research repository tool for gaining those insights, and how to share them will follow.
If your team is using Jira already you might benefit from keeping user research results at everyone’s fingertips, as we did. For my organization, the drawback of Jira is the limits of JQL, while the greatest benefit is the high level of distributed access we can achieve. For my team, the increased access and engagement far outweighed the drawbacks.
Resources
Metzler, Brigette. “Harry Beck, Research Repositories & Getting People to the Station.” Medium, 13 May 2019, uxdesign.cc/harry-beck-research-repositories-getting-people-to-the-station-325b8b57f4be.
Francis, Naomi. “An Interview with Kate Towsey, ResearchOps Manager at Atlassian.” Marvel Blog, 12 Aug. 2020, marvelapp.com/blog/kate-towsey-researchops-atlassian.
Sharon, Tomer. “Foundations of Atomic Research.” Medium, 16 Mar. 2018, tsharon.medium.com/foundations-of-atomic-research-a937d5da5fbb.
Richardson, Jonathan. “I Built a User Research Repository — You Should Do the Same.” Medium, 25 Sept. 2020, medium.com/researchops-community/i-built-a-user-research-repository-you-should-do-the-same-df680e140df8.
ResearchOps. “#WhatisResearchOps.” Mural.Co, app.mural.co/t/researchopscommunity7839/m/researchopscommunity7839/1539419866773/d21dd2cce77e9e502dcdb46c4abfa7ad8a0aff88. Accessed 4 Feb. 2021.
