Oracle Single Pane: one view for many Jira instances.

Single Pane lets you view multiple Jira Service Desk instances within a single user interface.

Gone are the days of keeping a separate tab open for each region. Single Pane consolidates issues from remote Cloud and Server Jiras into one place, so engineers can monitor system health without constant context switching.

I was the sole UX designer on an Agile team of three developers and a product owner. I was responsible for the overall design direction, while collaborating with the team on ideation. My work spanned:

• Product strategy.
• User research & analysis.
• User flows & stories.
• Persona creation.
• UI design & prototyping.
• Usability testing.

Ideally, engineers could manage tickets in a single system; however, requirements prohibit this. Engineers must review multiple Jira instances to monitor their system health.

• A history of missed tickets from monitoring multiple systems.
• An inability to correlate related issues across regions.
• Lowered customer satisfaction from slow engineer response on in-progress tickets.

To reduce or eliminate these issues, Oracle Single Pane provides a single place for OCI users to perform read-only Jira Service Desk tasks daily, independent of realm or region. Consolidating remote Cloud and Server Jiras into one interface decreases missed tickets and increases customer satisfaction by reducing response time on in-progress tickets.

The first step was to talk to engineers and understand the environment they work in and their needs. Before building user scenarios, stories, and personas, we needed to see how users reacted to the current experience. We asked about a dozen OCI engineers to follow tickets while we observed their behavior, and how they felt about each page or action required to follow active Jira tickets.

The interviews surfaced the common pains of a multi-Jira setup:

• Focus on one view to avoid context switching.
• No alert when tickets are created.
• The current flow does not support multiple regions.
• A lack of cross-references between issues in different Jira sources.
• No mobile version.

These key insights defined the launch of the MVP version of Single Pane:

• The current flow does not support multiple regions.
• Users need information to be highly scannable and simple to navigate.
• Information overload affects users monitoring multiple systems at once.
• One dashboard per region means up to six tabs open at a time.

User research and persona creation surfaced users' main needs, goals, and behaviors. The main issues my design decisions needed to solve were:

• Focus on one board to avoid context switching.
• Alerts and notifications.
• The ability to filter & sort data.
• The ability to manipulate data (add and remove).

Filtering and sorting was the hardest section of the platform in terms of experience and design.

I created sets of specification docs to communicate requirements to engineering. These deliverables consisted of customer journeys and the design system — informing typography, attributes, size rules, button sizing and behaviors, hierarchical content organization, iconography, measurements, spacing, and styles for all patterns.

The new approach eliminated the "flowchart" feeling of previous designs. Earlier, arrows on the time blocks produced a flowchart effect rather than a timeline, and the arrow direction implied the wrong reading order — we wanted to represent time moving left to right.

Circles with a number represented the number of changes, separating the two most important pieces of information: time and changes. Discoverability was an issue, though — many users didn't understand what the number inside the circle meant and had to hover to see the "Changes" label.

The goals of the test were to:

1. Evaluate whether OCI engineers can complete key tasks within an optimal success rate.
2. Identify whether key patterns are missing in the interaction flow.
3. Determine whether users exhibit anxiety, confusion, or frustration during their journey.

The HTML prototype exposed usability issues straight away. The process became less time-consuming because small changes no longer took hours to rectify, and the code was completely reusable when it came to the production stage.

The design was created to be responsive — fluid and adaptive to the screen size. Rather than a "mobile first" design, it's a "responsive first" design: not built for one specific screen size, but to adapt to any.

The goal was to release a tool that eases the burden for on-calls by providing a consolidated view of multiple Jira Service Desk instances. We wanted to onboard multiple teams, then request feedback and review metrics to learn about the tool's performance before moving to the next implementation.

Learnings & next steps after the MVP release

The main problem was users expecting an overview of the data (data visualization). Technical constraints meant we had to substitute pagination for infinite scrolling — which still impacted record navigation.

Next steps were to test the live implementation with users, investigate an alert system, and explore data pagination. I also explored how to add more value to the data visualization by making it more informative, interactive, and engaging.