Reimagining a core product experience used by millions of people: JIRA issue view redesign
Composable architecture for Jira's most-trafficked screen — keynoted at Summit, cited to investors.
Composable architecture for Jira's most-trafficked screen — keynoted at Summit, cited to investors.
Don't have the password? Get in touch
Lead designer across the full lifecycle. I paired on the usability direction and evaluation methodology in the early stages with a designer from Jira Service Desk, then created the conceptual architecture, built the strategy presentation, led the iterative rollout with a milestone-based feedback loop, managed a junior designer, coded the status transition animation personally, and defended the direction through three years of cross-product politics.
Jira's issue view — the screen where users view, edit, and interact with work items — was the most-trafficked surface in the product. And it was hurting. NPS feedback consistently cited complexity, clutter, and an outdated interface. Leadership made a strategic decision to simplify Jira, and research identified the issue view as one of three critical areas of focus.
The challenge was compounded by Jira's product suite. Jira Software, Jira Service Desk, and Jira Core all used the issue view, and each had taken an additive approach — injecting product-specific UI without a governing architecture. The result was a sprawling, inconsistent experience that confused new users and frustrated power users in different ways.
I developed a philosophical framework for what information belongs where on an issue. I split the issue view into three conceptual containers:
This wasn't just a layout exercise. It was a composability argument. If the issue view was architecturally sound, it could render anywhere — on a board, in a timeline, in a chat integration, in Bitbucket when a commit references an issue key. One component, many contexts.
I built a strategy presentation articulating this vision — including templatisation across product domains and the applicability of Jira beyond software teams. From what my manager and colleagues told me, this was seen internally as punching well above my weight. I was either a designer or newly senior at the time.
The strategy visuals were shown at Atlassian Summit 2018 in the keynote, where the bento box metaphor was used to communicate the design direction to thousands of customers and partners. The redesign was subsequently cited in Atlassian's Q2 FY19 shareholder letter, where the co-founders described it to investors: the redesigned Jira issue — "the core unit of work connecting tools, processes, and teams of all kinds" — making it easier for users to understand what's most important.
The initial exploration was deliberately divergent. I created multiple directions — exposed UI vs. collapsed, dense vs. stark — and tested them through a task-based usability methodology developed in collaboration with a designer from Jira Service Desk who brought rigorous measurement practice from usability theory.
We ran approximately four rounds of testing. The first identified a global maximum — which broad direction performed best. Subsequent rounds refined toward a local maximum, then stress-tested across the product suite and at varying data scales. Custom fields, workflow configurations, and the sheer flexibility of Jira meant edge cases were the norm, not the exception.
A late-stage curveball emerged when on-premises customers began migrating to cloud, bringing data sets far larger and more complex than typical cloud usage — laboratory equipment tracking, CRM-like custom field configurations, issues with dozens of fields. The architecture had to accommodate progressive disclosure at scales we hadn't initially designed for.
This was the phase I'm most proud of. Working with a strong PM and engineering manager, I built a milestone-based rollout system with feedback embedded at every layer:
Each milestone defined where we'd roll out next — by cohort and by product surface — and what needed to be resolved before progressing. The goal was 100% coverage and deprecation of the old view.
The central design tension in Jira is always the same: power users with dense configurations vs. new users who need simplicity. We encountered this directly when rolling out to the Jira Software board.
We'd shipped the issue view as a modal — it worked well on Jira Core boards with no negative feedback. On Software boards, the feedback was immediate: users wanted the side panel they were accustomed to.
Rather than react to what they had before, we segmented. We found that team leads viewed significantly more issues than individual contributors — they were grooming backlogs, unblocking work, moving between issues constantly. ICs were largely monotasking. The modal worked for ICs. Team leads needed the persistent side panel.
We shipped the ability to dock the modal as a side panel, then set smart defaults based on usage patterns — new users got the simpler modal, heavy-volume users got the panel. The feedback signal diminished with each intervention.
A similar pattern played out with history (shipped behind a chevron, moved to a tab when discoverability remained an issue) and with status transitions. Users had hacked their workflows — creating transitions that looped back to the same status just to trigger post-functions. Rather than punish this, I accommodated it in the new status dropdown design and proposed a dedicated actions capability, which shipped years later after Atlassian acquired an automation plugin.
One of my favourite details. I designed and coded an animation that subtly celebrated transitioning an issue to "Done" — not confetti, not a unicorn, just a considered acknowledgement. I pitched it within my working group at Design Week, who enthusiastically built out a heartwarming narrative around "making Jira care." I then prototyped the animation myself, and when I returned to my development team, we worked together to get it into production.
