{"id":1451,"date":"2026-01-17T06:00:07","date_gmt":"2026-01-17T06:00:07","guid":{"rendered":"https:\/\/levisohn.com\/portfolio\/?page_id=1451"},"modified":"2026-09-05T04:02:25","modified_gmt":"2026-09-05T04:02:25","slug":"global-nav-case-study","status":"publish","type":"page","link":"https:\/\/levisohn.com\/portfolio\/global-nav-case-study","title":{"rendered":"Global Navigation Research"},"content":{"rendered":"\n
<\/div>\n\n\n\n

Global Navigation Research<\/h1>\n\n\n\n

PagerDuty<\/strong> \u00b7 2020 \u00b7 Principal User Researcher
Methods<\/strong>: Card sorting \u00b7 Concept testing \u00b7 Tree testing \u00b7 A\/B testing \u00b7
Scale<\/strong>: 1.3M+ platform users \u00b7 15,000-user A\/B test \u00b7 37-participant tree test<\/p>\n\n\n\n

\n\n\n\n

The Problem<\/h2>\n\n\n\n

PagerDuty had grown fast. What started as an incident alerting tool had expanded into a multi-product operations platform \u2014 incident management, process automation, AIOps, service management \u2014 and the navigation hadn’t kept pace. Product teams had bolted on new surfaces over time, each making local decisions about where things should live. By 2020, the result was a navigation structure that made internal sense to the teams who built it but didn’t correspond to how any user actually experienced the product.<\/p>\n\n\n\n

The stakes were real. Navigation isn’t cosmetic in an enterprise platform \u2014 it’s the thing that tells users what the product believes about them. Get it wrong and users can’t find their work. Get it right and the platform becomes intuitive in a way that drives adoption, conversion, and retention.<\/p>\n\n\n\n

Research Approach<\/h2>\n\n\n\n

I started where the data already was: a full audit of the existing navigation structure, combined with stakeholder interviews with PMs, designers, and engineers across the platform. I treated these internal stakeholders as research participants \u2014 not just source material, but people with their own mental models about what the product was and who it was for. That decision mattered. It surfaced something that wasn’t in any analytics dashboard: the organization itself had three competing theories of how the platform should be organized.<\/p>\n\n\n\n

From there, I ran open card sorts to understand how users actually grouped the platform’s features, followed by closed card sorts to test three structural hypotheses that had emerged from the audit and stakeholder work: a role-based model (organizing by who you are), a Jobs-to-be-Done model (organizing by what you’re trying to accomplish), and an all-access model (flat, everything visible). Each represented a coherent theory. Each was also incomplete.<\/p>\n\n\n\n

After 25 card sorts, I made a call that turned out to be important: I stopped. The quantitative data was showing clustering patterns, but it wasn’t explaining them. Two participants could group the same items identically while reasoning about them in completely different ways. Understanding the pattern wasn’t enough \u2014 I needed to understand the logic underneath it. I pivoted to deeper qualitative sessions to probe the reasoning behind the groupings, which is what produced the insight that changed the project’s direction.<\/p>\n\n\n\n

The deeper sessions revealed four distinct behavioral archetypes with genuinely incompatible mental models about what the platform was:<\/p>\n\n\n\n