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:
Requests do not appear in the categorised queue.
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 to track their tickets 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
Approach
The first step was to unify the representation of how request types appear through out the various touch points within the product. Our future vision is to decouple the Issue type and Request typing mapping. Just only show request types to agents. However this has complications due to the underlying 'workflow configuration' logic. Basically, it's opening a can of worms.
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:
Requests do not appear in the categorised queue.
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 to track their tickets 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
Approach
The first step was to unify the representation of how request types appear through out the various touch points within the product. Our future vision is to decouple the Issue type and Request typing mapping. Just only show request types to agents. However this has complications due to the underlying 'workflow configuration' logic. Basically, it's opening a can of worms.
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:
Requests do not appear in the categorised queue.
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 to track their tickets 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
Approach
The first step was to unify the representation of how request types appear through out the various touch points within the product. Our future vision is to decouple the Issue type and Request typing mapping. Just only show request types to agents. However this has complications due to the underlying 'workflow configuration' logic. Basically, it's opening a can of worms.
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 June 2024
Want to team up or learn more about my process?
💌
hello@jenifferheng.com
© All rights reserved ·
Last updated June 2024
Want to team up or learn more about my process?
💌
hello@jenifferheng.com