Kai Forsyth

Redesigning issues in Jira

After 12 years of serving bug tracking well, the most viewed screen in Jira needed a redesign to improve the scalability and extensibility needs of today’s Jira users.

The new issue design

The new design displayed inside of Jira Software.

Understanding the problem

The design of the issue view had evolved organically from Jira’s origins as a bug tracking tool. More features and functionality were added over the years as Jira expanded beyond software teams to build experiences for service (Jira Service Desk) and business teams (Jira Core), however the foundations of the original design, that was really only intended to track bugs, had still remained the same.

The issue view presented user interfaces for elements and features that were rarely relevant or helped users with resolving an issue. We knew from our user research that users found the design overwhelming and and cluttered; empty states and infrequently used features were too prominently visible.

Screenshot of the old issue design

How the issue design looked with the minimum amount of information required to create an issue.

There had been numerous design explorations of how these problems could be improved over the years. Ultimately, each attempt failed to execute because of a combination of:

  • the technical realities of building on top of an ageing legacy codebase
  • the challenges of satisfying both the user needs and business stakeholders of three very different Jira products (Software, Service Desk and Core)
  • the need to maintain identical experiences across our server and cloud offerings, and
  • the company’s appetite for the risk with investing in a project that would make changes to the most important page in Jira and was estimated to take years of engineering effort to complete

As people over the years started to have higher expectations for the user experience in enterprise software, the problems with the issue view became amplified even further in customer feedback and churn surveys – it was clear to the business that a radical redesign of the issue view was now required.

In 2017 three key initiatives came to fruition where it finally made sense to tackle the redesign of the issue view:

  • a revolutionary update to the visual design system of Atlassian’s products had just been released as part of the Atlassian Design Guidelines
  • there was an obvious need to transform the architecture of Jira’s legacy codebase, and
  • there was now a desire to move more aggressively from a self-hosted on-premises offering to a cloud-based software as a service model

As part of the redesign project, I partnered with another designer in Jira, alongside product management and engineering to see the biggest change to the most visited page in Jira in fifteen years. In my role I largely contributed to the visual design of the new interface and drove the design of a unified system for displaying issues across Jira. I also led the design, integration and developer experience for how our marketplace of third-party developers would build integrations within the new issue design.

The new design

In Jira, each product (Software, Service Desk and Core) provides templates that come with issue types. A software team might configure issue types like Story or Bug, whereas a service team might define issue types for IT help or Support request. These issue types drive the variety and flexibility of experiences with the new design.

The new design needed to support the diversity of work that people were using Jira to track and also empower Jira’s growth into more non-technical teams. As the information displayed on an issue can vary wildly, depending on the complexity of the work and how the issue is configured by a user or for a particular template, the issue needed to be scalable and adaptive. We needed a model for how the design would operate across multiple templates, configuration options and Jira products.

The design model

A number of different design models were explored, concept tested and benchmarked against competitors before arriving at the model for the final design. This early validation was driven by Daniel Kerris, my design counterpart on the project, before I joined the team.

The model for the new design is compromised of four concepts:

  • Foundational elements – these are the required elements in order for an issue to exist. It includes the issue summary and status, as well consistent actions for users to build out their issue further via the quick-add buttons or through object-level actions.
  • Description – the conceptual extension of the issue summary. This is where users continue to further describe out the work to be done. This can be done through a WYSIWG editor, but also through features like attachments, subtasks or even third-party integrations.
  • Context – the conceptual extension of status. Information that helps users get an understanding of the state of work through contextual information like priority, the assignee or reporter, due date, or custom fields. Context items can also be used as vectors for searching groups of issues across multiple projects.
  • Activity – events posted to, or taken on, the issue over time. This includes comments, but also revision history of fields or actions taken on an issue.

The model would adapt to all of the different places in Jira where the issue is displayed, including a single-column view in the backlog and inside of a modal dialog on the board. The model would also be reflected in Jira’s native mobile apps, giving users a familiar experience as they move across devices.

The new issue design on the board

How the design is displayed when a user clicks on a card on a Jira Software board.

The new issue design on the backlog

The design transforms into a single column layout in the Jira Software backlog.

A set of quick-add buttons appear at the top of every issue, a natural place where users can start to further describe their issue with features like attachments or subtasks, but also through third-party integrations.

Design of the new quick-add buttons

As every item of work in Jira has to move through a workflow, the new design elevated the status of an issue and unified the actions you can take to progress an issue into one simple and consistent interaction.

Animation of the status button

As issues can have many fields and context items configured, the model needed a way to scale. In the old design these items were always shown, cluttering the interface with irrelevant noise. The new design employed a “show more” button that would display all of the fields configured for an issue type when clicked. Once an item hidden behind show more was filled out by a user, it would always appear above the show more line. Users would also be able to configure the order of their items and set required items to always be displayed.

Highlighting the show more button

As the project would see us implementing the design entirely from scratch using a new frontend architecture, it meant that we had the opportunity to apply Atlassian’s newly updated Design Guidelines and redesign how low-level features and functionality worked on the issue. I took the lead designing a number of these features, including subtasks, linked issue and many more contextual fields.

The issue experience

Issues are the life blood of Jira and the experience of prioritising, planning, progressing and resolving issues spans a multiple contexts and locations. How issues were represented in search results, as subtasks, as links and in the backlog and board had all evolved with little thought, resulting in them all looking very different. We knew that the issue experience extended beyond the design of the issue view, and we knew we needed to deliver a unified system for how issues should be displayed and represented across Jira. I took on this challenge and led the visual design of the issue view and in addition to proposing a system for how issues should be displayed across the product.

Expanding from the cards that users had already known from the board, the system aimed to solidify the treatment of the card interface element in Jira. We believed that when consistently applied throughout the product, users would learn to know that clicking on these objects would always show the new issue view design.

A group of cards in a column

Similarly, when these cards were displayed inside of the grey well pattern, they would know that these issues could be dragged and dropped to manipulate their order. These cards would be used in on the backlog, in search results, on the issue itself and of course, on the board.

A group of inline cards

The system would also encourage the use of an inline create state, where new issues can effortlessly be created and added to an existing sprint or column on the board or the backlog. Based on the issue type, a user could also set the priority or assign and issue through an interaction from within the create state.

An annotated card showing the system anatomy

I produced a comprehensive set of guidelines on these cards for the product designers on Jira. The goal was for designers to not have to think about where and how information should be displayed on cards, and instead focus on answering what and why.

Shipping and measuring success

In parallel to our project, as part of moving towards Atlassian’s vision for the cloud, the company was heavily investing in building out platform features and functionality that would be used by product teams, like the team I was part of. The platform teams would build product-agnostic functionality like the WYSIWYG editor or the Atlaskit user interface component library that would then be used in products across Atlassian. This was a shift from how we traditionally built product, where each product was largely responsible for owning the design and technical implementation of whatever feature they were building.

The benefits of the platform were clear, users would get a familiar user experience as they moved through Atlassian’s products and product teams could focus on solving the problems that users hire their product for, rather than focusing on the intricacies of building a WYSIWYG editor, for example.

However, these benefits of course did not come without its challenges. As one of the first teams to be built entirely on the new platform, we spent a lot of time defining requirements and managing stakeholders across the numerous platform teams that we were dependent on. My role saw me working closely with Atlassian’s design systems team to ensure interface components were fit for purpose. I also designed and proposed my own contributions of new user interface components to the Atlassian Design Guidelines to support the new issue design.

As we started building towards the new design, it dawned on us that it would take several months for the new design to be built with enough features to replace the old design. We needed a way to validate the new design and get feedback from customers sooner.

We knew that rolling out such a significant change to users would be challenging. We prioritised the features we built based on usage analytics on the old design. Using our internal analytics, we were able to identify customers that primarily used the features we had already built and roll out the new design exclusively to these customers. This approach allowed us to get the new design to customers sooner and deliver improvements incrementally, rather than waiting until it was complete enough to replace the old design.

To measure the success of the new design as we rolled out, we designed a feedback loop that would see us collecting feedback via a form from within the new design, alongside instrumenting three key metrics:

  • clickthrough rate, where we designed a way for a user to navigate to the old design. Measuring how frequently a user clicked through to the old design allowed us to infer how often what we had already built was meeting the needs of our users.
  • opt out rate, users were able to turn off the new design in their user profile allowing us to gauge the overall satisfaction with the new design.
  • UMUX-Lite, a usability metric derived from a two-question survey that would be periodically asked of users who were using the new design.

Our rollout strategy meant that some customers had the new design enabled for them without all of the features they were expecting. On one hand, it was very useful for us as users vocalised the features that were missing via our feedback form and this informed the prioritisation decisions for what we built next. However, we knew we were degrading the user experience for some customers who relied on those features, forcing them to opt out or clickthrough to the old design. Based on our earlier releases we learned from our feedback that we could have done a better job at setting user expectations of the new design. We adjusted our approach in subsequent releases to better communicate what had changed within the new design.

Some feedback on the new design that was shared on Twitter.

As we rolled out the new design changes to more customers, the majority of users were generally satisfied with the new design, and our clickthrough and opt out rates remained low. There was a vocal minority of users who expressed a preference for the old design on the board, where issues had changed from appearing in a sidebar to a focused modal dialog; but the overall relative satisfaction with the new design was overwhelmingly positive.

Delivering the new design was a massive effort that spanned many months and brought new design challenges as we continued move forward. Throughout the project I hardened my product-system thinking skills and learned how to better quantify the impact of design changes. We didn’t get everything right along the way, but our pragmatic approach to building the new design meant that we could address problems quickly as they came up and ultimately, be more confident that what we had designed was better than the old design that had been with Jira for 12 years.


  • Brett Flower Design – management
  • Bruce Templeton Engineering
  • Daniel Kerris Design – product
  • Kai Forsyth Design – product
  • Taylor Pechacek Product management


February 2017 — June 2018



The information, views and opinions in this case study are entirely my own and do not necessarily reflect the views of Atlassian or its employees.