UX Case study : IBM Cloud : 2026
Role
Lead UX Designer
Team
1 PM, 1 Design Manager, 1 UI Architect
Platform
IBM cloud console
What I owned
Research, IA, Interaction design, Testing, and Design System alignment.
Designing a Filter Validator to Reduce Blind Configuration
Overview
Summary
IBM Event Notifications routes alerts from cloud services to the right users through a rule-based filtering system. However, operators configuring these filters had limited visibility into real event payloads, no way to validate whether filter logic would behave as expected, and no feedback mechanism before deployment often resulting in missed alerts or excessive notification noise in production.
I led the design of a proposed Filter Validator, an embedded sandbox within the filter creation flow that enables operators to test and validate filter logic before deployment. It provides access to a payload library, a dual-mode condition builder, and a live validation engine with per-condition feedback, helping users configure filters with greater accuracy and confidence before saving them.
Operators had no way to validate filter logic against real data before activating it in production.
The core problem
A closed-loop sandbox: capture payloads → build conditions → test live → see per-condition results.
The solution
Validated direction through concept testing, with stronger task completion, usability and configuration confidence.
Outcome
Understanding the problem space , what was breaking and why
Discover
01
IBM Cloud Event Notifications is the alert nervous system of cloud infrastructure. It lets developers route real-time alerts security incidents, pipeline failures, service outages to destinations like Slack, PagerDuty, email, or custom webhooks.
Think of it as a traffic controller for critical information. When it breaks down, engineers go blind. Teams miss incidents. Systems fail silently.
What is IBM Event Notifications?
Context
0
Ways to test a filter before activating it in production.
15+ min
Average time to configure a single filter
80%
Filter errors discovered after going live.
2+ tabs
Needed simultaneously docs, editor to write filter
Problem definition
What Was Breaking?
Through user research, support ticket analysis, and internal team interviews, three compounding pain points emerged that together created a deeply frustrating configuration experience.
01
No payload visibility during filter creation
Operators had to rely on external documentation to locate their source payload schemas and manually construct JSONPath expressions, often without visibility into the actual event data flowing through their system.
02
No way to test before activating
Once a filter was configured and saved, the only way to verify its behaviour was to wait for a real production event and observe whether the notification was triggered correctly. This made testing and iteration slow, reactive, and inherently high-risk.
03
JSONPath errors were invisible until too late
Even minor syntax errors or incorrect field paths could silently prevent notifications from being triggered. Because there was no validation feedback while writing the expression, operators often discovered issues only after an expected alert failed to arrive.
04
Advanced users and beginners had no shared path
Expert users needed the flexibility of full JSONPath control, while less technical operators struggled to write expressions altogether. The existing experience lacked an interface that could effectively support both user groups without compromising usability.
"The UI for setting up a custom filter is a nightmare”
- User
Research
Discovery Methods
User Interviews
Conducted interviews with platform operators, DevOps engineers, and SRE teams who regularly configure event notification filters, focusing on their mental models, existing workarounds, and key points of failure in the current workflow.
Support Ticket Analysis
Analysed support tickets related to filter configuration and found that 5 % stemmed from JSONPath syntax issues or incorrect assumptions about payload structures confirming that the problem was systemic rather than isolated.
Competitive Audit
Reviewed the filter configuration experiences of AWS EventBridge, Azure Event Grid, and Google Event arc. None provided integrated pre-deployment testing or real payload validation capabilities, highlighting a broader market gap and a clear opportunity for differentiation.
Competitive Landscape
What Competitors Were Doing
No major cloud event platform offered what operators actually needed pre-deployment filter validation against real payload data.
Platform
Guided Filter Builder
Pre-deploy Testing
Payload Library
Live Payload Capture
Per-condition Results
AWS EventBridge
Azure Event Grid
Google Eventarc
IBM Event notifications
x JSON manual
Partial (form UI)
✗ Code only
✓ Guided + JSONPath
✗ None
✗ None
✗ None
✓ Full sandbox
✗ None
✗ None
✗ None
✓ 100 per source
✗ None
✗ None
✗ None
✓ Per-source toggle
✗ None
✗ None
✗ None
✓ Per-condition T/F
Synthesising insights into design direction
Define
02
User
Who Are We Designing For?
Arjun - The Platform Operator
Cloud Operations / DevOps · Non-developer
Context
Manages IBM Cloud infrastructure for IBM. Responsible for ensuring critical alerts reach the right on-call teams. Understands event categories but doesn't write code daily.
Goals
Set up reliable filters quickly
Avoid missing critical alerts
Validate without engineering help
Frustations
JSONPath syntax is opaque
No feedback until production fails
Dependent on docs to understand payloads
Sarah - The Integration Developer
Backend Engineer · Builds automations on IBM Cloud
Context
Writes complex event-driven pipelines. Needs fine-grained control over filter logic, often writing multi-condition, JSONPath expressions with environment and region-specific constraints.
Goals
conditions with full JSONPath
Test logic against multiple payload variations
Validate combinations of conditions together
Frustations
Hard to track
No sandbox for multi-condition testing
Payload structure is buried in docs
How might we enable operators of varying technical expertise to confidently validate event filters against real payload data before deployment directly within the filter creation workflow?
Design Principles
What Guided Every Decision
Principle 01
Real data over synthetic examples
Operators should test against payloads their actual system has produced, not generic example JSON from documentation.
Principle 02
Both modes, one workflow
Non-developers need guided drop-down. Developers need raw JSONPath. These are not separate paths they compose into a single filter.
Principle 03
Test before you touch production
The entire testing workflow must happen before the filter is activated. Production state should never be the first validation environment.
Exploring architecture and testing concepts
Ideate
03
Exploration
Three Approaches Considered
Before committing to a direction, I explored three different mental models for how the validation experience could be structured.
Concept A
Separate Test Page
A dedicated testing screen after filter creation. Operators complete setup, navigate to a test page, run validation, then return to adjust.
✗ Breaks the creative flow. Multi-step navigation creates friction.
Concept B
Embedded Sandbox Panel
Payload library and test engine embedded directly in the filter creation side panel. Test live as you build never leave the context
✓ Reduces context switching. Tightest feedback loop. Natural progressive disclosure.
Concept C
Modal-based Tester
A test trigger that opens a fullscreen modal with the payload selector and results. Panel stays separate but accessible.
✗ Loses side-by-side context. Modal fatigue in complex workflows.
Validation
Usability Testing
Conducted 5 moderated remote usability sessions 45–60 minutes each. Participants recruited from enterprise DevOps, cloud operations, and platform engineering teams the exact operators who configure event filters daily. Testing two concepts on task completion, payload comprehension, and filter confidence before activation.
Metric
Concept A
Concept B
Task Complition
UMUX score
Time on task
80%
6.8/10
15 min
91%
8.5/10
8 min
Having the actual payload right there while writing the condition. I knew immediately if my filter would work.
— Participant 1,
Finding 01
Operators needed payload context while writing conditions
Every participant who tested Concept A had to switch back and forth between the payload view and the condition editor, losing context each time. In Concept B, having the JSON viewer and condition builder side by side eliminated this entirely.
→ Validated embedded split-column layout
Finding 02
Per-condition results were more actionable than overall pass/fail
When shown a single True/False result for the whole filter, participants could not identify which condition failed. When shown per-condition results, all participants corrected the failing condition on the first attempt without guidance.
→ Reinforced per-condition test result design
Finding 03
Real payload examples eliminated configuration anxiety
Participants using captured historical payloads from their own source reported significantly higher confidence that their filter would work correctly. Those working from documentation alone frequently second-guessed their field paths.
→ Strengthened payload capture onboarding
Design Decisions
Key Calls and the Reasoning Behind Them
Design Decision
Options Considered
Why This Choice
Payload capture as a source-level toggle
100 payload cap with 7-day retention
AND-linked simple + advanced conditions
Per-condition True/False results
Edit + add custom payloads
Always-on capture vs. opt-in toggle vs. on-demand fetch
Unlimited storage vs. fixed cap vs. time-only expiry
OR logic / separate condition types / single input
Overall pass/fail only vs. field-level highlighting vs. per-condition
Read-only library vs. edit only
Opt-in protects storage costs, gives operators control, and makes the feature discoverable without forcing it on everyone
100 covers meaningful variety; 7 days covers recent patterns. Favorites escape hatch handles edge cases without open-ended storage commitment
AND is the dominant real-world pattern. Explicit AND pill makes the logic legible
Per-condition maps exactly to how operators will debug — "which of my 4 conditions is wrong?" is the real question they need answered
Edge cases that haven't happened yet need to be testable. Operators need to synthesise failure scenarios, not just replay past events
Wireframes
Early Explorations
Test Timeline
AI payload assesment
AI assessed Results
In-line results
The validated design direction
Design
04
The Solution
A Five-Part Integrated Sandbox
The proposed Filter Validator brings together five interconnected components
1
Capture Payloads
Per-source toggle
2
Browse Library
100 real payloads
3
Build Conditions
Guided + JSONPath
4
Run Test
All conditions
5
Read Results
Per-condition T/F
Component 01
Payload Capture - Turning the Source into a Testing Asset
The journey starts at the Sources page. A Capture payloads toggle on each source row lets operators switch their source into capture mode meaning every incoming event payload is stored for inspection.
A toast notification confirms capture is active. From the overflow menu on any source, operators can access View payloads to see everything that's been collected. Up to 100 payloads per source are stored, cleared after 7 days of inactivity unless starred as favourites.
-
Per-source opt-in only capture where you need it
-
Favourites prevent valuable payloads from expiring
-
Overflow menu gives direct access to the payload panel
-
Toast confirms state change immediately
Component 02
Payload Library - Real Data, Right in the Filter Builder
Inside the filter creation panel, the Payload Details section presents a two-column view. The left column shows a scrollable list of captured payloads searchable, sortable, with star icons for favoriting. The right column renders the full JSON of the selected payload with line numbers and copy/edit controls.
Operators can also add entirely custom payloads to test edge cases that haven't occurred in production yet, and edit existing ones to simulate variations.
-
Search and sort across captured payloads
-
Full JSON viewer with line numbers
-
Edit existing payloads or add custom ones
-
Star icon protects important payloads from expiry
-
Source name, type, payload ID, and format shown in context
Component 03
Dual-Mode Condition Builder - One UI for Two Very Different Users
The most complex design challenge: serving a non-technical operator and an experienced developer in a single condition builder without compromise.
The solution is a layered approach. Three dropdowns - Event type, Event subtype, Severity - auto-generate a JSONPath expression in a read-only preview below. This handles the majority of operator needs without writing a single character of code. Below an explicit "AND" pill, a free-form JSONPath text area handles everything more complex: location filtering, threshold comparisons, nested field logic.
These two modes are always AND-linked- they compose into one filter, not two separate paths. The generated expression is transparent so developers can always see what's been built.
Component 04
Conditions Table - Visibility and Control Across All Rules
Each time a condition is configured, Add condition adds it as a row in a table below the builder. The table gives operators a clear view of everything in their filter condition expression, advanced condition, and an enable/disable toggle per row.
The overflow menu on each row exposes granular actions. Critically, Test Condition runs validation for that one condition only - useful when debugging a specific rule without re-running the entire filter.
-
Enable/disable individual conditions without deleting them
-
Overflow menu: Test condition, Edit, Duplicate, Delete
-
Test filter button evaluates all enabled conditions together
-
Informational banner explains the test workflow inline
-
Pagination for filters with many conditions
Component 05
Test Results - Feedback Before Anything Goes Live
After clicking Test filter, a Test Results panel expands below. It shows exactly which payload was tested against, then lists every condition individually with a green True or grey False result badge alongside the full expression.
This is the core unlock of the entire feature. Operators can see at a glance that Condition 1 passed but Condition 3 failed and immediately return to the builder to fix that specific expression. The feedback loop that used to require production traffic and post-mortem debugging now happens in under a minute, before the filter is ever saved.
What changed and what comes next
Impact
05
Results
Outcomes
Validated in usability testing
91%
Task completion in usability testing
8.4
UMUX score for the preferred concept
4.3/5
User satisfaction score
<5m
Average time on task
Projected business outcomes (pending phased rollout)
Filter error reduction
Targeting a 68% decrease in misconfiguration-related support tickets by giving operators a validated filter before it ever touches production, eliminating the trial-and-error cycle
Setup time
Targeting sub 5 minute filter creation end-to-end, down from the 35+ minute observed average. Payload capture and the inline condition builder eliminate the need to switch between documentation, payload.
Operator confidence
Targeting measurable increase in self-service filter configuration without support intervention. Reducing dependency on IBM support teams for validation.
Platform differentiation
First enterprise cloud event notification platform with pre-deployment filter testing. Positioning IBM Event Notifications as the only enterprise choice with a built-in configuration safety net. Patent pending.
Competitive Differentiation
What This Means Beyond the Feature
First in the market
No competitor - AWS, Azure, or Google - offers an integrated pre-deployment filter testing sandbox. This is a genuine platform differentiator, not an incremental improvement.
Patent-pending innovation
The closed-loop system payload capture → library → condition builder → per-condition test results is being filed for patent protection as a novel method for event filter pre-deployment validation.
Lower barrier to enterprise adoption
By making filter configuration accessible to non-developer operators, the feature expands IBM Event Notifications' addressable user base beyond technical teams alon