RULES INVENTORY

The problem

UX identified a gap in the existing experience for how Security Command Center (SCC) surfaced the generative rules powering its detection capabilities. These rules governed everything users could see and interact with, but they were not transparently accessible or modifiable. To make matters worse, we were developing new rule types with configuration management that was entirely separate from existing rules. A classic case of “shipping our org chart”.

The users

The vision

To prevent a further fragmented rules management experience for users, I defined the product vision for a centralized Rules Inventory. My proposal was a single destination where users could view, configure, and manage all of their generative rules types across SCC. I sketched out a site map of a unified rules ecosystem where the primary job to be done was configuration. The goal was to provide visibility into what each rule powered and how it impacted the environment.

"Security practitioners should have peace of mind that SCC is comprehensively scanning everything they want to cover, and looking for the right things. Not only should it be possible to view the full inventory of detective cloud configuration rules, but the user should be able to see the logic of any rule, duplicate it, edit it to meet their needs, then track violations of that rule as part of a custom Framework." - UX Vision Doc

User validation

I partnered with a user researcher to validate my hypothesis that users would benefit from a centralized location for rules configuration. I rapidly mocked up a prototype to validate with users what would be most helpful. At this stage, we had little user feedback fueling our decision making so I took some big swings—adding embedded metrics and a version history—to see what would resonate most with users.

Prototype

Research methodology

We interviewed 11 participants in 7 sectors

User roles:

• Architects 

• Security Engineers

• Developers

• Cloud Engineers

Research insights

The results were clear: users preferred a single, centralized hub for rules management. We also drew meaningful insights on how users preferred to conduct their configuration processes which influenced the direction of the product strategy. 

Cross-functional alignment

As this had been an entirely UX-led effort, I took ownership of aligning stakeholders across PM, engineering, and impacted product areas. We were operating under the assumption that specialized users worked independently to handle rule management and governance for their product areas. However, our research made it clear that configuration tasks spanned across roles and workflows and dividing it out across the platform would be detrimental to the user. 

To advocate for a unified approach to rules management, I drafted a one pager summarizing our research findings and rationale behind centralization. This document served as the basis for executive alignment and long-term scoping and prioritization.

Initially, there was resistance, due to dependencies across several other teams. I positioned Rules Inventory as a preventative investment that would bridge the silos of SCC configuration, streamline governance, and support the scalability of future rule types. To further alleviate concerns, I led cross-team sessions with partners in each of the impacted workstreams and developed transition plans for the products that would be most impacted in order to streamline the integration and minimize disruption to projects already in progress.

Design execution

Once buy-in was secured, I fleshed out the full high-fidelity Rules Inventory experience in Figma. I also designed out transition experiences for rule types that were moving locations and adding clear messaging to ensure existing users wouldn’t be heavily impacted.

*you may notice some different stylings in these designs—SCC was mandated to transition to 3 different design systems over the several months this project was underway so Rules Inventory has had a few different paint jobs.

A big priority was interconnectivity. This entire project arose from a need to bridge the common experiences underpinning several of our workstreams and products. I wanted to avoid the same trap of siloing off the rule set up experience from what those rules generated so I built in several entry points from rules inventory into the various features powered by those rules and vice versa. I ensured it would be easy for users to transition from tailoring their rules to viewing the direct impact those changes had on their environment.

Scaling up

As adoption grew, four additional teams beyond the three teams we had already committed to supporting, reached out. They expressed interest in housing their generative rule types within the Rules Inventory as well. In order to facilitate the rapid scaling up, I created:

• Reusable patterns and a template for adding new rules types

• Guidelines on what exactly constituted a discrete generative rule type 

• Documentation and onboarding assets for product teams transitioning to Rules Inventory