SNYPR - Policy Creation

Streamline the process of building tailored policies

Overview
SNYPR is an analytics-based SIEM(security information and events management) platform that detect and respond to security threats in time. And policy is the analytics technique under the detection segment. This project is intended to upgrade the user experience of the policy creation process.
My Contribution
I worked with another designer and collaborated with product manager and engineers in this project. The research and end-to-end design process were led by me. And the work is under development, expecting shipped in 2022.
         Duration
          Jul 2021 - Sep 2021
         Tools
          Figma, FigJam, Sketch
         Team
          UX designer, PM, Software Engineer
Essentials

SNYPR is an analytics-based SIEM(security information and events management) platform that detect and respond to security threats in time. And policy is the analytics technique under the detection segment that refers to the check that threats need to run through in order to be categorized.
To put it in a more understandable way, if we analogize security threats as fire. Then policy works as a fire alarm that would flag the blaze. It will only notify the fire department when a real disaster happens. In the cybersecurity world, that means a risky attack. With the help of policy, the number of threats and events for security analysts to investigate would reduce.

Design Goal

Policy creation is the process of setting up customized policies. Since different business might face varied attacks, it’s important to create tailored policies to help detect different threats.
My overarching design goal in this project is to streamline the current long-winded policy creation process and improve the overall usability.

The Result
Before I dive deep into the design process. I want to share the final results first to give you a first impression.
  • 5 out of 6 users I tested with picked the new left panel design over the old one as the side-by-side reminder saves their effort to switch between pages. The user satisfaction increased significantly
  • The completion time for the policy creation is reduced and the process is streamlined.
01. research
      & interview
After I spent some time in the cybersecurity material readings, I turned to our software and tried to build empathy with the users. I drafted a user flow to better understand the policy creation process.
In parallel with my secondary research, I had 5 contextual interviews with the primary users, detection engineer, to understand their needs and pain points.
According to the interviews, the most complained issue was actually the top navigation bar. Users said that the top nav was not able to click and they have to keep clicking the Save & Next or Pre button in order to jump between pages. Instead of deleting the button and bringing everything in one page as what users ask me to do, I asked them why they need to jump between pages. And it was then I realize the real problem.

“Let’s say I am already at the last step, but I worked on other tasks for a while and when I am back, I totally forget what policy type I have selected and I have to click the Previous button multiple times and wait for the content to load and then click back to edit again.”

It turned out that when analysts are setting up the policy, they sometimes will forget the input they have entered in previous steps.

The vague and intimidating design goal at first finally been boiled down to something that can drive action!
02. ideation

How might we prevent detection engineers from forgetting previous inputs and enable them to proceed the policy creation process with confidence?

03. initial
       exploration
After learning through the interviews that the first page is the most critical page containing all the determinants, I thought that the most efficient way to shortcut the process is to enable the users to carry that decisive info along the creation process. So I quickly made three low-fi designs that would make the first page a memo for the user. The rapid test I did both with the users and internal team shows that they love the left page idea so I move forward with it.
04. iteration
#1
My first attempt was to make the first page (policy details page) sticky because I also wanted to provide users with the ease to make changes on the critical info whenever they want besides the memo function. So instead of building a traditional page, I tried a bold way that is to have the entire page stay completely on the left when not editing. However that idea didn't go well during the testing since compared to the full screen design, this way still feels cramped.
#2
I changed back to the traditional full-page design as the first attempt failed. In the second design, the first page will turn into a collapsible left panel with all the decisive info at your hand when you proceed to the next steps. In this way , users no longer have to suffer from cramped input boxes and still get reminders at the same time.
#3
The third round iteration is more about polishing UI details. I removed the actionable items and accent color like the blue button and blue text that might cause confusion. However, there are still some contents that should be highlighted so I leverage the type-weight to highlight subtly.
I also iterated the tag color to meet accessibility standards, and the tag design in the design library were updated as well.
05. design
       revisiting
After iterating on the left panel design, I revisited the first-page design and had a design retrospect. The policy type selection section caught my attention, and I wasn't very satisfied with it. So I decided to give it a second thought.

#1 Expandable example section
The first attempt was inherited from the current product. The only update is that I changed the hover explanation into an expandable example section with explanation images. But when I looked back, I think it lacked consideration as 1. the selections are scattered around and make it hard for users to glance and pick. 2. the selection button is the same as the primary button across the product.
#2 Differentiation + Alignment
So my second approach was to differentiate the selection button and I also aligned the options to make the page looks concise.
#3 Selection list
In the third approach, I designed a split section with a selection list on the left and an explanation on the right. Users can navigate through each policy type with details more easily in this way.
I tested all three designs, and I assigned tasks for users to complete in each test. The result showed clearly people liked the approach 3 the most. And I used it for the final design.

Should we add a toggle?
I also thought about proficient users that they might want to hide examples, so I tried adding a toggle to enable the right side to collapse. But the toggle will potentially mess up the screen and distract users. Besides, since most of the users I spoke with said they preferred to have the examples expanded, it actually can save their onboarding time. Therefore, I go for the one without the toggle for now.
06. what could be
       improved?

01. Content writing
There is a couple of unpolished UX writing across the project like "Tier 1 criteria", "Optional criteria", etc. Additional writing skills could be applied to make the product more solid.

02. Live user testing instead of survey
When I was testing for the selection design, I tested it with surveys in the Useberry. But the testing tasks were not clearly explained through the survey and I could tell there was some confusion during the tests. Even though the results are clear, people's decision rationale are unclear to me. Think back I probably should use live user testing and let them help me clarify some of my follow-up questions.

07. takeaways

01. Don't hesitate to raise questions and ask for clarification, especially when designing for knowledge workers. It's hard to understand professional knowledge within a short amount of time. But it's critical to designers as we work as a bridge between the product and the users. My experience taught me that instead of wandering or searching around, always ask upfront, and talk to a wide range of people from product managers, to engineers and even the sales teams to gain domain expertise of the users you design for.

02. Collaboration needs adaption. Just like a romantic relationship, a good collaboration between two different people needs open communication and adaption as well. I had a different working style with the other designer on the team in this project. It made the collaboration hard at the beginning, especially under the WFH situation. But after we discuss openly with respect to each other. We found the best way to collaborate for us.

03. Jacob's Law. I tried an unconventional way to design the left panel at the beginning but I learned from my mentor that according to Jacob's Law, Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.