Company: Chronosphere — unicorn-status observability platform, acquired by Palo Alto Networks 2025

My Role: Lead Designer and Researcher

Team: Principal Product Manager · 2 Backend Engineers · 2 Frontend Engineers

My Contribution: User research · Product strategy · Information hierarchy · Interaction design · Data density system · Design system contribution · Responsive design

Status: Early Access — designed and validated with real users, awaiting full rollout

Context — Two Personas, One Broken Page

In observability platforms like Chronosphere, there are two distinct types of users:

Makers — SRE admins who set up and maintain monitors. Their job is to configure what to watch, refine thresholds based on data, and optimize to reduce noise. Their work happens during peacetime — when systems are stable and there's time to think deliberately.

Responders — on-call engineers who get paged when something breaks. Their job is to investigate, mitigate, and remediate — fast. Every minute of confusion costs the business. Their work happens during wartime — under pressure, with no room for noise.

Before this project, Chronosphere had one page serving both personas. That's the problem we set out to solve.

Problem

The monitor page was built for Makers. But when Responders got paged, they landed there too — confronted with configuration tools designed for peacetime, not investigation.

One example: an attribute-based monitor selector that Responders had no use for during an incident — and couldn't figure out how to reset. The wrong tool, at the wrong moment, for the wrong persona.

There were no loud complaints — because there was nothing better to compare it to. But the latent need was clear: Responders deserved their own purpose-built experience.

How might we design a dedicated alert experience that gives Responders exactly what they need — and nothing they don't?

My Role — and How We Got Unstuck

I co-led the research with our shared researcher, defined the information hierarchy, and made key design decisions independently while collaborating closely with engineering to shape the solution.

This project wasn't without friction. A significant conflict emerged between the PM and lead backend engineer on product direction. Rather than letting competing opinions stall progress, I used research findings as neutral common ground — reframing the decision around user needs and data. That shift unblocked the team and kept the project moving.

Research — Understanding the Responder's World

I conducted interviews with on-call engineers and shadowed them during active on-call shifts — observing how alert investigation actually works under real pressure, not how people remember it afterward.

Key insights:

• Responders don't read — they scan. Visual hierarchy isn't a nice-to-have, it's survival

• Context is everything. Without related signals surfaced automatically, engineers piece together what happened manually — adding precious minutes to every incident

• Configuration tools create cognitive noise during investigation — Responders need the page to disappear everything that isn't relevant to the current incident

• Change events are critical — recent deploys and configuration changes are the first thing engineers look for when an alert fires

The Most Important Design Decision — Information Hierarchy

The foundational decision was defining what is primary data versus metadata — and how each should appear on the page. This forced the team to align on what an engineer actually needs to see first, second, and never.

I chose to organize the page around the event — the start and end of an incident — rather than the system's data structure. A deliberate shift from the system's perspective to the engineer's mental model.

From this decision, I developed a new data density specification and introduced it into Chronosphere's design system — so the principle scaled consistently across the entire alerting experience, not just this one page.