“Do I need to act now?”
Understand severity, fix the issue, snooze it or involve the right person. The first decision may happen in the middle of the night.
Splunk
Project UME
A connected response. Wherever work finds you.
Unified Mobile Experience brought service monitoring, incident response and collaboration into a mobile-native workflow. I led the UX from concept to MVP.
Explore the story
View presentation ↗From the first decision to a connected mobile response.
01 / The problem
The alert was mobile. The response wasn’t.
At 3:18 a.m., an on-call engineer wakes to an alert. To find out whether it matters, she has to get out of bed, open a computer and sign in. Only then does she learn it can wait until morning.
The design problem wasn’t fitting a desktop dashboard onto a phone. It was giving someone enough context to decide what to do—wherever the interruption happened.
02 / Two needs
Respond urgently. Check in calmly.
“Is it being handled?”
Check service health and see whether the right people are involved, without having to perform the investigation themselves.
03 / The baseline
Every handoff asked people to reconnect the story.
The mapped workflow crossed VictorOps, Splunk, Jira and Slack. Investigation, ticketing and communication each demanded a different place to work.
- 01Alert
Receive and acknowledge on mobile.
- 02Investigate
Move to a computer and open ITSI.
- 03Coordinate
Create tickets and involve the team.
- 04Resolve
Communicate, document and close.
4Context switches
7Application switches
1Device switch
Minimum switches in the mapped baseline—not an average measured across users.
04 / My role
Design the response as a whole.
I worked with product managers to define the problems and activities behind monitoring and troubleshooting, then guided the UX from the initial concept to MVP.
Working closely with customers, I defined the workflows and partnered with a UI design lead to bring the experience to life. The team included a UX researcher, IT Operations and Incident Management PMs, and iOS and Android engineers.
Activities: heuristic evaluations, A/B testing, user testing and product strategy.
05 / Design exploration
Define the path. Then resolve the interface.
The monitoring hierarchy moves from an overview into a service, then a KPI and the entities behind it. The wireframes establish that path before visual detail.
06 / Monitoring workflow
Start broad. Reveal detail when it matters.
A service owner starts with overall health. The next step reveals KPIs; from there, a particular signal leads to its entities and their details. Each level answers a more specific question.
- 01Services
Which service needs attention?
- 02KPIs
Which signal explains its health?
- 03Entities
What contributes to that signal?
- 04Entity details
What do I need to know about it?
Design decision
Progressive detail, not a wall of metrics.
The entry view supports a quick check. Investigation remains available without asking every person to start at the deepest level.
07 / Incident workflow
One episode. Several ways to understand it.
An episode becomes the point of orientation. From its summary, the responder can inspect affected services and entities, look at the underlying alerts, or follow the team’s activity in the timeline.
- 01Find the episode
Filter the list and choose what needs attention.
- 02Assess impact
Read the summary and affected services.
- 03Inspect the cause
Follow entities, KPIs and alert details.
- 04Coordinate
Use the timeline to follow activity and communication.
Design decision
Keep the incident as the point of return.
The workflow connects specialist detail to the same episode, so investigation and collaboration belong to one story.
08 / The proposed change
Connect the work, not just the navigation.
Rebuild context across tools.
Alert → investigate elsewhere → find people → open tickets → communicate → document.
Carry context into each action.
Acknowledge → evaluate → involve people → investigate → update and close within one mobile experience.
The mapped UME flow targeted zero context and application switches on one device. Reducing resolution time was the ambition; it wasn’t a measured outcome established by this case.
09 / Customer response
The appeal was getting their freedom back.
The customer reactions captured in the original presentation point to the appeal of a less fragmented mobile experience.
“This would be so frickin’ cool”
Regional Field Technical Manager
“This makes me happy for the future! My headache is literally going away right now”
Software Developer
10 / What I take from it
Mobile is a context. Not a screen size.
Design for the first decision.
The 3:18 a.m. scenario reframes the priority: help someone decide whether to act, defer or route the issue before demanding a full investigation.
Shared data does not mean identical needs.
The service owner needs reassurance; the responder needs a path into detail. A shared information model can support both through progressive disclosure.
Collaboration belongs with the incident.
The episode and timeline connect technical signals with what people are doing. Communication should stay attached to the work it explains.
A simpler flow is a hypothesis to validate.
Mapping fewer switches makes the proposal concrete. Demonstrating faster resolution would still require task-based measurement, not just an enthusiastic reaction.
11 / The direction
From exploration toward Mobile Observability.
The original presentation records UME being incorporated into Splunk’s Mobile Observability application, with a planned Q4 2022 release. That is the documented plan, rather than a verified launch date.
The contribution was a connected mobile workflow: service health, the detail behind it, and the people responding—all with a consistent path through the experience.
← All selected work