Notifications were embedded across nearly every major workflow in Drata's product: compliance tasks, system alerts, vendor reviews, Trust Center requests, and collaboration activity.
As the platform expanded, notification behavior had been implemented with a rigid, one-size-fits-all approach. Most notifications were triggered by predefined system events and delivered primarily via email, with limited flexibility for customization. Users had little control over how notifications were configured or delivered.
At the same time, upcoming initiatives were expected to increase both the volume and complexity of notifications across the platform.
This created a broader product problem: Drata needed a more flexible and scalable model for how notifications should behave across the platform.
I led the product and UX side of this initiative in close partnership with the Group Product Manager and Staff Engineer, helping turn an ambiguous infrastructure question into a clear set of product requirements.
- Translated fragmented insights into a product requirements model — Synthesized customer feedback and internal signals into a clear definition of how notifications should behave across workflows
- Defined the workflows the infrastructure needed to support — Mapped representative scenarios across compliance, Trust Center, and collaboration experiences to make platform gaps visible and concrete.
- Extended the problem beyond delivery channels — Identified that notifications were also a collaboration and context issue, not just a transport issue, which expanded the requirements for the infrastructure decision.
- Helped drive a platform migration decision — The work informed the recommendation to move Drata's notification infrastructure to a new provider better aligned with product requirements and long-term scale.
System limitations
Notifications were triggered through a small set of predefined system events (for example, a control changing state), with limited ability to customize behavior beyond basic toggles.
This created several challenges:
- Lack of flexibility — Users could not tailor notifications based on urgency, task type, or internal workflows
- No escalation model — There was no way to route notifications to different stakeholders or escalate when tasks were not completed
- Limited channel control — Notifications were primarily delivered via email, with minimal support for preferred tools like Slack or Teams
- No contextual differentiation — Critical alerts and routine updates were treated similarly, making it harder to prioritize work
As a result, notifications did not adapt to how organizations actually operate. Instead, users had to adapt their workflows to the system, making it hard to scale future workflows that would satisfy our customers' needs.
Requirements model
The first step was making the problem legible.
I synthesized feedback gathered over several months from Productboard, prior research conversations, and internal product and support discussions. I organized them into themes that exposed where the platform was failing users and where future needs were likely to grow.
That synthesis became the basis for a requirements model: a product-level view of what notification infrastructure would need to support.
Representative customer feedback included:
"Would be nice to have ability to customize notification behavior... Every moment must be clear who is the owner and have some SLAs for progress."
"Combining Slack integration with different notification customization... based on the type of task and how far in advance we receive the notification."
Research synthesis board — thematic clusters of customer feedback and internal product insights
Representative workflows
To move from insight to decision-making, I worked with the Group Product Manager to define representative workflows that expressed the kinds of notification behaviors the platform needed to support.
We defined a set of representative workflows to capture the range of notification behaviors the system needed to support. These included core notification scenarios, as well as an extended case that introduced collaboration patterns.
These workflows covered:
- Core notification scenarios
- Task assignment within compliance workflows
- Critical test failures requiring immediate attention
- Trust Center access requests from external stakeholders
- Extended scenario (notifications + collaboration)
- Task assignment with in-app collaboration, including comments, mentions, and shared context
User gets assigned a custom task
Relevant user gets notified of a critical failing test
Admin gets notified of a Trust Center request
This scenario extends the core task assignment workflow by introducing in-app collaboration (comments, mentions, shared context), highlighting additional requirements beyond notification delivery.
This work helped the team evaluate notification behavior as a system rather than as a set of disconnected edge cases.
These workflows also became a key tool in vendor evaluation. We used them directly in conversations with infrastructure providers to communicate the types of behaviors, interactions, and flexibility the system needed to support.
Rather than discussing features in isolation, these scenarios grounded the conversation in real product needs — making it easier to assess how each platform would handle complex, real-world workflows.
Collaboration requirements
As the flows were mapped, another layer of the problem became clear: notifications were increasingly intertwined with collaboration behavior.
We explored patterns such as:
- Internal notes and comments
- User mentions
- Threaded communication
- Shared context between users working on the same workstream
This mattered because future notification infrastructure would need to support more than system-generated alerts. It also needed to support evolving communication patterns inside the product.
This insight expanded the evaluation criteria beyond notification delivery, requiring the system to support richer interaction patterns and evolving collaboration behaviors across the platform.
Collaboration exploration — interaction patterns and their intersection with notification requirements
With requirements and workflows defined, the Group Product Manager, Staff Engineer, and I moved into a structured evaluation process.
We began with exploratory calls across multiple notification infrastructure providers to understand the landscape and narrow down options. From there, we focused on two providers — the existing solution and a potential replacement — and conducted a series of weekly working sessions to evaluate both platforms in depth.
The evaluation process included:
- Reviewing platform capabilities against our defined workflows and requirements
- Testing UI/UX and configuration flexibility from a product and design perspective
- Engineering validation using existing templates and triggers
- Customer reference calls to understand real-world usage
We not only assessed current functionality, but we evaluated how well each platform could evolve with Drata's product over time.
The evaluation focused on:
- Multi-channel delivery (email, Slack, Teams, future channels)
- In-app collaboration
- Scalability as notification volume increases and different digest capabilities
- Flexibility for engineering teams to configure complex logic
- Support for white-labeled experiences aligned with customer branding
The result was a recommendation to transition to a new notification provider better aligned with Drata's product and engineering needs. Because the existing implementation used only a small portion of the current platform's capabilities, the migration effort was considered manageable relative to the long-term benefits.
This work did not produce a customer-facing feature on its own. It produced something more foundational: the decision framework that guided Drata's next notification infrastructure.
- Converted fragmented insights into a structured requirements model for platform decision-making
- Clarified how notifications should behave across multiple product surfaces, not just individual features
- Expanded the definition of the problem to include collaboration patterns and white-labeled experiences
- Helped drive the decision to migrate to a new provider better suited to Drata's future notification needs
This project pushed me into a different kind of design work — one where the challenge wasn't designing a complex interface, but making sense of a fragmented system and helping define how it should scale.
One of the hardest parts was consolidating insights. Customer feedback around notifications existed across multiple sources — Productboard, research transcripts, internal discussions — but wasn't structured in a way that made it easy to reason about. A significant part of my work involved going back to raw inputs, piecing together patterns, and turning scattered signals into something the team could act on.
This project also gave me deeper exposure to how product, engineering, and vendor relationships intersect. I worked closely with the PM and Staff Engineer to evaluate infrastructure providers, joining calls where vendors presented their capabilities and early implementations. My role was to assess how those systems could support the product experience we were defining — from flexibility and customization to how well they could integrate into Drata's existing workflows, and fit our customers mental models.
Being part of a decision that would lead to migrating notification infrastructure across the platform made the impact of this work very tangible. It reinforced how much influence product and design can have on technical direction when grounded in clear requirements and user needs.
More broadly, this project shifted how I think about infrastructure decisions. Notifications are not just a delivery mechanism — they shape how users understand responsibility, urgency, and collaboration across the product. Defining those behaviors upfront proved just as important as the technology used to implement them.