Understanding team health
Which DevOps engineers were most interrupted during off and sleep hours? Which major incidents did teams experience, and how long did it take to resolve those incidents?
Monitoring service performance
Which technical services went down frequently? Which of them require more resourcing? What was the impact to customers and business during downtime?
As a company, PagerDuty firmly believes that time is the most valuable currency in our society. Better decisions can be made when teams are empowered with the right information at the right time. Thus, any user with a curious mindset will specifically use analytical products to get more information about the “what”, “why”, “how”, and “when”. Data presented in PagerDuty Analytics helped users with exactly these questions—with the central and unifying theme being—what is the impact of incidents on my teams, business, and customers?
Process and involvement
Keeping that theme in mind, I designed the Analytics product experience in order to enable users to better understand team health and service performance for their digital operations. The goal was to help teams strive towards continuous improvement in their organizations. This was initially tackled with the release of Intelligent Dashboards at Summit 2019, which also got featured by TechCrunch.
- User interviews
- Usability testing
- UX metrics
Designing an analytics product experience can be a complex task compared to designing checkout flows. There is no right or ideal path. There is no specific start or end. It all depends on the level of information the user is looking for. Some users want additional details while others may only care about high-level metrics. But insights must be provided at the speed of thought in order to curb uncertainty. This is why it was important to develop dashboard principles for our team to follow. For example, user exploration must be limited to a certain extent. Otherwise, users could end up with information paralysis where they’re continually searching for every data correlation possible. This is not ideal for majority of the users, as ultimately they want to make business decisions from these data. Therefore, the goal of a dashboard should be effective communication—with the most important information presented at the top. At first glance, users should be able to spot trends, gather insights, and determine the next steps that they may need to take. In addition, visually red and green should only be used to indicate negative and positive trends while neutral colours like grey, blue, and purple are best suited for actual visualization of data. Using these colours incorrectly can be harmful towards interpretation of data. Legends must also be clearly visible on charts, and numeric and text labels must be clear, legible, and aligned to their respective data table formats (e.g., right-align for numbers, left-align for strings).
Aside from designing the product experience for Intelligent Dashboards from ground up, I later started supporting an existing feature of PagerDuty Analytics—known as Operational Reviews—which represented similar yet static information to the user regarding team health, service performance, and business impact. Working on this feature led to a realization of how broken the overall product experience is for PagerDuty Analytics. This was also evident from user interviews, where questions like “How is this feature different from X?” or “Why does metric X vary and exist in two different areas of PagerDuty Analytics?” would often come up.
With more user interviews, it became clearer that this is indeed a big problem that needs to be addressed. Furthermore, when users requested for additional insights or data, they would always be centered around team health, service performance, and business impact. Given that the product experience of PagerDuty Analytics was so fragmented, I started working on a “metrics map” that would roughly showcase the information architecture, and would later become the foundation for a blue sky design exercise.
After convincing my Product Manager, I started on this blue sky design exercise to unify the product experience of PagerDuty Analytics—keeping the impact of incidents on team health, service performance, and overall business at the core of the experience. One of the goals of this exercise was to build an improved product experience for post-wartime context to help users understand the entire lifecycle of incidents (what caused it, when did it happen, who did it affect, and how long did it take to resolve). Other goals were to showcase what the future of the product could look like, and also get internal Product + Engineering teams and our users excited about its possibilities.
Aside from core Analytics product involvement, I led and/or supported initiatives in areas relating to design systems, design ops, and mobile.
Design system. I collaborated with UX + Engineering teams to establish processes as well as design and technical requirements for general UI components. This included conducting an audit of existing components, developing requirements and guidelines for UI components in Analytics, and assisting with integrating design components with their code components using Storybook.
Design ops. I supported the UX team with on-going design tool assessment by conducting internal user research and organizing information sessions. Additionally, I continuously pushed to improve product development processes and established the importance of UX metrics within the Analytics product group.
Mobile. I led the concept and design for customizing app icons for PagerDuty on iOS, which won a HackDay project in November 2019. Since PagerDuty had gone through a new and colourful brand refresh a few months earlier, my idea was to translate that to mobile in a simple and delightful way for the user. Allowing users to customize the PagerDuty app icon is just the beginning.
Technological constraints. As a designer, the biggest challenge working on PagerDuty Analytics, specifically with Intelligent Dashboards, was dealing with technological constraints. For example, the front-end of the product was powered by a BI tool known as Periscope. That severely limited the possibilities of the overall product experience. It was critical to understand Periscope’s limitations in order to design an experience around or with them.
Data exploration. The “drill down” functionality of charts needed to be limited, otherwise the user flow could get confusing very quickly. How much further should the user be allowed to go when drilling down into charts and related data? How do you indicate the level of navigational hierarchy to the user? How would this interaction look and function across multiple charts? The answers depended on the story being told with the data.
Decision automation for enterprise retailers
Visualize a year-long journey
Improve home comfort with heat loss maps