The New Development Panel Experience

[#1]

This blog post is for those of you who connect Jira to your dev tools and enable “Development” data to show up in the Details of your work item.

We’re constantly on the hunt for greater application speed and usability improvements. Our telemetry has show that Development data in this location was contributing to slower page load times. It also showed that the usefulness of the data varies across team members and their roles.

And so, we saw an opportunity to improve speed and usability. Here’s what the new Development Panel experience looks like.

The results?

• For pages with development information, loading time is now up to 700 milliseconds faster!

• The Development panel now has its own dedicated section, providing greater affordance, with added flexibility for each user to decide whether to keep it open or closed.

These improvements are being rolled out to you automatically right now. There is nothing you need to enable or configure.

The Development Context Group visibility is not manually configurable as the old Development field was. please reach out to support if you would like to opt back to the old experience. 

We want to hear from you

How does the new Development panel fit into your workflow? What would make it even better for your team? Please share your thoughts in the comments below.

For those of you who haven’t tried it yet - set it up and give it a try using this guide Configure development tools | Jira Cloud | Atlassian Support

Thank you for being part of the Atlassian community and helping us make Jira better for everyone.

[Tomislav Tobijas]

Hi @Carl Sowden ,

Seems like a good way forward 👌, but it's not quite obvious how one could 'turn this off.' For example, we now have a Dev panel on a couple of spaces where this is not needed, as these spaces do not use Dev tools at all. 👀

The first places where I've looked were "Features" and (work item) "Layout" under space settings, but this isn't configurable out there. Then I realized you could remove permissions from the permission scheme, and that would 'hide' the mentioned panel, but I'm not sure how to feel about this 🤔

At first glance, it seems like it would make more sense to be able to configure this on a space level (by space admin), and not something where Jira admin would need to intervene (when it comes to company-managed spaces)

Just my two cents on this, but it generally looks better than an old/previous experience.

Cheers,
Tobi

[Dave Mathijs]

Totally agree you with @Tomislav Tobijas

+1

[James Rickards _SN_]

I like the direction you are going with this @Tomislav Tobijas. +1 for being able to toggle Development panel on and off via the features settings menu for a jira space / project.

I'd add to it to suggest that each user should also be able to choose to show/hide that developer section.  Doing so would be in Atlassian's interest as it would reduce server load (and thus hosting costs), and in our interests as it'd keep the license costs competitive.

This could be achieved by simply remembering if the user toggles the panel open or closed. If the data in the panel is built Just In Time (JIT), then you don't need to pre-populate it for users who keep the tab closed. It hasn't rolled out to my instance yet, so I haven't been able to test if they thought of this already.

Default the tab to closed if there is no memory of the user's choice.

[Jason Wong]

Thanks for sharing your thoughts on this @James Rickards _SN_ , @Tomislav Tobijas , @Dave Mathijs 

I've been working with @Carl Sowden on this and would like to jump in and respond.

While the dev panel can't be individually set on/off, it can be expanded and collapsed.

There is a related feature request for an explicit setting on Dev data over here, based on the older design:

https://jira.atlassian.com/browse/JRACLOUD-96737 

We thought about how the new placement would perform in terms of relevance to the users who do use it, and those who don't and so it might be maybe worth mentioning the behaviour in a bit more detail,

On rollout of this change, we auto expand dev panel when there's dev data to display. However, if there was no dev data it will be defaulted to collapsed.

Once users click on the UI to expand/collapse, this setting will persist - on a per user basis.

Coupled with the faster page load time, hopefully we've improved the balance of preferences for users who would like it open and those who don't. 

Once its fully rolled out to all your team members, we'd love any more thoughts and feedback.

Thanks!

[Dave Mathijs]

Hi @Jason Wong Thanks for your reply.

As Jira is for all teams, and even when a business team has chosen a software space to track their work, I don't understand why you cannot simply show/hide panels from the Details of a work item.

Just like modifying the left side bar, one should be able to select the panels that are actually associated with a software space.

Is the expand/collapse setting of a panel in a work item kept in the user's browser cookies?

[Benedetta De Martino]

Very interesting!!

I'm not into a Dev Team, but I find it useful for dev who needs to keep track of their progresses and commits!!

[Josh]

I concur with @Dave Mathijs on the "Jira for all teams" line of thinking. If that's the vision, having a collapsed (but not entirely hidden) development bar for teams that don't develop software adds unnecessary complexity and UI clutter.

It's great for devs, but why make all non-devs have to see it?

[Milad S_]

This was rolled out to our instance, and I want to echo the feedback already shared: +1 as this is a great improvement; however, we need to be able to hide the panel. 80% of the work does not involve any development; Even within Dev/IT Support spaces, not all work types require this panel.

If they see something, they would click on it anyway and likely forget to click again to collapse it. Even if they do not click on it, it still conveys the sense that this is a tool for development teams. 

I hope you let us hide the panel at the work type/request type level. Perhaps the panel should be rendered only if the Development field is on the screen/request/issue type.

[Rune Rasmussen]

We noticed this the other day and said to ourselves "Well... That's a bit weird. Did we enable this? This Space doesn't do development work. I'm pretty sure it's always been turned off".

I fully applaud and commend the work and effort to improve page load time. Good work on that.
But I do not applaud or commend the ongoing "we know how you should work" attitude that Atlassian has been having for quite a while now.

Allow us to turn it off please.
In most of our Spaces this is not needed and only serves as clutter.

[Florian Ratz]

This was rolled out without warning to us ... so I had to pin all the items from "details" I actually needed and use my adblocker to hide the rest of the box because the development panel is now all the way at the bottom and required scrolling to view. 

Not a fan.

Glad it was rolled back now. 

[Jeremiah Fulbright]

Ah.. here we go again with a junk change.. I commend the speed up potential, but im not sure why that speed up can't be achieved with the existing Development collapsible that was inside of Details. 

This is causing our whole team grief cause it use to be easy to have a quick glance to confirm things were truly ready as well as quick review of what PRs.  

It now involves extra work of collapsing a panel to do a review of data, then uncollapse to continue updating other fields. (or scrolling back and forth.. similar to the Status button change that was inadvertently reverted after weeks of complaints)

Asking my Jira admin to reach out to support to request the old experience.

[Haddon Fisher]

I personally am ambivalent about this change from a "is this better" perspective - I'm not a developer in my day-to-day, and frankly this just isn't an area of the platform I engage with enough to have a valid opinion there. 

That being said....

• As is Tradition, the way I found out about this change was a user saying "hey why is this broken?". How is it 2026 and Atlassian still can't figure out a way to tell people when a change is coming before it comes?
  
  
• The two reasons given for this change were "we wanted to make this content load faster" and the ever-popular "we wanted to make this content more useful"...but nothing about how they got from these abstract inputs to the specific changes they made. How did Atlassian settle on this set of responses as the solution to the problem they identified?
  
  
• The specific feedback I got from the user was "Why can't I pin this set of information like I used to be? Its in this weird place now." This is feedback that a UX research team would have encountered in about 20 minutes of discussions with people who actually use the tool every day. How is it that Atlassian Product and Design are allowed to just YOLO this kind of stuff over and over? 
  
• I can't think of a single time Atlassian has ever rolled out a UI change and people did not ask for a way to opt out. I get that you want to encourage people to accept these changes, but asking people to contact Support to opt-out seems to be making literally everyone involved here suffer but the people responsible for this situation in the first place. Why is the UI opt-out not inherently always part of the plan? Why do these discussions get shunted to Support instead of allowing the people who keep making these terrible decisions to learn something?
  
  
• I don't want to say all of these problems have always been problems, but certainly since I was forced onto Cloud (so like 8 years now) it's felt like there's been no improvement on any of these. Why does Atlassian seem absolutely committed to not learning from past experiences?

[Jeremiah Fulbright]

I'm actually a little confused by this change as it actually goes totally against the blog regarding seasonal releases due to the horrendus status button change - https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/Coming-soon-Jira-seasonal-releases/ba-p/3177320

"Our intent is for all non-trivial user-visible changes to be included in each Jira release. We will continue to deliver bug fixes, performance improvements, minor cosmetic improvements, security updates, and infrastructure optimizations on a continuous basis."

This change definitely is non-trival and would fall into something i would expect in a seasonal release.

@Haddon Fisher you are spot on with the "How is it that Atlassian Product and Design are allowed to just YOLO this kind of stuff over and over?"

[tnolte]

I'll echo some others statements, and have already voiced it in other places. As a Developer that had these Development tools pinned so they would be at the top of my sidebar this was a massive blow to productivity and having to now scroll all the time to get to these fields. It's fine for this sort of change to be in place for other roles but to have prevented the ability to pin these fields like any other was a massive misstep for Atlassian. It does appear that some of this was rolled back but before doing these changes this should be rolled out in an Opt-In manner first so as not to disrupt teams workflows with sudden changes like this.