Jira
Proposing changes to a widely-used project management software
The Context
Exploring possible improvements to Jira’s project management platform
Jira, a product of Atlassian, is a widely-used project management software aimed primarily at supporting software development teams with planning, tracking, and collaborating on projects.
While Jira is a powerful and popular tool, there are aspects of it that can at times become barriers to productivity rather than creating a smooth, easy-to-use experience—particularly for developers, who often have limited control over its layout compared to project managers and product owners.
I was tasked with finding some of these pain points and suggesting changes that could be made to improve developers’ experience using this software for their work.
After synthesizing the data from our research, I found that while users were accustomed to using Jira and had few major concerns with it, there were some themes in their complaints about the platform. Based on these themes, I put together a prototype of key features I would recommend that Jira change to improve developers’ experience.
Role
UX Researcher & Designer
Dates
June 17-23, 2024
Methods & Tools
Cognitive walk-through, contextual inquiry, digital prototyping, Figma, Zoom
The Problem
Understanding the platform
To identify and improve usability issues for software developers, I first needed to better understand Jira and how developers use it in their work.
I started by working with a team to complete a cognitive walk-through of some basic tasks on the platform.
Unsurprisingly, we found that Jira was well-built for the simple tasks we were testing, though for beginner users, finding how to complete each task took some clicking around to find buttons or settings among the many options on the screen.
Software developers using this platform on a daily basis do not face these beginner issues and would have no trouble completing these simple tasks. But the barrier of the quantity of information and options on the screen was a theme that carried through to issues developers faced using the platform.
Conducting a contextual inquiry with a software developer whose team uses Jira
To gather input from developers themselves, my team collaborated with two other teams to conduct contextual inquiries with 3 software developers who use Jira for their work.
The overarching theme of issues that came up in these conversations was that developers only needed particular information and functionality from Jira, but all the additional information and options available tended to crowd out what was needed for those basic developer tasks.
Speaking with users
“I do wish there were less buttons in my face…I wish it were cleaner…I’m noticing how much I’ve never touched on here…I don’t know what to do with those, what are these?”
“I wish that when I got an email [notification from Jira], it would be more clear what changed, it sends all of the details of the ticket…what was the actual change?”
Referring to additional detials included in comments:
“Not my job, don’t care.”
“The only time I come in here is when I need a new ticket…after that, I don’t look at it much.”
The Design
Jira is well-designed for project managers, but could better support software developers
Given Jira’s overall goal to facilitate project management for teams, it makes sense that the platform—and its ever-growing library of features—would be geared toward project managers and their needs. However, based on the findings from our research, I determined that this setup can at times become a detriment to software developers whose primary work is in programs outside of Jira. For these developers, efficiency and simplicity is key.
Designing a streamlined solution
Based on users’ feedback, I focused in on 3 specific areas of improvement to explore in prototyping for Jira’s platform:
Comments - adding more searching and scanning functionality for comments (and their corresponding email notifications), since comments are a key tool for collaboration that users reported to be difficult to sift through
View customization - expanding users’ ability to hide and customize the content on their screens to limit distraction and overwhelm from unnecessary buttons and information
Ticket modal - ensuring the “tickets” or “tasks” reliably open in a modal rather than a side drawer for better readability and limited extraneous information
“Comments can often be overlooked in Jira.”
“It would be nice if I could get rid of the other [views] that I don’t use.”
“I hate the side drawer.”
Adding features to make comments more searchable and scannable
Several developers pointed out issues with having to sift through extraneous information in long lists of comments (and their resulting notification emails) to find relevant information when collaborating with teammates. They wanted comments and comment notification emails to be formatted in a way that highlights just the important content, making it easier to scan past irrelevant details. They also wanted to be able to search comments.
To address these issues, I added the following features:
Gray backgrounds for comments to provide visual separation
A larger, bolded comment subject line to highlight key info from each comment (Jira already allows users to format text within comments, but the built-in subject line would encourage users to add summarizing content, providing a uniform hierarchy in comments that wouldn’t rely on individual users’ formatting efforts)
Tagging capability with customizable labels and colors to provide quick visual cues indicating the content of each comment when scanning—users could also search or filter by tags
A comment search bar
A comment filters dropdown, allowing users to hone in on relevant information
Making Jira’s modal view more reliable
“Issues” on Jira already open in a modal view, but users reported that they would also open in a “side drawer” that made it difficult to see all the content with everything else on the page. Users didn’t know when an issue might open in a modal or side drawer, but they preferred the modal view. So in my prototype, I chose to have issues open reliably as a modal.
Because our sample size of users was so small and there may be benefits to the side drawer view in some cases, this feature might be better offered as an easily visible option for users to toggle whether they want to see issues in a modal view or side drawer. The option is already available on some views in Jira, but not all of them.
Enhancing Jira’s layout customization features
All the users we spoke to voiced a desire to have more control over customizing their landing screens and removing unnecessary options and information that crowded the view. Jira already provides a button to hide the sidebar menu and to enter full screen mode, but the users we spoke to spoke to did not use (or potentially even know about) these features. So I added the following features to enhance customization and limit crowding on Jira’s landing page:
Made the existing “hide sidebar” button blue to make it more noticeable
Combined unused buttons on the right side of the page into one expandable “…” button (which also makes the “enter full screen” button more noticeable on its own)
Combined filters into one filters dropdown button
Created customizable accordion sections in the sidebar for developers to sort out and collapse the views they don’t use
My full prototype showing proposed my changes to Jira’s platform (see a video walkthrough below):
Next Steps
Future considerations
Given the small scope of my project and limited number of users in my team’s research, this project was more of a practice in challenging myself to improve on a well-built app’s design than an actual client-facing project.
However, if I were to actually work with Jira on improvements in the future, I do think these user issues would be important to consider. I would be interested in doing user testing for the features I suggested in my prototype to see if they would actually improve users’ experience of the platform.
A particularly important consideration would be the customization and variation of the design for different types of users. In my case, I was looking to better software developers’ experience. But their needs would differ from a project manager’s, for example. Considering different designs for different types of workers and increased customization options for all users (regardless of whether they have admin access to a project) could be strategies to address these varying needs.
A video walkthrough of my prototyped changes to Jira’s platform: