Custom Fields & Formulas
Risk Management · Drata · 2024
Risk Management · Platform
Custom Fields & Formulas
Giving compliance and GRC teams the flexibility to capture, calculate, and act on risk data the way their organization actually works, without leaving Drata.
Project imagery coming soon
Role
Lead Designer
Team
Directors, PM, Engineering
Type
Feature Design · Research
Status
Complete
01 · Personas
Who we designed for
Carl, Compliance Manager (primary)
Carl manages risk across the organization and needs to capture data points that Drata's default fields don't cover, things like financial exposure, custom scoring models, or org-specific risk categories. He's maintaining spreadsheets and external tools just to get the flexibility the platform doesn't give him.
Dean, GRC Director (secondary)
Dean needs to measure risk using formulas his organization has defined: residual risk, risk appetite, inherent risk scores. Without the ability to build those calculations inside Drata, he exports data and does the math elsewhere, breaking the integrity of his workflow.
02 · Team & Role
Sole designer on a two-phase initiative
I was the only designer on this project end-to-end, partnering directly with directors, the PM, and engineering across both phases. My role covered everything from research facilitation and design direction to cross-functional alignment, from initial problem framing through prototype validation on Custom Fields and Custom Formulas.
03 · Problem Framing
Starting with the gap
GRC and compliance teams were working around Drata in order to work within it. Users were managing risk metadata in spreadsheets, Airtable, and other external tools, not because Drata lacked good risk management, but because it lacked flexibility. There was no way to capture the data fields their organizations had defined, and no way to run calculations on top of them.
The problem, stated plainly: Drata didn't let users create formulas, so they couldn't correctly measure risk using their own models inside the product.
This surfaced two connected opportunities, giving users the ability to define their own data fields, then layering the ability to build formulas on top of those fields and Drata's native data.
04 · Customer Interviews
Validating the problem across segments
Before moving into design, I put together a structured interview guide to dig into current workflows, pain points, and ideal states around custom data and risk measurement. We ran sessions across enterprise, commercial, and emerging customers, including Wiz, Zapier, ContentSquare, and DistillerSR, as well as internal stakeholders.
Questions focused on three areas: how users were currently capturing and managing custom risk data outside Drata, what types of fields and calculations mattered most to their workflows, and where in the platform they'd expect this functionality to live.
05 · Synthesis & Prioritization
Turning research into a phased roadmap
Research confirmed that custom data needs varied by organization, but the underlying workflow problem was consistent: users needed to bring their own structure to risk management, not conform to Drata's. Findings split into two clear phases:
Phase 1, Custom Fields
Users needed the ability to create text, number, currency, and option fields and assign them to specific locations within Risk Management (Details, Assessment, Treatment Plan). Ownership and placement flexibility were table-stakes across every segment.
Phase 2, Custom Formulas
Users with more mature risk programs needed to go further, combining custom fields with Drata's native fields (Impact, Likelihood, Risk Score) to build formulas that output calculated values like residual risk or financial exposure. This was the forcing function driving them to external tools.
We also flagged future opportunities, formula-based reporting, heat map integration, and expanding both features beyond Risk Management to Controls, Assets, Policies, and Vendors, and added those to the roadmap.
06 · Formula Builder Research
Watching how people actually type
One of the most valuable research moments on this project came from six internal interviews focused specifically on the formula builder interaction. Rather than testing a prototype, we gave participants real scenarios and watched them work through the builder as if it were a live product. Seeing people actually use it in front of us told us things we never would have caught otherwise.
What we assumed about keyboard behavior was pretty much wrong. We expected users to reach for certain keys at certain moments, but the way people actually used Enter and Tab to move through the formula was different from how we'd designed for it. Some were trying to confirm a selection with Enter, others were using Tab to advance to the next term, and the builder wasn't responding in the way they expected either way. Small moments of friction that, in testing, became really obvious.
Giving participants scenarios to work through, rather than asking them to describe how they'd use it, was what made this research so useful. You can't get that from a conversation. Watching someone pause, try a keystroke, look confused, and try another one told us exactly where the interaction model needed to change.
07 · Design Decisions
What we built and why
Phase 1: Custom Fields
Wizard-based creation flow
After working through options with engineering and the Cosmos team, we landed on the Wizard component for the add and edit forms. The workflow has conditional progress across three steps, Details, Placement, and Equation, and the Wizard's linear structure made the dependency between steps clear without requiring users to hold that logic in their heads.
Placement model (Location and Section)
Rather than making custom fields globally visible, users define exactly where each field appears, which object (Risks, and later Controls, Assets, Policies) and which section within it. This gave users precision without adding complexity, and was designed to scale as the feature expanded beyond Risk Management.
Fields tab within Custom Fields and Formulas settings
Custom Fields lives as a tab within a shared settings page, alongside the Formulas tab introduced in Phase 2. This established a clear home for user-defined data in the platform and set up the architecture for future expansion.
Phase 2: Custom Formulas
Formula builder with real-time validation
The formula builder lets users construct expressions using custom numeric fields, Drata fields, and mathematical operators. We designed it to give continuous feedback, invalid terms highlight in red, expressions show an “Incomplete expression” state until three terms are present, and the badge updates to “Valid expression” once the formula resolves correctly. That removed a lot of guesswork and caught errors before saving.
One of the more interesting calls was whether the dropdown should restrict invalid operator combinations automatically, or surface all options and use color to signal errors. We landed on the latter, keeping all options available while highlighting invalid terms in red, which felt more honest to how users actually wanted to work. They wanted control, not the interface making decisions for them.
Inline formula results in the Risk drawer
Formula outputs appear directly in the Risk drawer in the section matching the formula's placement, and update in real time as users edit fields. When a result can't be calculated, a single dash renders in place of the value, clear without needing an explanation.
Preventing destructive actions
Custom fields referenced by a formula can't be deleted or hidden without removing the dependency first. This kept formula integrity intact without asking users to track those relationships on their own.
08 · Scalability Decisions
Built to grow beyond Risk Management
One of the most consequential decisions on this project wasn't visible in the UI. It was the commitment to build Custom Fields and Formulas as a platform-level capability, not a Risk-specific feature. The placement model, expression schema, and formula evaluation architecture were all designed to extend to Controls, Assets, Policies, and Vendors with minimal rework. We co-developed the Controls expansion in parallel with the Dravatars team to make sure the foundation held before Risk Management shipped.
09 · Prototype Validation
Testing the direction with customers
We walked prototypes back through customers across segments. The wizard structure, formula builder interaction, and inline drawer results all validated as intuitive and aligned with how users expected the feature to work. The real-time formula update behavior in the Risk drawer, a decision made together with engineering, was specifically called out as matching how users expected connected data to behave.
