Notifications Builder
From fragmented alerts to a shared automation framework grounded in user mental models
role
Product designer
focus
System design & automation
platform
Enterprise desktop web
Overview
Restaurant365 supports a wide range of operational workflows, from inventory counts and daily sales summaries to hiring, scheduling, and task management. Over time, notifications across these areas evolved independently, each solving a local problem without a shared system or set of rules.
This case study documents how a request to add new notifications to the Notification Center led to a broader investigation into how notifications actually existed across the product, and how that investigation shaped a clearer, more reliable way to define notification behavior.
The work focused on understanding the system before designing UI, and on prototyping a model that made notifications explainable, configurable, and scalable.
The ask
The original request was narrow: add a new set of notifications to the existing Notification Center.
On the surface, this looked like a configuration task: define new triggers, add toggles, and expose them alongside existing notifications. But before introducing anything new, I needed to understand whether the current notification experience could actually support more without breaking user trust.
That question shaped everything that followed.
Existing notifications configuration
Understanding the existing experience
To ground the work, I audited how notifications currently existed across the product.
What I found was not a single system, but a patchwork of module-specific implementations. At least 6 modules (Inventory, Payroll, Intelligence, etc) each defined their own triggers, settings, delivery channels, and UI patterns. Notifications were configured in multiple, unrelated places, often with no clear connection between them.
From a user’s perspective, this fragmentation made notifications difficult to reason about. A single user might need to visit four or five different surfaces to manage what they received. Similar events behaved differently depending on where they occurred. When a notification fired—or didn’t—users often couldn’t explain why.
From a product and engineering perspective, the cost was equally high. Notification logic was tightly coupled to individual features, hard to extend, and difficult to test consistently. Adding new notifications meant recreating logic, patterns, and delivery rules each time.
It became clear that adding more notifications on top of this foundation would increase noise rather than clarity.
Map of existing notifications experience across various modules
Reframing the problem
At this point, the problem was no longer “which notifications should we add.”
The real issue was that there was no shared model for what notifications represented, how they were triggered, or how users were meant to control them. Without that, neither users nor internal teams could reliably predict system behavior.
The work needed to shift from adding notifications to understanding how the system decides when something matters.
Defining a mental model
Before proposing solutions, I mapped the full notification landscape in Miro. This work was intentionally low-fidelity—the goal wasn’t to design screens, but to make the existing complexity visible.
I focused on the records involved, the moments users actually cared about, the conditions that made those moments meaningful, and the outcomes that followed. Working this way surfaced patterns quickly, but it also exposed inconsistencies. Many notifications looked different on the surface, yet were driven by the same underlying logic.
As the mapping work came together, a consistent pattern began to emerge in how users described their needs. They rarely talked about notifications as features. Instead, they described records that were late, incomplete, or blocked—moments when the system should have reacted but didn’t, or reacted in an unexpected way.
That shift in perspective led to a simple framing that could hold across scenarios:
WHEN
something meaningful happens,
AND
certain conditions are true,
THEN
the appropriate action should occur.
Breaking notifications into core components to reveal a consistent underlying model.
Validating the model
To ensure the model wasn’t theoretical, I applied it to existing workflows such as Inventory Counts and Daily Sales Summary.
These areas differed in cadence, audience, and stakes, but the same structure held. Each scenario could be described through a record, a meaningful state or absence of one, qualifying conditions, an evaluation moment, and a resulting outcome.
The fact that this structure held without introducing exceptions was the real validation. It reduced the need for special cases and made it easier to define which patterns should be explicitly unsupported rather than quietly allowed.
Translating the framework into concrete UI controls and constraints.
Building a prototype
With the underlying model defined, the next challenge was translating that logic into something users could reason about as they built rules.
The prototype was designed to do two things at the same time: support complex rule construction, and continuously explain itself back to the user.
As users assemble a rule—selecting a record, defining its state, adding time-based evaluation, and layering in conditions—the system generates a semantic summary in plain language. This summary updates in real time, reflecting the exact logic the system will evaluate.
Rather than forcing users to interpret a technical configuration, the interface makes the system’s reasoning explicit. Users can read their rule as a sentence and immediately verify whether it matches their intent.
Prototyping how multiple conditions could be combined and configured.
Supporting compound logic
The prototype also demonstrates how multiple conditions can be combined without breaking that mental model.
As additional conditions are added, the system preserves a clear AND-based structure, ensuring that rules remain readable even as they become more specific. Each condition is record-scoped and validated in context, preventing users from constructing rules that are logically incomplete or impossible to evaluate.
This approach allows users to express nuanced operational scenarios, such as missing records before a scheduled time or approvals limited to specific templates, while keeping the behavior predictable and understandable.
Rather than forcing users to interpret a technical configuration, the interface makes the system’s reasoning explicit. Users can read their rule as a sentence and immediately verify whether it matches their intent.
Defining how compound logic is represented and controlled in the interface.
Outcome
This phase of work resulted in a clearer, more consistent way to define notification behavior across the product.
It gave design, product, and engineering a shared mental model, reduced ambiguity around when notifications should fire, and made it safer to add new notifications without reintroducing fragmentation.
Most importantly, it shifted notifications from a collection of ad-hoc rules into a system users could begin to trust.
By resisting the urge to immediately add new notifications and instead focusing on how notifications already worked, it became possible to make targeted improvements without overcomplicating the product or overextending scope.
Olivia Vaughan