Monitoring 2.0
Data Observability · Drata · 2024
Data Observability · Platform
Monitoring 2.0
Rethinking how compliance managers monitor data quality tests, making failures easier to triage, delegate, and resolve across the organization.
Project imagery coming soon
Role
Lead Designer
Team
Secondary Designer, Directors, PM, Engineering
Type
Feature Design · Research
Status
In Progress
01 · Personas
Who we designed for
Carl, Compliance Manager (primary)
Carl monitors data quality tests and addresses failures, either fixing them himself or delegating to the right person. He's the day-to-day user of the monitoring surface and the one most affected by noise, false positives, and unclear ownership.
Dean, DevOps Engineer (secondary)
Dean typically manages infrastructure tests and gets pulled in when errors occur, often because of connection issues. He needs fast visibility into what broke and why, without wading through noise meant for compliance.
02 · Team & Role
Leading a cross-functional team
I led design on the Monitoring 2.0 initiative, partnering with a secondary designer, multiple directors, the Product Manager, and the engineering team. My role spanned research facilitation, design direction, and cross-functional alignment across the entire effort.
03 · Initial Research
Starting with the signal we already had
I started by reviewing all customer feedback in Productboard tagged to monitoring and tests, surfacing recurring frustrations and patterns that had been accumulating over time.
Next, I facilitated a Rose-Bud-Thorn workshop with a cross-functional group that included directors, customer success managers, product managers, engineers, and the head of product. I intentionally invited both team members with deep product expertise and newer employees who could bring a fresh perspective. Customer success managers in particular brought valuable insights from direct user interactions.
Combining workshop outcomes with the Productboard feedback, I identified recurring themes and developed an opportunity-solution tree from our initial problem statement, giving the team a shared map of what was worth pursuing and why. This process surfaced four core problem areas:
- ●
Users lacked the details needed to know their next steps when a test failed
- ●
Information was scattered across the app and difficult to act on
- ●
Limited customization made it hard for users to work efficiently
- ●
There was no clear way to understand how tests connected to a broader compliance program or what impact a failure might have downstream
04 · Customer Interviews
Validating with real users
After building wireframes informed by customer feedback and the internal workshop, we ran interviews with 12 customers and internal stakeholders across all three segments. The goal was to make sure our solution worked for every type of user while staying intuitive and easy to use.
2
Enterprise
Tenable, Hornblower
5
Commercial
Legato Security, Truveta, Prolific, Blue J, Verbio
3
Emerging
Getinvisible, Dataminded, Spiraldot
2
Internal
SE Team, Alev/Jonathan
All sessions were recorded and synthesized in Dovetail, resulting in 200+ highlighted quotes organized across 52 distinct insights, grouped by theme and then triaged into actionable buckets.
05 · Synthesis & Prioritization
Turning 52 insights into a roadmap
Not every insight could be acted on immediately. To make the research usable for the team, I organized findings into four categories:
Already reacted to
Quick wins addressed immediately in the design. For example, users weren't discovering that the Findings count in the account table was clickable, so we made it an explicit “View findings” link. We also resolved a conflicting insight around connection visibility: some users needed to know which system a test was running on, while others found unused connections created noise. The solution separated active connections from unused ones, serving both needs without compromise.
For this version
Insights that shaped the core redesign scope, including the move from drawers to full detail pages, a filterable table view, tabbed navigation, and a test owner model.
For other teams
Findings that surfaced issues outside of Monitoring, flagged and shared with the Controls, Cosmos, and Effortless teams.
Future roadmap
Longer-horizon opportunities like connection health surfacing, actionable notifications through a user's preferred channel (email, Slack, etc.), and aggregated findings views.
06 · Design Decisions
What we built and why
The redesign introduced four primary changes driven directly by research findings:
Table view with filtering and quick actions
Users needed to quickly scan, sort, and act on tests without drilling into each one individually. The table replaced a less flexible list and gave power users the efficiency they were asking for.
Detail pages replacing drawers
The drawer pattern was limiting. Users would open it, lose context, and have to navigate elsewhere to take action. Full detail pages gave each test the space it needed and kept users oriented within the product.
Tabbed navigation (Overview, Findings, Exclusions, Controls)
Tabs gave users a clear mental model for the different jobs they needed to do within a single test, reducing the sense that information was scattered across the app.
Test owner assignment
Users expressed a clear need for ownership accountability. The test owner model directly addressed the delegation problem Carl faced as a compliance manager trying to route failures to the right person.
07 · Prototype Validation
Testing the direction with customers
We walked the prototype back through customers across all segments. The response validated the direction. Users described the changes as streamlining their workflow and making the experience significantly clearer. The tab structure, detail pages, and table view were called out positively across multiple sessions.
One particularly strong signal came from a conflicting insight that emerged mid-research: two users had genuinely opposing needs around connection visibility. Navigating that tension, and landing on a solution that satisfied both without compromising either, became one of the most useful design challenges of the project.
