Oracle Cloud Security Central

An internal security monitoring service used by Oracle Cloud to keep its cloud resources secure
Skills
UX research
Interaction design
Prototyping
Usability testing
Team
1 UX designer
1 product manager
3 UI devs
Timeline & scope
3 months (conception to design handoff) | ~5K users

Business context

Keeping the Oracle Cloud platform and environment secure is a task of paramount importance that holds a central role in the company's customer experience strategy. As an organization, possessing a robust security posture would provide Oracle Cloud with the foundation that enables customers to trust it with their most valuable workloads. In this respect, the company's ability to provide leading security requires that it possesses a seamless, effective, and accurate security monitoring mechanism.

In fact, Oracle Cloud has built an in-house tool to help it carry out this very task: Security Central.

Starting with the MVP

At the beginning of this project, Security Central had just launched its MVP 3 months earlier. And when this MVP was built, the team had a very simple goal in mind:
This was really important because as a cloud provider, Oracle Cloud needed to maintain security compliance. One way of doing that effectively is to make sure internal service teams resolve their security issues on time. And in a way, the Security Central MVP was kind of heading towards the right direction. It could, however, do a lot better.

Understanding the challenge with business metrics

In trying to better frame the business problem I was striving to solve with my team, I collaborated with my PM to identify a few unfavorable business metrics. While I'm not able to share confidential data, a good example of such metrics is the Average Time Taken to Resolve a Security Incident (and how it compares against the industry SLA).
Overall, Security Central MVP was doing the right thing, but the above metric also indiocated that something was missing. And the ultimate problem it wanted to solve was still kind of lingering:

The primary user

So how did I approach this problem as a UX designer? I started with the primary users for whom I was designing for, the on-call software engineer whose primary task is to resolve security issues for his team during an on-call rotation. In this respect, since a few high-level user needs had already been identified from when the Security Central MVP was being envisioned, I leveraged these existing data points as a way to get a sense of the team's current understanding of our users and their contexts.

Having a user profile gave me a basis from where I could begin to re-frame the problem we were trying to solve:

Looking for UX signals

My next step was to look for the UX signals. And what that really means is essentially any combination of user data that could suggest and point me to the potential root causes of the problem - the core reasons why users were experiencing this challenge.

With Security Central MVP, I was able to dive into a set of both quantitative and qualitative user data.

Usage analytics (understanding the WHAT)
I began with the WHAT of the user's context (i.e. what they were doing). One of the first signals came from the usage analytics we were tracking on Security Central MVP. Again, for confidentiality reasons I'm not able to share the exact values in this regard. Average Click Through Rate and Average Bounce Rate were 2 particular metrics we were tracking within this category.

Surveying (understanding the WHAT)
Another quantitative signal that helped me uncover a really important user insight was through a survey which I sent out to my entire user base, asking questions that really focused on their satisfaction and experience with Security Central MVP. Here’s an important piece of data:
User interviews (understanding the WHY)
Once I understood the WHAT, the next step was to understand the WHY (i.e. why were they doing it) - and that’s when the user interviews came in. Altogether my PM, my UX researcher, and I conducted 9 user interviews. We then conducted a series of affinity diagramming workshops to synthesize the collected qualitative data.

The more I talked to users through these interviews, the more I began to recognize a recurring pattern. A pattern that ultimately helped me redefine the user mental model – essentially, how users would think about their security story at Oracle Cloud:
What does that mean? In a nutshell, Security Central MVP was scanning service teams' cloud resources all behind the scene. These resources constitute of any computing infrastructure assets that a cloud service is built on top of (i.e. applications, servers, databases etc.). If the resources were flagged as insecure, Security Central would automatically create security tasks and assign these tasks to the respective service teams that own these resources. The tasks contain important information related to the resolution path for the identified issues. The idea was that an on-call engineer only needed to view a list of these security tasks, resolve them based on the provided resolution details, and accordingly bring their service back to a natural secure state:
The problem was that only the 2 latter parts of the diagram above were being surfaced via the Security Central MVP UI. In that respect, while users could see and interact with their assigned security tasks, they had no visibility into the actual security health of their service's cloud resources - something which we learned was vitally important to on-call engineers and their service teams.

Redefined user persona

As an outcome of my user research, I was able to redefine my primary user persona. With a focus on not only the security tasks themselves, but also how they would relate to the overall resources architecture of the service team:

Success criteria

As another user research outcome, I was also able to define 3 important business / product goals that I wanted our team to achieve through this iteration:

Understanding the user's context

A huge aspect of my design thinking process comes in the form of user journey mapping. At this point in the process, I would leverage the user data collected to help me shape a deeper understanding of my users, their contexts, as well as their current experience. The goal is to think about what overarching goal are users trying to accomplish, what needs would surface at different touch points throughout their workflow, what kind of questions they would ask, and ultimately, what experience gaps as well as opportunities exist throughout that journey.

As a summary, the visualization below represents a high-level structure of a user journey map I created for Security Central (Note: this is not the final output of the journey map, but rather a high-level representation only):

Early design thinking

Together with my team, I conducted design exploration workshops  to create high-level user flows that could envision what the end to end experience would be like for users. I started by thinking big and long-term about not only the immediate next release, but really in the ideal world, what would a successful experience look like. What would the ideal user flow be like? And, gradually, as I got more clarity around feature requirements from the PM, I began to zone in on specific flows and scenarios for the next release.

Through more design discussions with my team and stakeholders, in particular my PM, I began to create lo-fi wireframes that could provide an extra layer of details around the user interactions:
Together, these user flows / wireframes helped convey to the team and stakeholders my proposal for how users could potentially accomplish their goals through these workflows.

Design evolution

Gradually, the fidelity of my design mockups would increase as I began to get more clarity around feature requirements and technical constraints. While my focus was still on the overall UI layout, I started to put more emphasis on functionalities as well as specific user interactions through my designs. I also had the luxury to design on top of an existing design system that was built to specifically support the internal DevOps product ecosystem within Oracle Cloud, of which Security Central is a part of.

Below is one example screen from my design set: the Resources list. This view shows users all the resources associated with their service and the corresponding security status for each.:
At this point, I began to take these mockups out for usability testing with users for early validation. Here's one particular interesting finding I learned.

Quick filtering on the Resources list
A lot of users from various different service teams would generate the exact same lists of resources every time they visit Security Central. In fact, regardless of the service, all on-call engineers share a common interest in particular subsets of resources as they go through their security monitoring and resolution workflows. As such, one of the design changes I made on the Resources list was to add the quick filters to the top. This way users can always and easily generate these common lists anytime without having to interact with the filter controls on the left:
Ultimately, I was able to start envisioning what the live product would look like with hi-fi mockups; taking into consideration how these flows and pages would fit into the overall navigational scheme as well as the DevOps ecosystem. I also began to think more about visual design aspects and collaborated extensively with the UI dev team to come up with interactive prototypes that could be used for more usability testing and/or also shared with stakeholders.

Below is a comparison of the "before and after" versions of the Summary dashboard - the landing page for users to Security Central. The new iteration offers the Resources overview card at the top, shown by default. With Security Central MVP, this used to be the Tasks overview card. With this new iteration, the UI now offers a View dropdown which users can leverage to toggle back to the Tasks overview card if necessary. There’s also a Resource health card as well as a new Resources tab as part of the top-navigation (this did not exist with Security Central MVP). Overall, all of these changes signified the importance of Resources within the overall Security Central ecosystem:
Clicking on the Resources tab would take users to the Resources list. This is a view that could help users get a better sense of how their service's resources architecture is currently doing from a security perspective. They can gain this birds eye view, but at the same time they can also drill down into a specific resource using the quick filters or the filters panel:
If users click on a specific Resources link, they would get to the Resource details page. Here, they can obtain the context they need around the specific issue they’re trying to resolve for this particular resource. Accordingly, they can navigate to the corresponding Task for this issue by clicking on the View task details button:
Accordingly, they can navigate to the corresponding Task for this issue by clicking on the View task details button:

Did we solve the problem?

How did these iterations help to impact the business overall? Please contact me directly for more details around this topic!

What did I learn?

As always, a few important lessons I was able to gather through this journey to enable Oracle Cloud service teams with a better tool keep their resources secure.

Addressing a business need through UX design
First of all, this project was another testimony for the values of Design Thinking. As a product team, we were able address a real existing business need and challenge. Through this experience, I was able to truly appreciate how UX design as a discipline can truly add values to an organization in that way.

Leading and evangelizing on the UX process
My 2nd learning came from the opportunity I had to lead and evangelize to my organization on the values of a user-centered product development process. Before I joined, the team didn’t have any mechanisms or processes put in place to understand how users truly felt about the very product that was being built for them. We never really talked to users, and the only data we got was from the usage analytics that could never paint a holistic picture of our users and their contexts. As I joined the team, I made it my own commitment to gradually establish, grow, and embed the design thinking mentality into the overall product development process. From conducting user interviews, surveying, user journey mapping, affinity mapping, to usability testing etc. all were mechanisms which I built in collaboration with my team with a single goal in mind - putting the "U" into "UX process".