Single Pane

I have omitted and obfuscated confidential information in this design case study. All information in this example is my own and does not necessarily reflect the views of Oracle.

Image shows a representation of Single Pane.

Centralize System

Consolidate issues from Server Jiras into one view.

Project Details

  • Company: Oracle
  • Product: Tool
  • Year: 2019
  • Tools:

Project Summary

Single Pane allows you to view multiple Jira SD instances within a single user interface. Gone are the days with a tab for each region(s).


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


  • History of missed tickets due to monitoring multiple systems.
  • Inability to correlate related issues across regions.
  • Lowered customer satisfaction due to slow response of engineers on in-progress tickets.
User ends with too many tabs open.
User ends with too many tabs open.

To reduce or eliminate the above issues, Oracle Single Pane provides a single place for OCI users to perform read-only Jira Service Desk tasks on a daily basis, independent of realm or region.

Image shows a representation of Single Pane.
Single Pane.

My role

I was the sole UX designer on an Agile team comprised of 3 developers and a product owner. I was responsible for determining the overall design direction of the project, while collaborating with the rest of the team on ideation.

  • Product strategy
  • User research & analysis
  • User Flow & Stories
  • Persona creation
  • UI design & prototyping
  • Usability testing


The first step was to talk to engineers and try to understand a little more about the environment in which they work and to learn more about their needs.

Before we could start working on the user scenarios, stories and creation of personas for this project, we needed to see how users reacted to the process of the current experience. We asked to, approximately, a dozen OCI engineers, to follow tickets while we observed their behavior. We also asked how they felt about each page or action that they had to do to follow actives Jira tickets.

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

  • The current flow does not support multiple regions.
  • Users need the information to be highly scannable and simple to navigate.
  • Information overload affects users when monitoring multiple systems at the same time.
  • One dashboard for each region (up to 5 tabs open).
"You have to update the 6 dashboards at the same time to keep them synchronized".

Next, I created a provisional persona of a potential user based on PM knowledge and my understanding of the user. This persona was created with assumptions and not fully research-based but it was something that I came back to throughout my project to guide my design decisions and priorities.

OCI Engineer Persona

User Stories and MVP

User research and persona creation brought up the users' main needs, goals, and behaviors. Therefore, I found that the main issues my design decisions needed to solve were:

With goals in mind, we defined the design expectations for the 3-week design MVP project:

  • Focus on one board to avoid context switching
  • Alerts - notifications.
  • Ability to filter & sort data
  • Be able to manipulate data ( add & remove)

Based on this information, I was able to create user stories and define the MVP.

User Stories and MVP.

User flow

Next, I’ve created a user flow diagram to map every step of the user interaction required to achieve the main goal of this tool. Consolidate issues from Server Jiras into one view.

User flow.

customer journey map

Connecting to the Chicago and Phoenix regions

Lo-fi prototype
Lo-fi prototype.

Lo-Fi Prototyping


First login of the day, we present users with the list of available regions to pick from.

This step is only presented after the session has expired, which lasts 24 hours. After that, we ask users to pick the regions again.

Lo-fi prototype
First step: Connect to regions.

Pain point: The user needs to connect to Jira for each region.


Dividing the regions into Realms reduce the necessity of selecting each region. Picking a Realm connects you to the regions associated with it.

User can connect manually if one of the regions fail. If the user is not interested in that region doesn't need to do anything about it.

  • OC3 (Realm)
    • Ausburn (region)
    • Phoenix (region)
    • Chicago (region)
Solution for selecting regions
Solution for selecting regions.

Using Single Pane

After connecting to Jira SD regions user can view My issues or My projects data from the main page. Based on our user interviews the following records are the most useful data that we can provide for optimal use of the tool.

Records to show on the table after connection.

Designing the tool


We wanted to put the things that mattered most for the MVP.

Displaying data - Issues and Projects . Issues include users as a Watcher, Reporter or Assignee. Projects show tickets from the user’s projects that haven’t been assigned. Manipulating data - Users need the ability to organize the content according to a certain parameter.

Design challenges

  • The platform has to work on its own. That means that engineers should be able to look at it and understand what they can do with it.
  • Since OCI engineers would be able to use the platform anywhere, they should do so on desktop and mobile devices. How is the platform going to provide the same value on larger and smaller screens?
  • I had some issues understanding some 'technical words' used in that particular industry so I had to educate myself to design the experience of the platform.

Filtering & Sorting Data

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

Filter by.

First round: The Filter Bar

For the first round, due to the number of records to filter by, I decided to add a Filter Bar composed of an expandable panel. The user clicks on the different options to filter by the category presented.


For a better experience when testing I decided to code the idea so I could measure better the user reactions when interacting with the filtering proposal. I was looking for reactions regarding the IxD when selecting filters.


The feedback was negative regarding the experience. Users did not understand how to interact with the Filter Bar. The multiple buttons resulted in an overwhelming experience (Hick’s Law). Besides, the amount of space that the filtering was taking over the page was not welcome by the participants. In other words, participants were looking for something more "traditional".

“Too many buttons...”
OCI Engineer

Second round: faceted navigation

Faceted navigation provides multiple filters, one for each different aspect of the content. Faceted navigation is more useful for large content sets. Because faceted navigation provides the different values of the data, it also shows a structure to help users understand the content space, and help them to show what is available.

Faceted navigation


Participants felt more comfortable using the Faceted Nav. The feedback included satisfaction in the navigation and selection of multiple values of the data. The use and presentation of the space (layout) were well-received when completing filtering tasks. Other suggestions included being able to close the filtering section when not needed or be able to reset the selected filters.

Interface 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, measures, spacing and styles for all patterns).

Interface Design

Validation by Usability Testing

First release

Before releasing Single Pane to the development team, I do an initial test with the developers to understand if they see any feasibility issues. This is a quick review and an initial usability test with part of the product team.

I also selected a few users to test the prototype by asking them to complete a list of tasks associated with the experience.

The goals of the test were:

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

The HTML prototype exposed usability issues straight away. The process, was becoming less time consuming because small changes weren't taking hours to rectify and the code was completely re-usable when it came to the production stage.

Responsive design

One of our main goals was to ensure that our site would look and function well on any size device.

Each page element was designed with small screen sizes in mind. I determined how each element should flow and what design would work best on varying screen sizes.

Mobile view (responsive).

MVP solution

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. Also, we wanted to onboard multiple teams to the new application and request feedback and metrics review. We would learn about the performance of the tool and then move to the next implementation.

Learnings & Next steps after MVP Release

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

My next steps would be to test the live implementation with users & investigate an alert system and explore data pagination. Additionally, I would also like to explore how I could add more value to the data visualization by making it more informative, interactive and engaging for users.

Carlos Marin Burgos
Website Designed and Hand-Coded by Carlos Marin Burgos