Re-platform—a System Built to Scale

I designed Settings, Connections, and the templates and components that held those surfaces together, and moved 14 settings pages into one grouped navigation.

The core flow from Realignment as it shipped: index, panel, detail page, and context preview. The detail page is built on the page header and Key Value Pairs I designed.

Overview

Drata’s customers run enterprise compliance programs, and the product had outgrown the way it was built. Features had been added page by page, and it showed. The same needs were solved differently on every screen. The relationships between risks, controls, evidence, and policies were hard to see. Labels didn’t say what a page was for. The platform needed consistency, context, and clarity.

My surfaces had all three problems:

• Consistency: every page built its own header, and each Settings page invented its own layout.

• Context: Settings sat in one dropdown that didn’t separate your own settings from the org’s. Identity provider problems surfaced in a side drawer after setup, away from the step that caused them.

• Clarity: two pages were called Notifications, and workspaces were buried at the bottom of the Company page.

Drata used the re-platform to fix the structure instead of restyling it: a design-led rebuild of the information architecture, interaction patterns, and front-end stack, from first commit to opt-in beta in twelve months.

The New Drata Experience: Built for What Comes Next

By late 2024 the problem showed up in the numbers: a dip in NPS traced back to larger customers frustrated with the UX.

Goal: make my part of the platform consistent, clear, and in context, using shared patterns other teams could build on.

Key Decisions

Gave Settings its own grouped navigation, so 14 pages stopped competing inside one dropdown.
Renamed pages that collided, so every label says whose settings it changes.
Moved workspaces off the Company page into their own index and detail pages, so an org with hundreds of workspaces finds one without scrolling past the rest.

Roles & Responsibilities

My role changed across three phases:

Realignment, January 2024: I was one of the team leads on the core interaction flow, from an index table to a panel peek to a detail or create-and-edit experience. Later that year, a smaller team expanded the work into a redesign of one slice of the product.

Constellation, pages: Once the build was approved, every page in the product was assigned to a designer. I took all of Settings, Connections, Quick Start (onboarding), My Drata (personnel compliance), tenant login, and error pages, with one month for the first pass.

Constellation, navigation: I mapped the new navigation structure across Compliance, Risk, Vendors, Governance, Trust, and Settings, setting up the platform to keep deepening each feature area.

Constellation, components: Rafael Alvarado, our design systems lead, and I built the new components the redesign needed, working with the whole design team to cover every use case. I owned the platform page header and its subcomponents (breadcrumbs and Key Value Pairs), the data table gallery, empty states, illustrations, wizards and stepped processes, the core page templates, and the mobile experience.

I worked with a PM partner, the Cosmos front-end team on new components, and an engineering pod that kept growing as we found how deep the legacy code in Settings went.

Settings covered 14 pages, including Organization Details, Workspaces, Role Administration, Ticket Automation, Personnel Compliance, Notification Rules, and Fields and Formulas. Connections covered the Google Workspace setup flow and the reusable patterns that came out of it, plus four connection types and two custom connections.

Discovery

The groundwork started in January 2024 with Realignment, a month-long design sprint to rethink the product’s repeatable UI. I was one of the team leads on the core interaction flow: from an index table, to a panel peek, into a detail page or a create-and-edit flow. The core team worked for three weeks, the full design team joined for the fourth, and Arlo, Rafael Alvarado (design systems lead), and I presented the result to the executive leadership team, including the CEO, CTO, and Head of Product.

Leadership’s feedback set the rules for what came next. Our CTO pointed out that the drawer was always meant as a quick peek or quick action, but because we’d never built real detail pages, everything had piled into it. He flagged that page headers kept getting thicker, that some areas, like Connections, held too much information for a panel at all, and that mobile needed to be responsive, not separately optimized. Our CEO asked whether people could jump straight to a detail page instead of clicking through a panel, and called out inconsistent table heights. I’d already been discussing giving customers more control over what a table shows and how. Those notes became the rules we carried into Constellation: detail pages for real work, panels only for quick actions, and headers that show only what a page needs.

From that review, we deprioritized a “peek” concept, a panel preview of an object before the full detail page. We also aligned on illustrations needs for the platform—empty states, error pages, etc.

That work was ready when the business case arrived. In November 2024, product, design, and engineering leadership met about a dip in NPS traced partly to larger customers frustrated with the UX, and the plan for Constellation came out of that meeting. A hackathon later that month produced the first navigation and app layout concepts with engineering. Design kicked off in December, the company heard the plan in January 2025, and engineering pods joined in February. The Realignment flow became the backbone of the new experience, from index to action panel to detail page to context preview.

Once every page had a designer, I audited mine: all 14 Settings pages, plus Connections, Quick Start, My Drata, tenant login, and error pages. Some were simple form pages. Others were full product features in their own right, like Connections, Workflows, Notification Rules, and Ticket Automation.

The problems fell into four groups:

Navigation: Settings had no navigation of its own. Every page sat in one flat dropdown.

Naming: Labels didn’t say whose settings a page changed. Two pages were called Notifications, one for org-wide alert rules and one for personal email settings.

Scale: The original Workspaces experience was built for a handful of workspaces. As Drata moved upmarket, enterprise customers needed dozens to hundreds, and a stack of cards at the bottom of the Company page couldn’t hold them.

Setup: Connection problems surfaced after the fact, when fixing them was riskiest.

Reframing: The team’s first instinct was to port each Settings page to the new stack as-is and restyle it. I pushed to treat Settings as one information architecture instead of 14 separate pages. That case came from earlier discovery I led with our content designer and the CTO into why Settings was in the state it was in. My PM partner for Constellation had also been my PM on the Growth team when I investigated Settings to help new customers onboard, so the case wasn’t hard to make.

Design Strategy

I started with the shared pieces before the pages. The core page templates, the page header, the Key Value Pair, empty states, and the gallery card for data tables gave my surfaces, and the rest of the product, a shared skeleton. Settings pages use the full template with the Settings navigation. Focused tasks, like connecting an identity provider or creating a ticket rule, use the centered template with a stepper.

Once those parts were settled in Cosmos, each page came down to content and states. Other teams built on the same parts.

The page header came first because every surface touched it. I audited the most complex headers in the product, across controls, evidence, personnel, policies, connections, and risk registers, and found each page meeting the same six needs its own way. In the new header, the title is the only required part. Wayfinding, an identifier, actions, a priority banner, metadata, and tabs each get a fixed slot when a page needs them. The metadata slot became its own component, the Key Value Pair, which spread to nearly every page of the product. The full story is in the page header case study.

The Surfaces

Settings navigation and naming

Settings got its own navigation, grouped into Personal, Organization, and Configuration. The groups answer the first question an admin has: am I changing this for me or for everyone?

Renames followed the same rule. The org-wide alerts became Notification Rules, and Notifications stayed with personal email settings. Company Info became Organization Details. Custom Fields became Fields and Formulas, since the page holds both.

As things evolved I renamed some pages that were “company” specific to be more inclusive of our expanding customer base where a school or a hospital group might be the organization that uses Drata. Tradeoff: Since these were later changes, I had to ensure that these changes were represented throughout the product and that our help center team was aware.

The old Settings dropdown held two pages called Notifications. The new navigation groups pages by whose settings they change.

Workspaces

Workspaces moved off the Company page into their own index, create flow, and detail page. The index is a searchable table with managers and frameworks summarized on each row. Each detail page holds a workspace’s details, managers, and frameworks, each editable on its own.

Tradeoff: Orgs with only a handful of workspaces now have an extra page to visit.

The legacy layout stacked a full card per workspace. The new table keeps dozens to hundreds searchable on one page.

Connections

Google Workspace setup became five steps: Configure, Connect, Resolve, Scope, and Confirm. Instructions sit next to the values admins need to copy. Admin mismatches get resolved in place, before the connection goes live. Scope changes warn admins before they cut off another admin’s access.

This followed a note from the Realignment review: Connections held too much information for a panel, so setup moved to its own page. The flow grew out of the identity provider lockout work and became the pattern for all of the over 300 connections.

Tradeoff: For some of the simpler connections, this new full space space may have felt like more friction, but with all connections evolving and new AI connections coming into play, the space the new flow and surface offered was worth it and keeping. all connections consistent was a no brainer.

Before, problems surfaced in a drawer after the connection was made. After, admin mismatches and risky scope changes get caught and fixed during setup, before anyone loses access.

Ticket automation

Six stacked accordion steps became three: Details, Scope, and Ticket. An example ticket shows what the rule will create updating as the trigger changes. Saved rules land in a table where each one can be switched on or off, and a new empty state explains what a rule does before anyone builds one.

Tradeoff: Here again, we might have been adding a bit of friction to what was a single page, but building off the connections experience, the consistency and focus of the three steps made the separate steps worth it.

Before, a rule took six stacked steps filled in one at a time. After, three steps, with an example ticket that shows what the rule will create before you save it.

Everything else I owned

Organization Details: split into Org Info and Key Personnel tabs.

Personnel Compliance: one long page became three tabs: Internal Security, Training, and Human Resources.

Role Administration: moved from role cards to a person-first table with filters and a detail panel. This added search, filtering, and build the stage for custom roles as RBAC continued to scale to support enterprise customers.

Language: separate Default Language and personal Language pages that link to each other.

Error pages: branded 404, 403, and 500 pages with on-voice copy and mobile layouts.

Tenant login: Engineering rebuilt the underlying flow which game us opportunities to rethink the UX in support all users types across customers, personnel, auditors, and multi-instance management users like MSSPs. This project requires a full case study to dive into the depths.
Mobile responsiveness: came down to making sure we had a plan for all key surface components to be responsive and focusing attention initially on experiences more likely accessed on mobile such as login and My Drata, the personnel compliance experience.

Holding the quality bar

I led design’s UAT issue reporting for Constellation, across the whole product and not only my surfaces. The issues were the details that make a product feel finished: a vendor table showing fallback initials while the detail page showed the custom logo, identity names that truncated badly instead of wrapping, and risk terms named differently from page to page.

Opt-in beta

The new experience launched to customers as an opt-in beta, with broader rollout starting in early 2026. All my experiences were feature complete back in 2025 outside of the new login flow which I was still supporting through spring 2026.

Results

Before: 14 settings pages in one flat dropdown, two of them named Notifications.
After: one grouped navigation where every page has a unique name.

Before: workspaces stacked as cards on the Company page, not searchable and not scalable to Drata’s enterprise customers’ needs.
After: a searchable table built for enterprises with dozens to hundreds of workspaces.

Before: complex connections crammed everything into a panel
After: connections all have a preview before connecting, a full screen connection experience, and a detail page with plenty of space to track history and resolve any issues.

The Connections flow became a reusable pattern for all 300+ other connections. The page header, Key Value Pair, empty states, gallery card, and templates live in Cosmos. The Key Value Pair alone spread to nearly every page of the product.

Expanded beyond a front end refresh, the new Drata resolved legacy code issues and experiences that were not ready to scale for the Drata custoers’ needs.