VictorOps
On-call response
AcknowledgeRouteCoordinateUnified Mobile Experience
On-call response.
With service context.
Bringing VictorOps and ITSI together on mobile.
UX lead · Concept to MVP
12:03 ••• ▰
‹ Episode 22···
EPISODE DETAILS
etcd cluster has insufficient members
k8s, Infrastructure · #SUP-928301
CRITICAL
AFFECTED SERVICES SHOW ALL
Web Store Sales125
AFFECTED ENTITIES SHOW ALL
mysql-0225
mysql-0210
mysql-0325
ALERTS
PrometheusEtcd main insufficient members
◈ ▤ ♙ ♧ ▣
Original monitoring UI; episode view rebuilt from Figma with names removed.
The opportunity
Two products.
One response.
VictorOps connects the alert to the person on call. ITSI provides the service intelligence needed to understand the issue.
ITSI
Service intelligence
ServicesKPIsEntitiesThe problem
The alert arrives.
The context doesn’t.
Investigation, ticketing and communication required people to reconnect the same story across tools.
Alert
VictorOps
Investigate
Splunk / ITSI
Track
Jira
Communicate
Slack
The use case
3:18 a.m.
Can this wait?
An engineer wakes to an alert. They open a laptop and sign in, only to discover the issue can wait until morning.
The first decision
ActDoes this require intervention?
DeferCan it wait?
RouteWho needs to be involved?
The users
Responding and monitoring
are different jobs.
On-call engineer
“Do I need to act now?”
Assess, investigate and coordinate the response.
Service owner
“Is it being handled?”
Check service health and see the response in context.
How an episode forms
Related events.
One episode to assess.
User-configured aggregation policies group related notable events. Episode severity follows the configured policy; status and ownership support triage.
Notable events
Signals and alerts
Aggregation policy
User-defined grouping rules
Episode
Severity · Status · Owner
Product mechanics: Splunk ITSI documentation. This project focused on the mobile response experience.
The organizing idea
The episode is
the point of return.
An SRE can assess the grouped issue, understand service impact and coordinate the response with the relevant context close by.
Episode
Assess → investigate → respond
ServicesEntitiesAlertsTimelinePeople
My role
Design the whole response.
Then connect the screens.
I led UX from concept to MVP, defined workflows with customers and product managers, and partnered with a UI design lead.
PartnersUX research, IT Operations and Incident Management PMs.
DeliveryiOS and Android engineering.
Design workMonitoring and troubleshooting workflows, prototype and evaluation.
Two entry points
One mobile experience.
Two ways into the work.
Incident view
Start with the episode.
Assess the issue, inspect its impact and coordinate the response.
Monitoring view
Start with service health.
Follow a signal from the overview into KPIs and entities.
Incident view · Wireframes
Keep the episode
as the organizing frame.
List → summary → supporting detail. Activity and people remain part of the response.
12:03 ••• ▰
‹ Episodes···
YoursTeamAll
Episode
Severity · State · Summary
Episode
Severity · State · Summary
◈ ▤ ♙ ♧ ▣
12:03 ••• ▰
‹ Episode summary···
Episode details
Description · Team · Ticket
Affected services
Service impact
Affected entities
Infrastructure context
Timeline + people
Activity and coordination
◈ ▤ ♙ ♧ ▣
Wireframes redrawn from the Figma structure; names removed.
Incident view · Interface
See the impact.
Choose the next step.
The summary puts service impact, affected entities and source alerts together.
12:03 ••• ▰
‹ Episode 22···
EPISODE DETAILS
etcd cluster has insufficient members
k8s, Infrastructure · #SUP-928301
CRITICAL
AFFECTED SERVICES SHOW ALL
Web Store Sales125
AFFECTED ENTITIES SHOW ALL
mysql-0225
mysql-0210
mysql-0325
ALERTS
PrometheusEtcd main insufficient members
◈ ▤ ♙ ♧ ▣
Service impactUnderstand what is affected.
EntitiesFind the infrastructure behind it.
AlertsInspect the underlying signal.
Interface rebuilt from Figma with anonymized labels; source example values retained.
Coordination
The conversation belongs
with the incident.
A timeline records alerts, acknowledgement and paging alongside the people involved.
12:03 ••• ▰
‹ Timeline···
ALL CHAT MENTIONS
Slack channel set
Updates linked to the response.
Acknowledged
Responder acknowledged. Stopping paging.
Page attempt
Contacting the on-call responder.
Alert · Critical
Underlying service signal recorded.
PEOPLE
◈ ▤ ♙ ♧ ▣
Rebuilt from the source timeline with names and handles removed.
Monitoring view · Wireframes
From an overview
to a specific signal.
The hierarchy supports a quick check and a deeper investigation without treating them as the same task.
12:03 ••• ▰
‹ Monitor···
AllStarred
Service analyzers
Grouped dashboard list
Other dashboards
Saved entry points
◈ ▤ ♙ ♧ ▣
12:03 ••• ▰
‹ Service···
Performance
Service signal over time
KPIs
Contributing indicators
Critical episodes
Related incidents
◈ ▤ ♙ ♧ ▣
12:03 ••• ▰
‹ KPI···
Performance
Selected metric
Entities
Underlying contributors
◈ ▤ ♙ ♧ ▣
Redrawn from the original monitoring wireframes: monitor → service → KPI / entities.
Monitoring view · Interface
Scan the services.
Find what matters.
The original UI gives each service a label, value and trend. The next level reveals its contributing signals.
Monitoring view · Detail
Follow a KPI
into its entities.
The entity view exposes role, service, operating system and the underlying contributors.
The proposed response
Carry the context
through the work.
Assessment, investigation and coordination become parts of a connected mobile response.
Assess
Episode + impact
Investigate
Services + entities
Coordinate
Timeline + people
Testing
Value for the user.
Concerns validated.
What we learned
Testing demonstrated value in the connected experience and validated concerns the team had identified.
The project included heuristic evaluation, A/B testing and user testing.
Customer feedback
“This would be so frickin’ cool”
Field technical leader
“My headache is literally going away right now”
Software developer · excerpt
Qualitative findings; no quantified resolution-time claim.
Learnings
Start with the decision.
Reveal the depth.
Mobile changes the contextThe first need may be deciding whether to act—not conducting a full investigation.
Different entry points matterMonitoring and response use the same information with different intentions.
Coordination is part of the taskKeep technical context and the people responding connected.
Outcome
A direction for
Mobile Observability.
The original case study records UME being incorporated into Mobile Observability.
The contribution
A connected workflow across service intelligence and on-call response.
The source records a product direction and planned release—not a verified launch or quantified performance improvement.