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

"You have to update the 6 dashboards at the same time to keep them synchronized".

User Personas

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.

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)

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 need to 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.

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.

HTML Wireframe

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

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.

HTML Wireframe

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

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.

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.

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.

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.