Post-incident review for September 2025 change to status button location

[#1]

Hi everyone,

We committed in our recent update to JRA-96247 to sharing a public incident review of the recent change to the location of the status button on the work item view page on the web. While there was no downtime, we recognize the disruptive impact to our customers and take accountability for improving our release process.

Summary

We planned a change to the location of the Status control on the Jira work item view. The intent was to improve clarity by consolidating primary actions and declutter an area of the screen that mixed high and low frequency actions. After general availability, we heard strong negative feedback from many customers about increased friction and disruption to established workflows. We decided to revert the change and are revisiting the broader design approach.

✅ Current state: Change reverted and a new, more cohesive design direction is in progress.

Current experience

Proposed direction with consolidated actions on left side

Timeline

• April 2024: started developing work item modernization vision, initiating projects like threaded comments, redesigned child work items panel, and a new “Add” button.

• Nov 2024 - Mar 2025: Ran limited experiments in team-managed and company-managed projects with status button change that showed increases in user actions and new user retention.

• Jan 2025: Completed qualitative UX testing with both existing and new users of the new work item view, but status button location was not explicitly tested.

• June 2025: Made decision to proceed to general availability. Existing feedback from customers during experimentation phase was understated and internal miscommunication led to review steps getting missed.

• September 2025: Began rollout to all customers.

Impact

Customers reported difficulty locating Status quickly and more scrolling on longer issues. The change disrupted established habits and slowed team workflows, particularly for high-volume users and larger organizations.

What we got wrong

• We moved a core action without delivering a comprehensive layout change with appropriate benefits and communications

• We prioritized new user actions without sufficiently considering the impact to high frequency muscle-memory for existing users

• Early experiments didn’t fully represent enterprise usage patterns and work item complexity

• Our communications failed to consider the disruptive impact of this change.

What we've done so far

• Stopped the rollout and reverted the change.

• Paused all UI changes to the work item view to review the quality of our upcoming changes.

• Launched a thorough review of our work item view vision and roadmap.

What we're changing going forward

Area	Plan to address
UI updates	Deliver work item improvements in larger, predictable bundles with clear communication to customers and comprehensive customer value.
Enterprise customer feedback	Expand targeted reviews with large customers to validate usability for high-frequency actions.
How we test UI changes	Balance experimentation with longer opt-in feedback periods in Jira Labs and open beta periods to put admins in control of changes.
Change communications	Balance “what changed” with “why this helps,” provide clear opt-out/rollback context where applicable.

Our commitment

We’re committed to making sure Jira is the best way for every team to plan and track work. When we miss, we will listen, learn, and respond quickly. Thank you for the candid feedback—it makes our product better for everyone.

[Kate]

Deliver work item improvements in larger, predictable bundles with clear communication to customers and comprehensive customer value.

So happy to see this listed.

I think this whole PIR is a good overview of what users and admins have been communicating and I really appreciate that you have committed to working with us in future

[Slava Gefen]

Thank you @Dave Meyer !

One more important thing that wasn't mentioned is that it was released only for Jira Software users. Thus JSM users had to use both status locations: the new one on the left and the old one on the right.

[Mike - Dreamsuite Consulting]

Hi @Dave Meyer I love the accountability and transparency of this.  Kudos to you...

Rolling back is a strong move. After all, "what is the purpose of having a mind if you can't change it"

I do have a couple of questions (mostly out of pure curiosity)

• Was any prerequisite work carried out prior to the development beginning, surveys, focus groups with A-B mockups across new and existing users? (I ask because I have seen an increase across the board of companies making unsolicited changes to software then having to roll back due to complaints, this is not just an Atlassian issue)
• Modern day humans as a species (particularly adults) generally suck at dealing with change and excel at complaining.   I'm pretty sure a lot of the rationale behind the change was to ensure that Jira moves forward as a solution that is encompassing a new kind of audience with business teams.  This means it needs to be clean and simple for ALL.  Are you sure that by rolling this back, you aren't appeasing the existing users at the cost of widening the scope of Jira? 
• "He who shouts the loudest" and all that...Did you tally up the number of complaints from Jira admins v's users? 😂 (just stoking the fire for my own amusement) 

BTW, I wish the Trello team would publish a similar assessment of their recent changes to its users.

[Petr Gaikovich]

The root cause quoted is missing on What we got wrong paragraph:

Jan 2025: Completed qualitative UX testing with both existing and new users of the new work item view, but status button location was not explicitly tested.

Beautiful.

[Joe Johnson]

Thanks @Dave Meyer and the Jira team for listening and providing the PIR so quickly! Glad to see that the team have understood the challenges and are using this as an opportunity to do improve working practices.

[Graham Douglas]

-

[Bill]

Thank you for the positive steps of  listening to the community and reversing an unpopular and disruptive change.

If I could make one suggestion it would be to just leave the UI alone. The UI works for the majority of you customers, quit messing with it for awhile.

[Dwight Holman]

We feel like the decision-making process around the UI has been broken for some years. Not just this example. I cannot remember a UI change that has actually delivered a real benefit for my users. 

Rather than focusing on layout changes and tweaks for new users - the most common complaints from my experienced long-term users are:

1. That that Atlassian products are too slow. Feels like your customers have given up complaining about this, but we remain unhappy about page load times. 
2. Jira Search provides poor quality results - the fastest way to find what you want is to write JQL.

We would *love* to see some movement on these.

[Rebekka Heilmann _viadee_]

Thank you for treating this with the relevance that it had.

I still believe that this particular change was only the straw that broke the camel's back - after a long series of huge changes that were not managed or communicated well enough.

I discussed that with the research team in Barcelona: I would love to see some research done on the change itself in combination with the enablement materials. To check:

- Do we need the purple boxes?
- Is crucial information missing from the documentation (Admin and user perspective)?
- What are the FAQs?
- Does the change make sense / bring value to the users, once its put into context?
- ...

[Frank Kulla]

While i appreciate your honesty and self-reflective analysis about that (completely unnecessary) incident, i really must question your approach to simply relocate one of the most important ui elements. Sometimes i have the feeling that you don't work with those apps by yourself, otherwise i can't see how you thought that this was a good idea. And this wasn't the first time (like labels in Confluence for example).

If you want to declutter that to right area, you could just simply thought about what UI elements are the most used by your customers. And maybe ask us. In that case i for example would have told you that you could move the elements for "Feedback", "Vote" and "Share" into the three-dots menu, and move the elements for status, resolution and automation up into the fixed area where the "Watch options" and the three-dots menu already are.

This would even had created a real improvement: regardless how far down you have scrolled the right side area, the buttons for status and automation would have bee still usable (right now they simply vanish upwards out of sight...)

[Julia Foden]

Slightly off-topic but @Frank Kulla mentioned the "Share" button and we are talking about the work item UI and we've had a spate of renaming things . . . for me the thing that is crying out to be renamed is the "Share" button. Many's the time I've had to explain to users that Share just means 'send the person an email with a link to this ticket', and that if the recipient does not already have access then 'sharing' the ticket with them makes no difference. As Jira Admins we understand how permissions work so it's obvious for us but for users familiar with the Share button in Word, Excel etc this is very confusing.

Like others here I would be happy to see no UI changes for a while. But if you want to do one thing, rename Share to Send Link.

[Frank Kulla]

@Julia Foden I hear you... not to mention the "Shared with" function in the JSM frontend, that corresponds with the "Request participants" field in the backend. People permanently use the "Shared with" function like CC in emails..

But to be honest, that's more a problem of how we Atlassian admins teach our users. Still, a renaming would do wonders sometimes... Sorry for OT, had to let that out...