📣 Do you need Jira Fields with better UI? Having ideas how to improve Jira custom fields UI?

[Aga Szuta]

Hi there!

We’re exploring field rendering and would love to hear your stories about field customization.

Is there a field customization feature you’re missing? Would you like to change the look and feel of Jira to better suit your team’s workflow? This is your opportunity to let us know exactly what you need!

What are fields in Jira?

Jira issues are made up of fields. Some are built-in, like “Summary”, “Description”, and “Components.” Others you can add yourself - these are called custom fields.

Fields appear when you create, edit, or transition issues. They are also present on screens like dashboards, gadgets, and many more. Custom fields allow you to store information specific to your team's needs.



Sample fields marked in blue

Share your story with us!

What’s causing you pain when working with fields? What would you wish for in a magical ✨ world? 

How about different views? Do you need Jira Fields with better UI in dashboards, issues, search results or gadgets?

If the answer is yes, then let’s talk! Just email me at aszuta@atlassian.com

⏰ No time to meet? No worries, just leave a comment below. Any input on how we can improve the field UI experience in Jira will be extremely valuable.

Looking forward to hearing from you! 

Cheers, 

AGA

[Imrul Afshyn]

Hi Aga,

Regarding look and feel, if the all Sub-Tasks could have been displayed under Main Tasks within the Board View, it would have been really helpful.

You might see this kind of visual representation in Trello. If the same is followed within the Kanban board on Jira Software and Jira Work Management, it would help.

Thank you.

Regards,

Imrul Afshyn

Engineer Program Lead

WASP Ltd, Collins Aerospace

[Aga Szuta]

Hi,
Thank you for your comment; just to be sure we are on the same page, do you mean this kind of layout? This is a screenshot taken from Trello.

 

[Imrul Afshyn]

Hi @Aga Szuta 

Thanks for looking into this request on Sub-tasks' visibility on Task Cards within KANBAN board view.

I have used previous iterations of Trello pre-2019 - one where all subtasks were visible under on the main task cards as sub-headings. 

Sub-headings of any unfinished subtasks, would have been placed where you see the Blue Bars on this example.

This greatly helps with visual management of a Teams daily and weekly project activities. They get to know how much work is due behind a task package at a glance.

Thank you.

Regards,

Imrul Afshyn

Engineer Program Lead

WASP Ltd, Collins Aerospace

[Imrul Afshyn]

Hi Aga,

One other item regarding look & feel for Jira Work Management, is how the Tasks are shown under an Epic within the Timeline view.

All Tasks under a specific Epic are not placed under that Epic in the Timeline. Instead these are placed in order of their Creation date. This kind of defeats the purpose of a Gantt Chart / Timeline View .

Sincerely hoping your team could look into this as a matter of urgency.

Thanks again.

Regards,

Imrul Afshyn

Engineer Program Lead

WASP Ltd, Collins Aerospace

[Imrul Afshyn]

Hi @Aga Szuta 

This below is an example of issue we are facing within the Timeline view of Jira Project Management Template.

Tasks are shown in order of creation dates. These are not displayed under the relevant Epic bar.

This does not give the right kind of depiction of the project.

It would really help this could be fixed so that tasks would show up below the parent Epics.

Thanks again.

Regards,

Imrul Afshyn

Engineer Program Lead

WASP Ltd, Collins Aerospace

[Matt Smith]

Approvers:
At present it seems you can only select the approvers as "all required" from the approvers listed.

If you need just one approver from a list then there should be a simple option other than the "All required" such as "dynamic" X  approvals required.
X can be a chosen minimum defined at the approvers selection stage when creating the ticket.

X = 3 
List of 10.
Once any 3 of the list have approved then the approval is granted.

There is also the option of single approval required where one approval meets approval criteria.

The above will assist with failover for approval if parties are unavailable (A/L sickness etc.)
It also allows for majority consensus to be applied automatically.

KR,
Matt

[Aga Szuta]

Hi Matt,

Thank you for your comment.

To be sure, are we talking about a custom field in Jira Service Management type of projects?


 

[Keith Jones]

I would love better control over transition screens. For example, Most of our transition screens need just a piece of specific information - the Comment area is not needed and often just contributes to noise and/or confusion. 

[Cassie the Jira Mechanic]

AGREE! I get asked all the time to remove it.. and I can not : (

[Aga Szuta]

Hi Keith,

Thank you for your comment,

I guess the Comments field should always be present because a team wants to trace why specific tasks were moved. But that is my wild guess.



I'll pass this feedback to a team responsible. 

[Keith Jones]

Aga,

I think one of the reasons that some of us feel that the comment field isn't always necessary, is that the transition is controlled by the workflow. So if something is moving through the transition screen, the reason is related to the workflow, not an ad-hoc comment. At best, having the ability to hide it or minimize it for specific transition screens would be optimal. 

[David Holman]

The main problem I encounter with custom fields across orgs is the need for calculations.

I wish there was an easy way to create a field_c that is the result of values entered into field_a and field_b without having to resort to Automations. That's a hassle for simple operations.

[Anne Saunders]

Yep. We use a custom issue type to document project Risks, and we use custom number fields for the probability and severity, but then we need an automation to populate the calculated RPN field.

[Anne Saunders]

The "Paragraph" type of Custom Field has a description that states it supports rich text and markdown, but in use there is no rich text editor and classic markdown doesn't seem to modify text. 

It's a little thing, but it's annoying to believe I'll be able to use numbered and bulleted lists, text styling, etc., then discover that I'm limited to plain text.

The other "custom field" I'd really love to see are custom fields assigned at the project level, rather than the issue level. Let me use JQL to identify all of the projects where Katie is the PM, or Anthony is the lead dev, or the client has "Luck" in the name, etc.

[Keith Jones]

Anne - if I understand you correctly, this may help you with the first part - you can change the renderer to the Wiki style for a particular field within a project. https://qmetrysupport.atlassian.net/wiki/spaces/QTMJ/pages/720207914/How+to+set+Wiki+Style+Renderer+for+description

[Anne Saunders]

@Keith Jones THANK YOU!! You just made my Devs very happy :)

[Mike Aaron]

Hi Aga,

Actual fix https://jira.atlassian.com/browse/JRACLOUD-69877 would be great.

Thanks

[Cassie the Jira Mechanic]

A number field that doesnt have a decimal place and I can state character limit on!! Think banking companies or anyone with like account numbers we all have to use the short text but then cant validate number input well.

[Anne Saunders]

Regex-able number fields would be amazing.

[Yatish Madhav]

Hi thanks for this @Aga Szuta . You can see by my numerous updates/comments and a Support ticket as well on these. My kind of biggest itch is:

• https://jira.atlassian.com/browse/JRACLOUD-81315
• https://community.developer.atlassian.com/t/trying-to-edit-select-field-with-value-not-id/66258
• https://community.atlassian.com/t5/Jira-Service-Management/Trying-to-edit-select-field-with-Value-not-ID/qaq-p/2153992

Apart from that - I think perhasp a report of the custom fields would be awesome, esp for cleaning and maintaining fields. Eg no of custom vs standard vs connect app fields, accurately being able to remove fields from screens and from the instance (apart from Last used col), being able to validate and report on a single field and all of its values by project(s) and the instance, seeing when last a field was used on a screen/project, etc

Another odd one is radios, they work the same as single selects, so are they needed?

Then, seeing as we have 651 fields on Jira, I also wonder if Jira's performance is based on number of fields, in the instance, in a scheme and on a screen.

I also think the Create field window/flow can be a little cleaner. And would be brilliant if a field can be checked if there is any other similar field at all before a dup is created.

Thank you again. Looking forward to a a magical ✨ world of fields on Jira :D

Yatish

[Anne Saunders]

@Yatish Madhav When you say a report on custom fields, do you mean like utilization on which screens, the number of issues with a value in that field, etc? HubSpot offers something similar in the properties manager and I have found it really helpful in property cleanup. 

[Ben Ernest-Jones]

We just migrated over from Server to Cloud... being able to use Issue Layout on projects is useful and more flexible than Server... but:

1) I don't like that Issue Layout is "copied" instead of shared between projects... this is a different mode of administration than shared "Schemes" so it's just confusing to have more than one way of using the same admin settings across projects.

2) I miss the compact display of fields on Server... the line spacing is minimal and you can see more on the screen. In Cloud, the line spacing between fields is way too big and you can see a lot less.

3) I like tabs that we now have in Screen Schemes in Cloud, but in Issue Layout I'd like to have the option of more columns under the General list of fields. Even the option to at least have 2 columns would be nice to fit more into the view. In Server there used to be just "Resolution" and "Fix Versions" in a second column. It would be nice to configure in Cloud which fields we'd want across 2 columns in this part of the screen.

4) One field specifically... Story Points... it would be nice to either limit or at least indicate which values are acceptable. We have our pre-defined list of allowed values for Story Points... we have this in the description of the field... in Server it appeared under the field when creating or editing an issue. In Cloud it doesn't appear anywhere. And in Cloud you do have an (i) icon to get the description of a field in a tooltip, but for some reason it is not displayed for Story Points. Even better would be the option to make Story Points a drop-down of specific pre-defined values to choose from.

[Ben Ernest-Jones]

One more thing to add... specifically in the Mobile app, I don't like that the Details and More Fields sections of fields are displayed under Attachments and Linked Issues... it would be better to have General/Details/More Fields all stacked on top of each other, even if Details and More Fields start out as collapsed by default.

[Symantha Gates]

I'd like to suggest that Atlassian provide a UI differentiator when it comes to default fields and custom fields. For example, we have staff who across 200 projects have created 10 custom fields related to due dates - original due date, expected completion date, Due Date, target completion with date values in the picklist, etc. Truly the JIRA cloud system default is 'Due date' . I don't think anyone knew that was the default since the second d is lower case. Perhaps default fields are black and custom ones are blue to help users and admins differentiate ? Our reporting is now weak because the Due Date fields are inconsistently used and applied and it's a growing challenge to know what the default fields are in JIRA cloud.

[Tomislav Tobijas]

It's a 'small' thing, but it kinda bothers me from time to time - paragraph custom field labels, when placed on view/edit screens, have bigger font sizes (and possibly styles) compared to all other custom field types. We usually do need to place a combination of paragraph text fields and single-line fields or date fields on multiple tabs on the view/edit screens and that can sometimes look 'not-so-pretty'. Here's an example where Reminder field is Text Field (multi-line) type, and Reminder date is Date Picker field type.

[Anne Saunders]

This one is brand new today, but the Single Project Picker field seems to be limited to 50 projects. We have 75 open Client projects right now, without counting our internal projects, archived projects...Is there any way to expand the length of the list, or limit which projects can be selected (in this use case, I'd want to limit it to category=Client, for instance)?