If your team(s) already use Jira, it can be a good tool to store feedback and research insights. The problem many teams have is getting non-UX roles to use their research knowledge. The big advantage going this route is better adoption from non-UX teams by using tools stakeholders already use daily. Jira is also flexible enough to do much of what a repo does for sharing knowledge. Especially when combined with Jira’s easy customization and JQL, findability and evangelism for research insights is great. From my experience, here is what I would suggest:
- Keep feedback, artifacts, and general insights in their own Jira project. This keeps things clean and easy to search and share while still enabling linking tickets. You can also manage research projects with their own sprints/cadence this way.
- When you have a key insight/nugget that should get included in development, then you move it over to a product team’s Jira project. I would recommend creating a UX task type, which is simple. This allows you to still see and pull out upcoming UX insights with Jira reporting tools and JQL.
- Take advantage of the custom fields functionality, you can easily add required fields and some custom tagging even. You can also use Labels for tagging, but those can get unwieldy for a taxonomy in the long run.
Several researchers in the ReOps community use Jira/Trello/Monday, here’s an article by one with their setup. Disregard their next-gen comment, next-gen projects are probably the optimal choice since the article was written.
This isn’t to say Airtable isn’t a good option too, there’s probably a slick integration in the Atlassian Marketplace so you could easily get advantages from both approaches. I personally keep my research artifacts in GSuite and manage insights and research projects inside of Jira which should be just as easy with Airtable.
