Shipt’s communication infrastructure was fragmented across push, SMS, email, and in-app — with no unified system governing what gets sent, where, or why. I designed the strategy and led the execution across three layers: automated comms, a preference center, and a centralized notification center.
Time-sensitive updates — your shopper is on the way, a substitution needs approval — weren’t reaching members consistently.
No single channel could reliably reach all members. Each one had limitations — low opt-ins, inbox fatigue, or cost.
Promos, retailer announcements, feature updates, deals — all of it was scattered across channels with no unified system.
I designed the strategy across three layers. Each one had to ship before the next could work.
The most foundational layer. Ordering is a core member experience — notifications about order status had to be reliable before anything else could work.
Members needed control over what they received and through which channels. Once opt-in quality improved, every downstream feature became more effective.
A centralized hub inside the app — not dependent on push opt-ins or email open rates. Every layer below enables the next above it.
I led the design and development for the Notification Preference Center.
The gap
Email hit inboxes but converted at 1.1% CTR. SMS was already overloaded with shopper comms. Push opt-ins were too low to rely on for broad reach. No channel could consistently reach all members — and none offered a passive, always-available surface for non-urgent content.
Most of the important work happened before any screen was designed. The choices I made in the framework phase determined everything downstream.
Before opening Figma, I needed to define what belongs, how it's prioritized, and how any team could ship without a design review. I led a cross-functional brainstorm to surface every notification type, then organized them into five buckets ranked by urgency and user value.
Listing use cases and organizing them in buckets
We started by listing every type of notification the platform could send. We ran a cross-functional brainstorm with Product & Marketing, then grouped all use cases into named buckets.
Ranking the Buckets
We arranged the buckets from most to least important based on urgency and member value — creating a clear priority hierarchy that content decisions could map to.
Template System
Defining reusable notification components per bucket so any team can add to the center without needing a design review from scratch.
Research showed users read feeds chronologically with urgency as a secondary signal — not by content type. The 5-bucket model was creating overlap, not clarity. So I challenged our own framework and consolidated to 3.
A single, flexible component that handles every notification type in the feed. The visual structure adapts to bucket tier — urgency-ranked notifications use a higher visual prominence, while lower-tier content stays visually quieter.
Color-coded tier tags make it immediately clear what kind of notification you’re looking at — and how urgent it is. The tagging system gave teams a shared vocabulary for content decisions without needing a design review.
Users could mark as read or delete — nothing else. Every other control we considered created expectations the backend couldn’t fulfill. A control that doesn’t work erodes trust faster than no control at all.
Time-sensitive order notifications required a distinct visual treatment to stand out in the feed. Active orders surface at the top when relevant — no hunting through a list of promotional content to find out where your shopper is.
The full case study covers the research methodology, the complete card sort and MaxDiff findings, every design exploration considered and rejected, and the delivery roadmap.
Password protected
Incorrect password. Reach out to get access.