Overview
The what and the why
Building the Service Directory into the PagerDuty app, to better help responders diagnose and resolve incidents while on the go or in the middle of the night.
Role
UX Intern (Assisted with UX research, Designed UI)
Timeframe
Delivered August 2019
The User Challenge
As primary users of the the PagerDuty app, responders rely on the app not only to alert them to an incident (i.e., wake them up in the middle of the night if necessary), but the app also affords the opportunity to provide enough information to determine if something is actually an issue or not. That is, a responder needs to decide if this is something that needs to be addressed now, and if so, how bad of an issue is it. One piece of that information is understanding what service the incident lives on. But the PagerDuty app in its current form had little to no service information.
Understanding the user’s experience
As part of a much larger project to redesign the Service Directory as a whole, I had the benefit of customer interviews and research the team (and I) had done. That gave us the base from which to explore the current experience in the app and identify gaps. I facilitated a mapping experience with our engineering team and uncovered some very clear areas to improve.
The workshop revealed multiple dead ends, where a responder would be unable to find the service information. In some parts of the app, the service name was shown, but there was no way to tap in for more information.
Designs
For the mobile designs, I built out access to the service, with an emphasis on information hierarchy. Most importantly, we had the service status and number of incidents, followed by who was on call. (On-call being the responder’s most useful piece of information if an incident involves multiple services and teams). Other data including description and business services, were all information that could give the responder as sense as to the scope or scale of the issue.
In addition to building out the service details, I also designed the mobile version of the service directory, with an emphasis on being able to search for the service you needed. Key information included the name of the service and its status, as well as the team or escalation policy that owned the service. This was especially important when responders weren’t sure exactly what the service was called.
My designs were a first in a series of iterations, and laid the groundwork for a new version of the incident details/services pages that were built and released a couple years later.