Tufin · 2021-2022

Tufin SecureCloud: From One Rule to Policy at Scale

My role: Product Designer

5 → 500: Rules the model was designed to hold at, up from the old one-off ceiling
3: Primary personas defined from admin and architect interviews

Tools

Figma

Teams

Product DesignProduct ManagementEngineering

Bottom line

My role: Product Designer. I owned end-to-end UX/UI for SecureCloud and contributed to expanding Tufin's corporate design system in parallel.

The problem: Provisioning cloud resources independently across AWS, GCP, and Azure left compliance gaps and misconfigurations invisible until policy was checked in one place.

Moved the rules model from one-off explicit rules to tag-based scoping (Version, Environment, Tier), designed for 500 rules where the old model only held at 5. I left before I could confirm that at real volume.
Anchored policy violations to the rule that caused them, in a drawer instead of a disconnected panel.
Rebuilt rule creation as progressive disclosure and expanded the design system components this project depended on.

Challenge

Job to be done: a network admin or security architect needs to write and check policy rules that still hold at 500 rules, not just 5, so a compliance gap gets caught before an audit finds it.

Explicit, one-off rules were easy to read in isolation and unmanageable in volume; the rules list had to work at 5 rules and at 500.

Policy discrepancies lived in a narrow side panel, disconnected from the rule that caused them.

Building a rule correctly meant defining scope, source, destination, service, and action all at once on one dense form.

Approach

Interviewed and ran usability sessions with network admins and security architects to define three primary personas.

Replaced explicit one-off rules with tag-based scoping (Version, Environment, Tier).

Single explicit rule next to the rebuilt tag-based rules list at scale — Single rule to tag-based scale

Redesigned the violations panel into an expandable drawer anchored to the selected rule.

Tufin SecureCloud inbound rules table with violations flagged against vendor security groups — Violations against vendor rules

The same rules table checked against Tufin's managed policy — Violations against Tufin policy

Asset rules violations view listing risky ports and permissive access flags — Asset rule violations

Rebuilt rule creation as a progressive-disclosure form, and expanded Tufin's design system in parallel.

Add Policy Rule form using progressive disclosure across From, To, and Tags fields — Add Policy Rule, progressive disclosure

Rules list grouped by policy name with tag-based From/To conditions — Policy rules list

Impact

Split violations into two named views, against each vendor's own security groups and against Tufin's managed policy, so admins could see which side caused the drift instead of one merged blind spot.

Rule creation became a short guided sequence instead of one dense form covering every property at once.

The component library built alongside this project meant the next SecureCloud screen didn't start from zero.

What I'd do differently

Retrospective

I left Tufin before I could see post-launch adoption numbers, how much faster admins actually caught drift, or whether the tag-based model held up as rule volume grew further. I know the shipped design was right; I can't back it with a number.