Application Performance Management (APM)

IBM | 2014-2016

APM is a SaaS solution that monitors application health, helping companies quickly address issues and ensure an optimal user experience.

APM Product Website

Project Overview

Title: Application Performance Management (APM)
My Role: UX Designer
Team: Design Lead, UX Researcher, Visual Designer, Front End Developer, UX Designer
Duration: 1.5 years
Impact: The redesigned APM experience drove a 14% market growth, securing a 15.2% share within IBM’s performance management segment.

Context & Problem Definiton

Background: Even brief outages can cost millions. APM helps prevent them by identifying issues before they become outages
Target Users: DevOp users responsible for monitoring apps
Problem Statement: How can companies identify system issues as quickly and efficiently as possible?
Constraints:

Research & Discovery

Methods: Observation, Persona Creation & Validation, and Prototype Testing
Key Insights:
Impact on Direction: Identified strategies to maintain 99.99% uptime, prevent outages, and accelerate app development

Persona Creation

After observing DevOps users, I identified key insights to informed the creation of a user persona:

Shift from status quo processes to a unified monitoring experience
Surface issues first to speed awareness and response
Use correlation to identify patterns and diagnose root causes
Provide detailed error types to help teams prioritize effectively
Enable quick drill-downs without “fishing” for information
Reduce alert fatigue by minimizing noisy signals
Advance toward automation and self-healing systems

Phase 1: Observing DevOps Users

To grasp the impact of downtime, I studied DevOps users’ daily workflows, communication, and tools

Phase 2: Identifying Hills and Solutions

At IBM, a “hill” is a user-centered goal statement that aligns the design team and defines the path forward

Phase 3: Quickly Iterating and Collecting Feedback

Attended weekly feedback sessions to capture insights firsthand and rapidly iterate on prototypes and wireframes

Maureen

“I want to quickly know if the problem is in my application or somewhere else.”

— Maureen, 32, Senior Developer, DevOps Cloud Delivery

Likes

Focusing on writing and deploying code
Being nimble and efficient
Making her company more efficient instead of just fixing issues

Seasoned developer with 10 years experience in traditional application delivery
Wants to build scalable and efficient cloud service
Wants to spend her time improving things instead of fixing them
Wants to build apps quickly, like startups do, without being bogged down by testing and support

Dislikes

Acting as the internal company support team
Firefighting issues
Infrastructure management
Interrupted coding that takes her out “the zone”

Ideation & Design Process

Hills

The initial designs stemmed from three hills. Using research and Maureen’s persona needs, I brainstormed experiences to address each hill and enhance her journey.

Hill #1: Quick setup & monitoring

A DevOps user can quickly set up monitoring—seeing availability and response times within 20 minutes (5 on Bluemix)—and is guided to add more monitoring value over time.

—-

• Ping and check responses for apps, URLs, and locations

• Send alerts via email, SMS, or IM based on user preference

Hill #2: Isolating the problem

A DevOps users can isolate issues in their domain—or another team’s—within three clicks..

—-

• Display overall app health in Bluemix

• Indicate performance status (good/slow, up/down)

• Enable UI customization to fit user needs

Design Iterations: Hill #2

User feedback revealed Hill #2—isolating problems—as the top priority. I began designing with a customizable dashboard that let Maureen organize her most relevant information.

The dashboard used drag-and-drop customization, allowing Maureen to rearrange and save layouts. She could create multiple presets tailored to specific needs, swap them as priorities changed, and reuse or delete them as desired.

High-fidelity wireframes show Maureen using a custom dashboard to isolate a problem, built with IBM’s design system and style guide.

Hill #3: Finding the root cause

In under five clicks, DevOps users are guided to the probable root cause and supporting diagnostic details.

—-

• Quickly identify root cause (server or browser)

• Correlate log errors with issue timing

Design Iterations: Hill #1

For Hill #1, I designed flexible alert notifications so Maureen’s team wouldn’t need to constantly monitor the dashboard.

Based on restrictions and A/B testing, I focused on email alerts as the most feasible for near-term implementation. Below are medium- to high-fidelity wireframes and a scenario handed off to development.

Design Iterations: Introducing a New Concept

While designing for Hills #1 and #2, I began considering Maureen’s transition from free to paid APM for more space and advanced features. I sketched flows to explore key functionality and interactions.

Final Solution

APM enables DevOps teams to monitor performance, availability, and response times to quickly diagnose issues. User testing feedback was highly positive, leading only to minor design tweaks.

While I left before completing Hill #3 (isolating root cause), the team carried it forward, and it remains a core part of the APM platform.