nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rethinking Issue View Field Configuration

Ahmud Auleear

Hey Admins,

We've heard consistent feedback that the Issue View can feel cluttered and overwhelming, making it difficult for people to efficiently find and update field. Too many fields, disorganised layouts, and excessive empty fields contribute to cognitive overload for users, while admins face complex processes to configure the Issue View to suit their ICs' workflows.

While we're still in the early stages, we're exploring ways to make the Issue View simpler and more intuitive.

We are considering ideas such as inline editing from the Issue View, removing the need to access configuration screens and enabling real-time adjustments. We're also streamlining field grouping by combining some fields and empowering end users to personalise their views without impacting others.

I've uploaded a high-level concept that is not validated but rather a concept to help you envision a potential solution.

Screenshot 2025-01-15 at 1.48.08 PM.png

If you have any feedback, positive or constructive, or would like to discuss this problem further, I'd love to connect via Calendly.

Feel free to leave a comment as well!

Thanks,

Ahmud

Comments

Tim Eddelbüttel

Just my 2 cent...

Add theming support to Jira
Make it available for app developers.
Create a "Jira Classic" theme

Problem solved as you will never satisfy everyone as there is no one view fits everyone!

Dirk Ronsmans

Hi @Ahmud Auleear ,

Great that this is becoming an area of interest.

Looking at it from a JSM point of view there are some major enhancements possible imho.

Not linking Request Type configurations to Screen configurations would be one, as not all customers use request types (or even a portal) and even if they do, having something in a certain place on a request type doesn't mean it needs to be front and center on a issue type screen.
Having empty fields in the same location as when they are filled in
actually respecting the order of the screen configuration

I'll look at scheduling a call with you to discuss in more detail!

Flavio Di Transo

My suggestions:

add the possibility to move or remove some unwanted default field like "Issue linking" from the bottom of description section
give the possibility to change the sections layout (like in confluence page)
give the possibility to arrange the add-ons panels in the description section

Nicolas LAISNEY

Hi,

I am not really convinced with the ability for each user to customize its own view. In a team, having the same configuration helps discussion (and in companies where documentation exists, screenshots shall preferably reflect the screens...).

From my point of view, one of the key issues with the issue view is that some fields can not be disabled or layed out (grouped, ordered...) according to our needs. This issue also goes with the overall JIRA side bar, where it is not possible to have control over all items (I would like to hide Goals, some plugins...). Some just cannot be controlled.

Benjamin Lentz _KUMAVISION AG_

Hey,

i want to underline especially the first part of the comment. Standards are helpful and needed for us, every user configuring their own view would be a support and learn problem.

So if you plan to introduce this, please use team-managed projects for it or give us the possibilty to deactivate it globally / on project level.

The possibility of grouping different fields via scheme would be interesting as well.

Thanks for your ongoing improvement of jira and the possibilities.

Best regards,

Benjamin

Dave Meredith

I like the idea of being able to arrange / view / hide according to individual user preference.

However I'd like to make sure there is some form of 'Reset to default view' functionality.

I create standardized Request Forms (In a request type this is the Customer portal view), Forms, View Screens with tabs and Request Type layouts that group relevant information based on the type of work to try and make the UX intuitive for the user. If users can pin, move, hide fields that are needed for the workflow, supporting them is going to be very difficult to even find that field on the screen.

Side Note: I like having standard layouts for Request Types but if I need to add a field to one Request Type, I then need to add it to 49 other similar request types because there is no shared templates for Request Type layouts which is not a good use of my time...

Also, any field that gets placed on the Request Form (Customer portal view) gets moved from where I placed it in an Agent View Screen or Request Type layout. Putting that field in a Form instead stops this behaviour but you don't always want to attach a form.

Then there's the differences between UX and functionality in the agent transition screens...

Thinking it through the UX of Customer / Agent views seems VERY disjointed and difficult to create a standard experience.

</ramble>

Ben Ernest-Jones

There are already several tickets entered for Jira Cloud about reducing white space between fields... that alone would help quite a bit to see more at once without scrolling.

Also what would help with that is to allow at least 2 columns of fields on the main page at the top when viewing an issue. That's generally a lot of wasted space that could be better used so that you can see more information vertically.

Rune Rasmussen

Firstly, I think this could be a neat addition. There is something similar already in Software Projects.
I expect this would apply to all projects no matter the type.
Would it also be possible to export/import these customizations, or share them between users?
This could greatly save time in cases where multiple teams work in the same Project, by giving each team their own "baseline" of what's shown and what's hidden.

But I ultimately don't think this will resolve the problem you are trying to address.

The thing that has caused a significant amount of clutter for us is that when a field is added to a screen, it is also added to the layout of any Issue (or request) type that uses the screen.
Doing something about this behaviour would (from our point of view) do much more to resolve the problem of clutter with too many fields.

If I were the king and queen of all cheese, I would want both.
The new feature proposed, and for fields to not automatically be added to the Issue/Request layout when they are added to a screen.

I wanted to book a feedback session, but the hours seems to range from 00:00 to 07:30 CET, which is when I get my beauty sleep.

Rune Rasmussen

Agreed.
It often feels like Jira is built for a low resolution 4:3 monitor.

Ashley_y947oq

Awesome!

Listing out some things I'd love to see:

being able to change the description of a field based on issue type within a project (will be useful for unifying/consolidating projects and having useful/valuable helper text)
masking field names on issue view as you can also mask the name on the customer portal (will be useful for custom field management)
may be beyond scope but masking status names on issue view as you can also mask the name on the customer portal

Mathew Lederman

While I appreciate the desire to improve the Issue View for all projects, I think you need to fix what is broken today with issue views. JSM projects do not have access to the Issue Layout and don't respect the configuration of the View screen (tabs, field order, etc).

For my enterprise service desk with 1000 agents that all share a single sub-task issue type, this means 1 giant list of fields in the Context pane that usually only show when data is populated, and about 5 fields in the Description pane that are only applicable to 1 team but cannot be hidden when empty.

Please fix broken items before looking to implement new changes.

Symantha Gates_v9yyuq

Some kind of dynamic schema for JIRA admins would be useful so they could "skin" the issues - for their tenancy and their projects.

JIRA does not provide information about default and custom fields - this would be super useful to users and to admins (https://community.atlassian.com/t5/Jira-Cloud-Admins-questions/Project-admins-How-do-you-find-all-fields-used-in-your-team/qaq-p/2738812).

If there were a metadata schema screen available to JIRA admins, we could have a base + variable configuration. For example, JIRA admins select a collection of fields as the base configuration for all issues and then each project adds a collection of other fields to allow customization of the project's fields.

Anne Saunders

I agree with not allowing all users to customize their views - there are custom fields we use for reporting and display on cross-functional teams' boards and dashboards that we need people to complete.

It might be cool to attach views to project roles or groups. My executives have different needs than the project managers or devs (and we're a small shop, so they do get in there some!) and the PMs would probably prefer different fields be given priority.

Leonard Hussey

Things I'd like to see:

1. per-user field space selections: Default, Cozy, Compact -- there is a lot of free space between one field and the next. Some screens feel like we need to scroll forever. Especially on information-dense projects

2. inherit some of Confluence's visual options:

- layout: be able to split a section in two or three columns with embed-able contents

- expand: be able to embed jira fields into a section that can be collapsed and allow it to be set with a default status: collapsed or expanded

- tables: be able to embed jira fields into a sort of table-like layout.

I have a very specific need for the last one. I have 5 stages in my ticket flow, each stage has 6 fields for different pieces of data of the stage. This is 30 fields one below the other. Info is needed by service managers to have a clear view of the ticket progress. Arranging these in a table-like structure (which allows columns and row headers) would be great. Sort of like below:

Stage   | Header_1  | Header_2  | Header_3  | Header_4  | Header_5  | Header_6
-------------------------------------------------------------------------------
Stage 1 | Field_1_1 | Field_1_2 | Field_1_3 | Field_1_4 | Field_1_5 | Field_1_6
....
Stage 5 | Field_5_1 | Field_5_2 | Field_5_3 | Field_5_4 | Field_5_5 | Field_5_6

above, "field_x_y" means to show the actual value of the field. This would achieve better visualization and data condensation.

Symantha Gates_v9yyuq

Agree, this would be super useful. JIRA is really good at pulling us right down into the weeds of the story.task to support developers. This type of thing would help the dev/eng manager, the scrum master, the product owner who are looking at work more cross functionally and across more than one project.

François Dumas

I also would really like to book a feedback session as I have many ideas and opinions on the subject but no slots are suitable for my timezone. Any possibility to arrange a slot outside of what is available in Calendly? (I did that a few months ago with another product manager regarding Issue List view 😉)

Lasse Bencke

The changes you mentions sounds great and I only got one wish:
Please make it configurable and possible for the admin to enable or disable it.

Lara Bailey

A few people have already pointed out the various problems with allowing users/agents to customize their views. If you do proceed with allowing this, please have a toggle to allow users to go back-and-forth between their custom view and the default view.

Personally I made a tab for each part of a ticket so that people who are involved in only some parts can select that tab and see what they want. I also use a read-only field (and automation to update it) to allow an important field to appear in more than one tab.

Tabs allow me to keep the minimal number of fields on the right-hand bar, so the view is clean, while also allowing more detailed per-task/role views.

Note: whatever tab you have open on one ticket, it automatically opens to the same tab when you open a new ticket. This is great.

Given we have tabs, I'm not sure adding groups would improve functionality or just add further complications - more things to maintain, more things to setup, and get right.

Bert Bingham

The most important parts of interacting with issues from a user perspective is either inline editing, or transitions. The inline editing on Cloud seems fine, and improvements to make it closer to WYSIWYG are always welcome.

For transitions however, Cloud seems to have taken a big step back from Server.

For any given issuetype, there are generally only 2-4 transitions that make sense to promote to our average user so they aren't overwhelmed with complexity, and I don't expect any two projects to have the same set of transition names or priorities.

On Server this was solved by including an opsbar, which allowed me as an admin to adjust the order those transitions were presented to users, with the most important or encouraged few appearing first, and the remaining transitions being dumped into a pulldown menu that was sorted by whatever method the admin felt was best (for me it was the expected or encouraged frequency of usage).

As it is now, everything is dumped into two arbitrary pulldowns, one for status updates, and another for actions, so we are essentially forcing users to hunt for a transaction among a sea of them rather than presenting the optimal ones on a silver platter.

Sarah Wright_gz218r

As one issue often has to serve up information to many personas -- product owner, developer, qa, project manager, stakeholder, release manager, compliance, etc. -- having what could effectively replace tabs that is customizable at a level that is not Jira Admin could go a long way towards minimizing the user fatigue.

As an X, I would like to be able to focus on the fields most relevant to my needs in the issue lifecycle.

Imagine a creating a filter that has all the fields/columns you are interested in then using that to dynamically create issue detail views. Wait, maybe these filters just become quick filters that pull the fields in the filter into the top and move other fields to a collapsed section. Also I think I am heavily influenced here by Big Picture's view settings. I can create a view and elect to share or keep private.

(I hear the support arguments and challenges this could create so include a great big DEFAULT VIEW button somewhere so it becomes as common to say as 'have you tried turning it off')

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

issue-view

field-configuration