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 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.
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:
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.