Enable request forms in Jira Issue

Enable request forms in Jira Issue

Role
Design strategy, platform systems, components
Duration
June 2021

Context

Over 65% of tickets created in the global Jira issue creator are unmapped to a request type. The implications are twofold:

  1. Requests do not appear in the categorised queue.

  2. These requests do not surface in the customer portal.


Problem

For agents, tickets can get lost and be hard to track. This causes failure to solve the request. But we also know that some agents deliberately want an unmapped request type. For customers making the request, they have no visibility when accessing the portal.

[Before] issue types and request types lived in the same select field.

Implementation

We believe the current UI experience is causing user error. Our solution would be a stepping stone between now and our future state. We decided to make selecting request types more recognisable, in addition to rendering the request form inside the issue creator. Considering the Jira issue creator covers all Jira projects, this dropdown option would only appear for Jira Service Management projects.

[After] we made request types it own select field


[After] the dropdown menu allows more context into what the request type is


Impact

After implementation and release, we saw unmapped issues drop from 65% to 20%. The drastic change in numbers was very encouraging to all team members involved. We knew that we were on the right path for our future vision.


Note

This project was very technical. A small change can be complicated due to the monolithic code in the Jira platform. Introducing any UI changes was also risky because creating issues is a high-frequency task for agents. This can be very disruptive to their everyday workflow.

Role
Design strategy, platform systems, components
Duration
June 2021

Context

Over 65% of tickets created in the global Jira issue creator are unmapped to a request type. The implications are twofold:

  1. Requests do not appear in the categorised queue.

  2. These requests do not surface in the customer portal.


Problem

For agents, tickets can get lost and be hard to track. This causes failure to solve the request. But we also know that some agents deliberately want an unmapped request type. For customers making the request, they have no visibility when accessing the portal.

[Before] issue types and request types lived in the same select field.

Implementation

We believe the current UI experience is causing user error. Our solution would be a stepping stone between now and our future state. We decided to make selecting request types more recognisable, in addition to rendering the request form inside the issue creator. Considering the Jira issue creator covers all Jira projects, this dropdown option would only appear for Jira Service Management projects.

[After] we made request types it own select field


[After] the dropdown menu allows more context into what the request type is


Impact

After implementation and release, we saw unmapped issues drop from 65% to 20%. The drastic change in numbers was very encouraging to all team members involved. We knew that we were on the right path for our future vision.


Note

This project was very technical. A small change can be complicated due to the monolithic code in the Jira platform. Introducing any UI changes was also risky because creating issues is a high-frequency task for agents. This can be very disruptive to their everyday workflow.

Role
Design strategy, platform systems, components
Duration
June 2021

Context

Over 65% of tickets created in the global Jira issue creator are unmapped to a request type. The implications are twofold:

  1. Requests do not appear in the categorised queue.

  2. These requests do not surface in the customer portal.


Problem

For agents, tickets can get lost and be hard to track. This causes failure to solve the request. But we also know that some agents deliberately want an unmapped request type. For customers making the request, they have no visibility when accessing the portal.

[Before] issue types and request types lived in the same select field.

Implementation

We believe the current UI experience is causing user error. Our solution would be a stepping stone between now and our future state. We decided to make selecting request types more recognisable, in addition to rendering the request form inside the issue creator. Considering the Jira issue creator covers all Jira projects, this dropdown option would only appear for Jira Service Management projects.

[After] we made request types it own select field


[After] the dropdown menu allows more context into what the request type is


Impact

After implementation and release, we saw unmapped issues drop from 65% to 20%. The drastic change in numbers was very encouraging to all team members involved. We knew that we were on the right path for our future vision.


Note

This project was very technical. A small change can be complicated due to the monolithic code in the Jira platform. Introducing any UI changes was also risky because creating issues is a high-frequency task for agents. This can be very disruptive to their everyday workflow.

Want to team up or learn more about my process?

💌

hello@jenifferheng.com

© All rights reserved ·
Last updated April 2024

Want to team up or learn more about my process?

💌

hello@jenifferheng.com

© All rights reserved ·
Last updated April 2024

Want to team up or learn more about my process?

💌

hello@jenifferheng.com

© All rights reserved ·
Last updated April 2024