role
Senior Product Designer
focus
System design and automation
platform
Enterprise desktop web
Restaurant365 runs the operational core of a restaurant business. Notifications across its product areas grew independently, each solving a local problem with no shared model for when something should fire. A request to add a few more became a single framework that design, product, and engineering could build on.
8
product areas with their own notifications
6
modules audited in depth
120+
events cataloged in Inventory and Sales
4 to 5
places a user visited to manage them
Before adding anything, I audited how notifications already worked. Each product area had its own triggers, settings, delivery channels, and interface.
Users visited four or five places to manage what they received, and when a notification fired, or failed to, nothing could explain why.
The problem was no longer which notifications to add. The product had no shared definition of what a notification was.
The work became defining how the system decides when something matters.
FIRST PASS
I mapped every existing Inventory Count and Daily Sales Summary notification in Miro and wrote each one out in full, one row per rule, in the same nine slots.
Most fit. “Is due” and “is past due” did not. They sat in the status column next to “completed,” but a record never becomes past due the way it becomes completed. Past due is an absence with a deadline.
SECOND PASS
I collapsed the rules into a grammar, where each slot holds only its allowed values. Status kept only real states, and absence moved into its own slots: is not, before or after, a number of hours or days, and a time anchor. “Past due” became “is not completed, 2 hours before scheduled time.”
Automation Framework, principle 5
Inventory Counts and Daily Sales Summary, two workflows with nothing operationally in common, produced the identical grammar. I kept each rule to one record type on purpose, so conditions cannot mix across records. The model reduced to one sentence:
WHEN
AND
THEN
The prototype lets users build a rule from plain controls and writes the exact logic back as a sentence, updating in real time. Users can read the rule and confirm it matches their intent before saving.
As conditions are added, each one is scoped to the record and validated in context, so a user cannot build a rule that is incomplete or impossible to evaluate.
I planned the builder as a staged rollout. Each stage adds only what the previous one made necessary, and the model underneath never changes.
Version 1
One module
Version 2
The Automation Hub
Expansion
A second module
Opens from Manage automations on Inventory counts.
Inventory automations only, all in one modal.
Unnamed rules, a single WHEN and THEN.
Engineering planned a technical spike on the framework for the following quarter. My time at Restaurant365 ended before that work began, so I did not see it built.
Before then, another designer applied the framework to recipe modifiers, a record type I had not designed for. His rules change inventory data instead of sending notifications, and the grammar held without modification.
Inventory automation
WHEN inventory count is not completed two hours before scheduled time AND location is Gaslamp Quarter THEN notify [user] immediately via push notification.
Communication action
Recipe modifier rule
WHEN modifier is Extra Tomatoes AND menu item name is Margherita Pizza THEN deplete Tomatoes by 8 ounces AND replenish Tomato Sauce by 8 ounces.
Two data actions on a new record type
