Products
Desktop App
Mobile App
Team
Sr. Product Designer (Me)
Head of Design
Product Lead
What I Did
User Research
Design Thinking
UI Design
User Testing
About Aurva
Aurva is a B2B SaaS platform focused on enterprise database security. The company builds advanced tooling for monitoring, controlling, and securing database activity — helping organisations prevent vulnerabilities and breaches before they occur. Their customers range from mid-size fintechs to large enterprises managing hundreds of data sources across AWS, GCP, and on-premise environments.
{Aurva logo or brand mark on a minimal background}
Policies & Database Access Portal
Policies on Aurva lets security admins create and manage rules that govern data access across an organisation's databases. There are two policy types: Access Control policies that actively modify the data stream (masking SSNs, redacting rows), and Alert & Monitoring policies that trigger notifications to tools like Slack or Splunk without interrupting the user's workflow.
The feature is coupled with a Database Access Portal — an employee-facing interface where developers and analysts can view their active data sources, request access to new ones, and receive time-bound credentials, all governed by the policies the admin has set.
{Side-by-side mockup: the All Policies list page on the left, the Database Access Portal on the right}
Business Requirements & Constraints
I worked closely with Aurva's Product Manager and Engineering Lead to understand the project goals and technical boundaries. The engineering team was lean, so every design decision had to be implementable within tight sprint cycles, and we had to work within Aurva's existing design language.
OBJECTIVES FOR THE FEATURE
Provide CISOs and security admins with a centralised, readable view of all active data protections.
Replace ad-hoc, CLI-heavy policy configuration with an intuitive visual builder.
Eliminate the broken access-approval workflows pushing employees toward risky workarounds like sharing passwords on Slack.
Make the system scalable enough that a single policy could be applied across dozens of databases simultaneously.
Challenges
Enterprise database security policies are inherently complex — Boolean logic, layered conditions, multiple user groups, varied response actions. Existing tools (Satori Cyber, Cyral, Imperva) handled this through dense configuration panels or CLI commands, creating a steep barrier for security admins who needed to act quickly.
Three specific problems stood out: security admins had no centralised visibility into which employees were accessing what data. Password sharing through Slack and Notes apps was rampant because the legitimate access path was slower than the workaround. And the existing approval flow — a multi-day email chain — meant developers routinely bypassed security altogether.
My challenge was to design a system where the secure path was also the fastest path, for both the admin creating the policy and the developer requesting access.
{Annotated diagram showing the "broken flow" — the password-sharing problem and the slow email-chain approval}
Research
USER RESEARCH
I conducted interviews with three distinct persona groups. CISOs wanted a bird's-eye view of all data access patterns and couldn't afford blind spots. Security admins lacked proactive controls — they were reacting to breaches rather than preventing them. Data consumers (developers, analysts) wanted fast, frictionless access and wanted to avoid unprofessional workarounds.
{Photo or illustration of research artefacts — e.g., an anonymised interview script or affinity map}
KEY RESEARCH INSIGHTS
The most critical finding was that the admin's mental model is inherently hierarchical: "Where is the data? → Who is touching it? → What should happen?" This sequence became the backbone of the entire policy-creation flow.
We also discovered that improper password sharing was not a discipline problem — it was a design problem. Employees shared credentials because the legitimate path took days. And admins frequently needed to apply identical rules across large groups of databases, but existing tools forced them to configure each one individually.
COMPETITIVE ANALYSIS
I analysed Satori Cyber, Cyral, and Imperva to assess their policy-building UX, information architecture, and visual design. The common pattern was a disconnect between the target (which database) and the logic (what rule), leading to frequent configuration errors. This directly informed our decision to separate data-source selection from rule-building.
{Competitive analysis snippet — a redacted comparison grid or annotated competitor screenshot}
Wireframing & Iterations
THE WIZARD STRUCTURE
Armed with the research insight that admins think hierarchically, I mapped the policy-creation flow as a two-step wizard: Step 1: Policy Details & Data Sources → Step 2: Apply Rules.
In early wireframes, I experimented with a single-page approach where the data source was just another variable inside the rule-builder. But the data source isn't a condition — it's the foundation. Selecting it first establishes the "blast radius" of the policy, and critically, allows us to dynamically filter options in Step 2. If an admin selects a Postgres database, we only surface relevant schemas and tables, preventing the "invalid rule" errors that plague competitors.
{Low-fidelity wireframe of the two-step wizard structure, showing the progression from Step 1 to Step 2}
SEPARATING POLICY TYPE EARLY
One of the most debated decisions was whether to split Access Control and Alert & Monitoring into distinct types or unify them under a single builder.
I advocated for the split for three reasons. First, the system impact is fundamentally different — Access Control policies modify the data stream in real-time, while Alert policies passively observe. Merging them risks a "fat finger" error where an admin blocks a production microservice when they only meant to send a notification. Second, choosing the type upfront lets us filter available actions in Step 2, keeping the interface lean. Third, our research showed admins think about these tasks at different times — compliance audits trigger an Access Control mindset, threat-hunting triggers an Alert mindset.
{Mockup of Step 1 — Policy Details screen showing the Policy Type toggle and the Data Source selection panel}
Selected UX/UI Improvements
THE "NATURAL LANGUAGE" RULE BUILDER
The central design challenge of Step 2 was representing Boolean logic without overwhelming the admin. I designed the rule-builder around a "When... AND... THEN..." mental model, structured as distinct vertical blocks rather than a horizontal sentence.
While a horizontal sentence like "If User X accesses Table Y then Alert Z" works for simple logic, it breaks down when an admin combines four user groups with three sensitivity levels and two response actions.
{Full mockup of the Apply Rules screen, annotated to highlight the three vertical blocks: "When Users," "Access with Conditions," and "Perform Actions"}
The vertical layout solved three problems. Complexity without clutter: conditions nest clearly using "AND" connectors without expanding past the right edge. Multi-value stability: multi-select tags stack neatly within their block rather than pushing actions off-screen. Trigger-response separation: the top blocks represent what we're monitoring, the bottom block the proactive response, making the consequence of a policy scannable at a glance.
{Close-up of the condition rows showing multi-select tags for Sensitive Data types and AND connectors}
FROM "BLACK BOX" TO SELF-SERVICE PORTAL
If security felt opaque, developers would revert to sharing passwords on Slack. The Database Access Portal was designed as the employee-facing mirror of the admin's policies — making security tangible and time-bound.
The countdown timer was the key design choice. Displaying exact time remaining (e.g., "75m 32s") reminds the developer that access is ephemeral while eliminating the anxiety of not knowing when it expires. The timer's colour shifts from green to red as time runs low, providing an instant urgency cue.
{Mockup of the Database Access Portal showing "My Data Sources" cards with countdown timers in green/yellow/red states}
I separated "My Data Sources" (primary action: View Credentials) from "Available Data Sources" (primary action: Request Access). Database-specific icons (RDS, Redshift, MongoDB, MySQL) and region labels provide instant recognition — developers can distinguish a production instance from a dev instance at a glance.
{Mockup of the View Credentials modal showing Host, Port, Username, and masked Password fields with copy buttons}
THE "BREAK-GLASS" OVERRIDE
The "Override Masking & Redaction" toggle was born from a conversation with a Lead DevOps Engineer: "When production is on fire at 2 AM, I don't need 'XXX-XX-1234.' I need the raw data." Without a sanctioned escape hatch, developers keep shadow admin passwords under their keyboards.
I designed this as a high-intent interaction. The toggle includes a clear description of what "unabridged access" means, and activating it makes the "Reason for access" field critical — creating an auditable paper trail. On the admin side, the override status surfaces prominently at the top of the approval modal. Access is always time-bound, with masking rules snapping back automatically when the duration expires.
{Mockup of the Request Access side panel with the Override toggle activated, and the Admin View showing "Override Masking & Redaction: True"}
CONTEXTUAL FORENSICS FOR INCIDENT RESPONSE
The Security Incident detail page was designed to move an admin from "something happened" to "here's why" in seconds. Rows accessed acts as a quick proxy for risk — 1-2 rows suggests a targeted fix, 10,000+ flags potential exfiltration. Semantic Types reveal what kind of data was touched. The raw SQL Query block provides definitive context — a targeted WHERE clause tells a different story than a blanket SELECT *.
A "Set up ACL" button on the incident page lets the admin move from observation to control without leaving context.
{Mockup of the Security Incident detail page showing incident metadata, log table, and SQL Query block}
Visual Identity & Design System
Aurva's existing pages used a loosely defined visual language — inconsistent spacing, mixed component patterns, no documented interaction guidelines. The Policies feature became the opportunity to establish a cohesive design system.
DENSITY WITHOUT CLUTTER
Enterprise security interfaces need dense information on screen, but density breeds errors. I developed a component language using containment and whitespace rather than borders and shadows for hierarchy. Multi-select tags use a compact pill style with muted fills, keeping blocks stable even with six or seven values selected.
{Design system specimen: tag/pill components in various states alongside vertical block containers with spacing annotations}
COLOUR AS FUNCTION
I restricted the palette to serve meaning, not decoration. Aurva's primary blue is reserved for interactive elements. Status colours follow a strict hierarchy: green for granted access, amber for pending, red for expiring or errored — most visible in the portal's countdown timers.
{Colour palette specimen showing functional assignments with annotated examples from the portal and admin views}
3. REUSABLE COMPONENT PATTERNS
The side-panel pattern (Request Access and Approve Access) established a consistent model: contextual detail slides in without leaving the list. The data-source card became a reusable template for any entity needing technical identity alongside a primary action. The wizard stepper accommodates two to five steps for future policy types. All components were documented with interaction specifications for engineering.
{Component board: side-panel, data-source card, wizard stepper, and status badge across all states with annotations}
Design Validation & Feedback
I tested the flow with security admins and developers across two rounds. The first validated that the two-step wizard aligned with the admin's hierarchical mental model — data-source-first was universally preferred. The second confirmed admins could accurately read back multi-condition policies and identify which actions would fire.
One CISO participant worried the Override feature would be overused. This led me to add the mandatory "Reason for access" field and admin-facing override status — turning a potential security hole into an auditable workflow.
{Photo or screenshot of a testing session — a blurred video call or annotated prototype with user feedback}
Summary
By focusing on a "North Star" of human-readable governance, we turned complex security logic into an interface both the admin and the developer could trust. The admin gets proactive control through a rule-builder that reads like a structured checklist. The developer gets a transparent, self-service portal where the secure path is faster than the workaround. And the CISO gets visibility into every access — including the exceptions.
The policy-creation wizard eliminates CLI configuration. The Database Access Portal eliminates password sharing on Slack. The "break-glass" override eliminates shadow admin credentials — replacing all three with a single, auditable system.
Metric 1
Metric Description
Metric 2
Metric Description
Metric 3
Metric Description
By mirroring the inspector's physical journey rather than digitising a paper form, I transformed a 50-field data sheet into a focused, step-by-step experience that earned the trust of field workers operating in some of India's most challenging conditions.
James Cao
CEO at Company