In 2025–2026, Drata re-platformed and redesigned its entire core product. I was a key contributor from the stealth discovery and audit of the existing product through final implementation with engineering. The goal was platform consistency. That meant implementing our existing design system components, but it also meant re-examining the patterns we reused across the product and documenting the solutions so they'd be reused on purpose. Everything was on the table: inconsistent page headers, how we handled negative space on pages that were primarily a form, even how steps were labeled in a wizard.
I owned the redesign of platform settings and features, along with key components and functionality like login, external user experiences, and mobile responsiveness. Some features were legacy, with little institutional knowledge left about the original product decisions. Others were new, and the designer who led them was still at Drata. Each assignment needed an abridged round of discovery: understand the why, then realign every screen and interaction to the new standards. Along the way I identified new component needs and wrote system documentation for the use cases behind them.
A header rebuilt on every page
The page header was one pattern we'd been inconsistent with. To align on a single solution, I started by auditing the most complex page headers across the product: controls, evidence, personnel, policies, connections, and risk registers.
Audit of page headers from production app
Side by side, the problem was obvious. We had the same needs over and over, and each page met them in its own ad hoc way with no guidelines. From the audit I pulled out the requirements:
Wayfinding
Every page had some way back to a previous location—breadcrumbs or a "back" link that acted as the page's parent.
Every page had some way back to a previous location—breadcrumbs or a "back" link that acted as the page's parent.
Title and identifier
Every page had a title, and many needed a unique identifier next to it—an image, avatar, version number, or tagged ID.
Every page had a title, and many needed a unique identifier next to it—an image, avatar, version number, or tagged ID.
Actions
Most pages had top-level key actions, grouped into an action stack.
Most pages had top-level key actions, grouped into an action stack.
Priority messaging
Depending on the status and lifecycle of the object, we needed a consistent way to deliver priority communication to the user. That meant a banner, always in the same place when needed.
Depending on the status and lifecycle of the object, we needed a consistent way to deliver priority communication to the user. That meant a banner, always in the same place when needed.
Metadata
Many pages needed to show a set of key metadata, which led me to a new component: the Key Value Pair.
Many pages needed to show a set of key metadata, which led me to a new component: the Key Value Pair.
Sub-navigation
Tabs needed a consistent position.
Tabs needed a consistent position.
Structure before visuals
Before touching visuals, I blocked out the header's structure: what's required, what's optional, and where content could slot in. The title is the only thing every header needs. Everything else is optional, and the slots let teams drop in whatever identifier the object calls for without breaking the layout.
The anatomy turned those requirements into rules. The title is always the page's H1. Parent navigation is breadcrumbs or a back link, nothing else. Key Value Pairs cap at five in a header. The banner, tabs, and action stack are optional, but when they show up, they're always in the same place.
The Key Value Pair
The metadata requirement became its own component. A Key Value Pair is a label and a value, with an optional edit link on the label and optional feedback beside the value. The value supports four types: text (dates, versions, etc.), status badges, tags, and avatars for users or orgs. Each type handles one or many values and truncates with a "+#" overflow when it runs out of room.
Because it wasn't locked to the header, the Key Value Pair spread. It gave us a consistent way to represent static data, and that brought consistency gains to nearly every page of the product.
Layout rules built in
The header shipped with responsive behavior and width rules baked in. At narrow widths, the action stack drops below the metadata. For pages dominated by a form or another restricted-width element, a max width variant aligns the header with the page content instead of stretching to the viewport. That answered one of the negative space questions from the start of the project.
The result
A flexible but consistent page header: dynamic content with repeatable display, mobile responsiveness and layout rules built in, and trickle-down consistency for the rest of the app through the Key Value Pair.
