Redesigning Global Navigation
Context
PagerDuty is an incident management platform used by approximately 1.3 million users across 30+ features. Engineers, SREs, and on-call responders rely on it to detect, triage, and resolve production incidents under real operational pressure.
I initiated this project independently—no executive assigned it. Eight months into my role, I identified a critical problem through analytics exploration: the global navigation had grown organically over eleven years, creating a fundamental mismatch between how the product was structured internally and how customers understood it.
Using SQL queries against Snowflake and Pendo analytics, I identified converging signals that navigation was a high-leverage problem worth solving:
- 15% feature discovery rate among new users
- 7+ days average time to complete initial setup
- 22% of support tickets were navigation-related
A “CONFIG” menu had become a repository for every new feature—an engineering concept with no connection to user mental models. Navigation was blocking both user success and business growth.
Research Approach
I scoped the project into three phases with explicit decision checkpoints, designed to reduce uncertainty at points where decisions would become irreversible.
- Qualitative interviews (N=24)
- Card sorting with think-aloud (N=8 deep sessions)
- Competitive analysis
- Analytics review
- Behavioral segmentation
- Tree testing (N=37)
- Prototype testing
- Stakeholder co-creation
- A/B testing (15,000+ users)
- FullStory behavioral analysis
- Support ticket analysis
- ROI modeling
The Strategic Challenge
Product leaders favored a Jobs-to-be-Done framing (Incidents, Services, People, Analytics, Status), while engineering advocated for an Action-Based structure (Prepare, Respond, Review). A third camp preferred incremental improvement. Prior attempts to reconcile these had failed, and the disagreement was consuming leadership attention.
I faced a critical decision: should I select one internal proposal and iterate, create a hybrid structure, or reframe the problem entirely around user mental models?
| Option | Advantages | Disadvantages |
|---|---|---|
| A: Select one proposal | Faster decision, clear ownership | Risked reinforcing disagreement |
| B: Create hybrid | Satisfied multiple stakeholders | Vague labels, no governing logic |
| C: Reframe around users | Evidence-based, durable framework | Required additional research investment |
I chose Option C. The deciding factor: the organizational cost of continued disagreement exceeded the cost of additional research. This decision shaped the entire project trajectory.
Key Findings: Four Mental Models
The most consequential methodological decision was pivoting mid-project from quantitative to qualitative methods. After 25 card sorts, I recognized I had clustering patterns without understanding of underlying reasoning. I proposed shifting to 8 in-depth 75-minute sessions with think-aloud protocols—smaller sample, richer insight.
Critical Insight
The research revealed four behavioral segments with incompatible mental models. Two participants might group identical items while applying completely different logic—the similarity matrix showed agreement; the reasoning diverged. This insight informed product decisions for years afterward.
I also conducted stakeholder research, treating internal partners as study participants. Product management interviews (N=12) surfaced concerns about quantitative proof; engineering interviews (N=8) revealed technical debt anxieties; executive interviews (N=4) focused on ROI and timeline. This allowed me to frame findings in terms each group valued.
Validation: Tree Testing & A/B Testing
I conducted segmented tree tests (N=37 across two variants) to evaluate proposed navigation structures against the identified mental models.
While tree testing eliminated clearly poor structures, several options tested as “adequate.” We escalated to A/B testing (15,000+ trial users) to distinguish adequacy from excellence with real behavioral data.
Post-Launch Impact
I tracked post-launch metrics to understand how the redesigned navigation performed in production.
Outcomes
Rather than selecting the “right” internal model, the team aligned on designing for user jobs-to-be-done informed by the four behavioral segments. The project exceeded all success criteria:
The organizational impact extended beyond the immediate metrics. As a direct result of these learnings, we codified navigation placement principles and established a lightweight governance group to ensure future changes were evidence-backed.
Reflections
What Worked Well
- Early reframing: Shifting the discussion from “which proposal is best” to “what problem users are actually solving” prevented prolonged debate and enabled evidence-based tradeoffs.
- Methodological flexibility: Eight deep, contextual sessions revealed more actionable insight than 75 shallow ones would have. Depth mattered more than sample size.
- Stakeholders as research subjects: Interviewing PMs, engineers, and executives before presenting findings allowed me to convert potential resistance into advocacy.
What I Would Do Differently
- Involve analytics earlier for clearer baselines
- Formalize the behavioral segmentation framework sooner for downstream reuse
- Front-load contextual inquiry—the four behavioral segments were the project’s most important discovery
- Push harder when research evidence conflicted with stakeholder preferences