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.
Consolidate issues from Server Jiras into one view.
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.
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.
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.
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:
"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.
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:
Based on this information, I was able to create user stories and define the MVP.
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.
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.
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.
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.
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.
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. 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
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.
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.
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).
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 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.
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.
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.
