Response-based Notification System
A trigger system rebuilt around how people actually think, so setting up the right notification takes minutes, not a call to support.
Company
Cisco WXM
Product Designer
Q2 (2019)
Role
Timeline
Disclaimer: The designs, concepts, and product details shared here are intended solely to demonstrate my design process and contribution. All intellectual property remains with the respective companies. Confidential information has been omitted and certain details have been generalised where necessary.
The problem
Cisco WXM's notification system let admins trigger email and SMS alerts based on survey responses using AND/OR logic. On paper it was powerful. In practice, it had been built around functionality alone with little thought given to the people actually using it. Over time users started reaching out to support just to complete a task that should have taken minutes. What looked correct on screen often didn't behave the way users expected on the backend. A feature meant to be self-serve had quietly stopped being one.
Goal
To redesign the notification trigger system so that any user, regardless of their technical background, could configure conditions independently and with complete confidence
My Approach
I started by working closely with the Customer Support and Implementation teams. They trained users on the feature daily and were the first to hear when something broke, which made them the most useful source of honest feedback at this stage. From there I ran structured interviews with five users, giving each of them a set of real-world notification scenarios to configure from scratch. I wasn't just observing what they did. I was trying to understand how they thought.
What I Found
The interviews surfaced something I hadn't anticipated. There weren't just users who struggled and users who didn't. There were two completely different mental models in the room.
Logical thinkers approached conditions mathematically. They understood AND/OR intuitively and moved through complex configurations without friction.
Non-logical thinkers, the majority, used language as their guide. When they wanted a notification for users in Mumbai or Bangalore, they'd configure "Mumbai and Bangalore" because that's how they'd say it in a sentence. The system would interpret this as an impossible condition and the notification would silently fail. They had no idea why.
The design solution had to work for both without asking either to change how they think.
User Interviews Results
The interviews required each user to configure conditions for a set of common real-world scenarios. Two examples are shown below.
​
When users tried to trigger a notification for men aged 18 to 25 in both Mumbai and Bangalore, most configured the two location blocks with an AND condition between them. The system couldn't resolve two mutually exclusive values linked by AND, so the notification never triggered. Users had no way of knowing this until it was too late.
The correct configuration required an OR between the two location blocks. Logical thinkers arrived at this naturally. Non-logical thinkers almost never did, because the word "and" in the sentence "Mumbai and Bangalore" led them straight to the wrong operator every time.
This single insight shaped the entire design direction. The interface needed to make the consequences of AND versus OR visible before a user committed to saving.
Two in five users were logical thinkers. Three in five were non-logical thinkers. Both needed to be able to use this feature confidently and independently.
What I Designed
The redesign centred on three things: making logic visible, making conditions testable, and making errors recoverable.
1. Condition Blocks
Instead of a flat list of conditions, I introduced grouped blocks that let users build logic in any order. The AND/OR relationship between blocks is explicit and always visible, so users can see exactly how their conditions connect before saving anything.
2. Live Summary
As users build their conditions, a summary panel translates the configuration into plain language in real time. This closes the gap between what users think they are setting up and what will actually trigger. No more silent failures.
3. Test Before You Save
Before a notification goes live, users can run it against real historical responses. A date range selector lets them narrow results to the most relevant time period, and a modal shows exactly which responses would have triggered based on the current setup. This turned an abstract configuration into something users could actually validate before trusting it.
4. Troubleshooting from the Dashboard
A further enhancement let users apply existing notification rules as quick filters directly on the response analytics dashboard. If a notification didn't fire, users could go from "why didn't this trigger" to seeing the matching data, adjusting the rule, and saving again without leaving their workflow.
The Result
The redesigned system shipped after multiple rounds of usability testing with the Support team, Implementation team, and two US-based clients. Task completion rates improved significantly. Users gained the confidence to configure complex notifications independently without needing external support. Edge cases were identified and resolved before launch. The feature became what it was always meant to be: genuinely self-serve.
What I'd Do Differently
I'd have brought real platform users into the discovery process earlier. Reaching existing clients proved harder than expected, which pushed their input later than I wanted. It's a lesson I've carried forward: build in lead time for user access from day one, not as an afterthought.
© 2026 by Rajashri Achar. Created on Wix Studio.