Often a customer will ask for a field to be added to a screen, when the field may be new or already exist. Regardless of whether the field is new or not, adding a field to a screen without thinking through all relative areas of impact can cause problems for both admins and users. As such, there are multiple considerations a Jira admin must keep in mind when adding Jira fields to screens.
Where the Screen is Used
Screens are managed not only as part of Screen Schemes and Issue Type Screen Schemes, but also within Workflow Transitions, so modifying a screen can change the overall user experience in multiple areas. Fortunately, reviewing a screen within the Screen tab (in the Administration/Issues tab) will show both the Screen Schemes and Workflows where a screen is used, so it is relatively easy to understand how changing a screen will impact the user flows.
For Screen Schemes (which build into Issue Type Screen Schemes), these are mostly used as part of the Create/Edit/View Screen functions, and so the user experience focuses on those three “views.” As described below, the order in which the Jira fields appear on the screen can impact how the fields are used. Furthermore, some fields only need to be part of the user experience in certain parts of the process (e.g. just when an issue is created), or just as part of the reference process (e.g. only on the View screen). Work with the requesting customer to understand when and where a field should and should not be available, and create appropriate screens, with an overarching guideline to limit the number of screens when possible.
Other Jira Fields on the Screen
Other fields on the screen may relate to each other or may pull information from each other, and so re/moving fields on the screen may impact the customer experience and needs to be understood. First, review each field on a screen, looking for any special or unique Jira fields that could impact each other. Look for fields that refer to each other (e.g. with description text that says things such as “see field below”) or special customized fields that actually pull data (hidden or not) from other fields.
Also review the entire screen and understand its place in the workflow. Sometimes screens exist just to track a very specific point of meta-data (e.g. a Resolution or Comment screen) in a specific point in the workflow, and should not have any new fields added to them. When in doubt, sit down with Jira Service Desk stakeholders or even super-users to review the specific point in the workflow where a screen is used to understand how changing it could impact the day-to-day operations.
Order of Fields on the Screen
Sometimes the order in which fields are displayed on the screen has different significance for the customer and end-user, as all or some of the fields on the screen may “tell a story” as the customer/requestor and end-user uses the screen. Depending on how work is done, different information may be entered in different order, and may even be collected or organized outside of the tool in a certain process. How the fields are organized on the screen is then very important to how your users interact with Jira Service Desk, so changing that order can have a direct impact on the customer experience.
Often, fields are collected with similar categories of meta-data organized into a subsequent list of requests. For instance, gathering the contact information for a potential vendor may list all the fields for that contact together: Vendor Name, Vendor Address, Vendor Phone and Vendor Email. In such a case, you wouldn’t want to add a new field in between those fields unless it directly related to that specific flow of information (Vendor Contact could go up front, while Vendor URL might go before Vendor Email, for instance).
Once again the key is working with your customers (project owners, stakeholders and agents) to understand the overall customer experience and how and where new fields might impact that experience. Don’t add new Jira fields in a vacuum; make sure you get multiple perspectives before changing the screens and schemes, and your customers will know that you have their best interest in mind whenever you’re making changes. You will also save yourself rework by not inadvertently disrupting someone’s existing workflow.
In Support of One Screen Per Scheme
Sometimes a Jira Service Desk project and its workflows have multiple moving parts and need to have many screens that reference all the difference points of interaction by the customers and agents. In those cases, it’s understandable to have multiple screens and schemes for each part of the Jira Service Desk experience.
However, sometimes a Jira Service Desk and overall user experience are small enough that all the fields needed can be tracked on one screen. In such cases it can be sufficient (and easier to manage) to create just one screen (call it the “Edit Screen”) to support an entire scheme (instead of all three Create/View/Edit operations). This is ideal for a screen that has fewer Jira fields (under 20 or so) that don’t require a lot of configuration and don’t change depending on the user’s place in the overall workflow. While larger projects with extensive lists of fields/workflows dictate the need for three screens per scheme (one for each operation), keeping to the one screen per scheme can reduce administrative overhead and streamline the customer experience at the same time.
Need help with more Jira Service Desk tips or any other Atlassian issue? Please feel free to view all of our Atlassian services, fill out our contact form or give us a call. As Atlassian Platinum Solution Partners, we have the expertise you need for any Jira Service Desk project.