Enable request forms in Jira Issue

When work goes missing, it can’t be “Done”

Every day, millions of tickets are created in Jira to track bugs, requests, and critical tasks across teams. But some slip through the cracks - invisible, untracked, and unresolved. Ultimately, it leaves customers hanging.

This case study shares how I led design explorations to uncover and fix this problem. Working within the constraints of legacy architecture, I focused on identifying the root cause, aligning teams, and designing a clear, scalable solution that ensured incoming requests would never disappear again.

OVERVIEW

The scale and cost of an unmapped ticket

Of those millions of tickets created in Jira Service Management (JSM), and of those created via the global issue creator, over half of tickets were not mapped to a request type. This had two major downstream effects:

1. These tickets bypassed categorised agent queues, making them easy for Team Leads’ to miss.

2. They were invisible to the original requester in the customer portal, eroding trust and transparency with the company’s brand.

This was beyond a UX issue, it was impacting agent efficiency, service quality and customer satisfaction at scale.

Before and after

Before: The dropdown combined issue types and request types into a single select list, an oversimplification that hid important distinctions and introduced friction into the workflow

↓

After: We redesigned the dropdown to align with the mental model of agents, separating out request types and making the mapping step more intentional.

DRIVING DECISIONS

Investigating blackholes in agent workflows

To understand why tickets were disappearing, I investigated how agents were using the issue creator day-to-day. I partnered with the PM to analyse usage data and customer feedback, which helped us distill the problem into two key causes:

• Unique request type setups across teams, that sometimes needed requests unmapped.

• UI that didn’t make the mapping process clear, thus leading to user error.

We needed a solution that reduced user error without disrupting existing workflows. I established clear experience principles of simplicity, intuitiveness, and reliability to guide the design. Since the issue creator is one of Jira’s most widely used surfaces, any change had to respect that scale and familiarity.

Bridging the architecture gap where users get lost

I started by mapping key touch points through the lens of the Jobs to Be Done framework, focusing on what each user was trying to achieve, from workflow setup to ticket creation and submission. I wanted to understand where ambiguity crept in, and why.

What I uncovered was a fragmented experience. Entire flows had been designed by different teams at different points in time. Some were deeply embedded in legacy architecture, while others had been built on a modern tech stack. The result was an inconsistent system experience that made it hard for a team to completely comprehend the cause and effect of their setup.

Turning system maps into shared momentum

To make this visible, I created a systems artefact that highlighted gaps between product surfaces, this also helped me identify critical patterns. This became a strategic tool to show the product systems that mattered to stakeholders, and the request details that mattered to agents. So the designs I proposed focused on:

1. Increased visual emphasis on the request type dropdown to reduce selection errors.

2. Inline form rendering to give users immediate context and clarity before submission

Because the issue creator is monolithic and central to Jira’s core workflows, changes were subject to high scrutiny. I partnered closely with engineers and PMs across both JSM and the Jira Platform to assess constraints, mitigate risk, and scope a safe path forward.

The final solution was isolated to JSM projects, using conditional logic and feature flags to protect platform stability. Guardrails ensured backward compatibility and prevented regression across non-JSM experiences.

POST-LAUNCH

Impact

After progressive rollout reached 100%, we saw unmapped issue creation dropped by 45%, significantly improving:

• Agent visibility: requests were more accurately routed into triage queues

• Customer transparency: users could now track their tickets in the portal

This uplift validated that the issue was indeed rooted in UX ambiguity, not just user intent.

What I learned

While the UI changes appeared simple on the surface, this work required significant alignment behind the scenes. This project reinforced some design lessons I keep returning to:

• In high-frequency workflows, clarity is a performance multiplier.

• In legacy systems, even incremental change demands cross-functional trust.

• And when done right, platform UX can quietly unlock enterprise scale.