Security Central 2.0

Before I joined the team...

At the beginning of this project, Security Central had just launched its version 1.0 a few months earlier. When it was released, the team had a very simple goal in mind - help internal engineering teams resolve security issues faster.

The team had a very simple goal in mind - help internal engineering teams resolve security issues faster.

This was really important because as a cloud provider, OCI needed to maintain security compliance. One way of doing that effectively is to make sure internal engineering teams resolve their security issues on time. Even though Security Central 1.0 was heading towards the right direction in that regard, it could definitely do a lot better.

Understanding the business impact

In trying to better grasp the business need we were working to address, I collaborated with my PM to identify a few unfavorable business metrics. 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 1.0 was helping to reduce this particular metric, but it was still not within the favorable industry-standard SLA threshold. The ultimate problem it wanted to solve was still kind of lingering - internal engineering teams were still taking too long to resolve security issues.

Internal engineering teams were still taking too long to resolve security issues.

Understanding the primary user's context

I started with the primary users for whom we were designing for, the on-call software engineer. These are the folks who are tasked with the responsibility to resolve their team's security issues during an on-call rotation.

In this respect, the team had a few high-level user stories that were defined from when Security Central 1.0 was being developed. I leveraged these artifacts as a way to get a sense of the team's current understanding of our users and their contexts. Having an existing user profile gave me a basis from where I could begin to re-frame the problem we were trying to solve.

Per our original understanding, the number one thing on-call software engineers care about when they're on-call is the number of security tasks they have on their plate. Security tasks are basically Jira tickets auto-created by Security Central and auto-assigned to an engineering team in question, based on security issues it had identified as stemming from that team's software applications.

Looking for UX problem signals

My next step was to look for the UX problem signals. Essentially, any combination of user data that could suggest and point me to the potential root causes of the problem.

With Security Central 1.0, we were able to dive into a set of both quantitative and qualitative user data. A combination of usage analytics, surveying, and user interviews eventually allowed us to identify a few fundamental gaps in our understanding of how users operate. It helped us holistically redefine our user mental model and stories.

A combination of usage analytics, surveying, and user interviews eventually allowed us to identify a few fundamental gaps in our understanding of how users operate. It helped us holistically redefine our user mental model and stories.

As in turned out, while security tasks are important, what on-call engineers care more about are actually their resources. Resources, in this context, are all the computing assets (databases, compute servers etc.) an engineering team uses to build its software applications.

Mapping the user journey

A huge aspect of my design thinking process comes in the form of user journey mapping. I leveraged 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.

Early design thinking

Together with my team, I conducted design exploration workshops to create user flows that could envision what the end to end experience might look like - one that would be centered around resources rather than tasks.

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.

I conducted design exploration workshops to create user flows that could envision what the end to end experience might look like - one that would be centered around resources rather than tasks.

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

Design-test-iterate

After multiple rounds of design-test-iterate, I was able to produce a set of hi-fi design specifications / mockups that would support the release of Security Central 2.0. Below are some sneak-peaks.