Oracle Single Pane

This portfolio showcases my personal work and design projects. While some of the content may reference my professional experience at Amazon, all views, opinions, and designs presented here are my own and do not reflect the official policy or position of Amazon. Any data or information displayed is either publicly available or has been anonymized to protect confidentiality. This portfolio is intended solely for the purpose of demonstrating my skills and experience in UX design.
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).
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
Problem
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.
Goal
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. Providing a tool for OCI engineers that consolidates issues from remote Cloud and Server Jiras into one single interface will decrease the number of missed tickets by the engineers and it will increase the customer satisfaction due to reducing the response on in-progress tickets.

Research and Insights
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.
The interviews helped us understand engineer’s behavior and what are the common pains they have when working with a multi-Jira setup environment .These are some of their pain points:
- Focus on one view to avoid context switching.
- Not alert of tickets created.
- Current flow does not support multiple regions.
- Lack of cross references between issues in different Jira sources.
- No mobile version.
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 6 tabs open).
"You have to update the 6 dashboards at the same time to keep them synchronized"
User personas

User Stories and user flow
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:
- Focus on one board to avoid context switching.
- Alerts - notifications.
- Ability to filter & sort data
- Be able to manipulate data ( add & remove)

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.

Designing the tool

Solution
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 needto do anything about it.
- OC3 (Realm)
- Ausburn (region)
- Phoenix (region)
- Chicago (region)

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

FIRST ROUND
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.
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...”
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.

For a better experience when testing I decided to code the idea so 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).

Validation by Usability Testing
First release
New approach in the design. This look eliminates the "flowchart" feeling from the previous designs. The arrows on the "TimeBlocks" produces a "flowchart" effect rather than a time line feeling. In addition, the direction of the arrows gives the wrong information about the direction of the timeline. In our case, we want to represent that time starts from left to right.
Also, circles with a number represent the number of changes. The change helps to separate the two most important pieces of information, Time and Changes. Discoverability is an issue in this design. Many users did not understand what the number inside the circle represents. They need to mouse over to see the "Changes" label.
The goals of the test were:
- Evaluate if OCI engineers can complete key tasks within an optimal success rate.
- Identify if there are key missing patterns in the interaction flow.
- 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.

high-fi prototype used during the testing .
Responsive design
The design was created to be responsive. The design is fluid and adapts to the screen size. The design is not a "mobile first" design. The design is a "responsive first" design. This means that the design is not created for a specific screen size, but it is created to adapt to any screen size.

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.
Next steps was to test the live implementation with users & investigate an alert system and explore data pagination. Additionally, I also explored how I could add more value to the data visualization by making it more informative, interactive and engaging for users.