The brief.
The platform sells in three layers — packages (commercial bundles customers buy), products (sets of services), and services (the functional UIs people actually use). The old navigation tried to mirror all three at once and collapsed under the weight.
The brief was narrow on paper — "fix navigation" — but the real question was which of the three layers belongs in the menu at all.
The answer: surface services as a flat primary list, and let categories sit inside the menu as an optional grouping layer — not a hierarchy users have to walk through.
What got in the way.
Which of the three layers belongs in the menu?
Packages are how the business sells, products are how engineering ships, services are what users actually use. Three valid mental models, one menu. Picking wrong meant either a sales-shaped UI no one could navigate, or a flat service list with no structure at all.
Naming churn during the project
Services kept being renamed mid-project by marketing, product and engineering in parallel. The IA had to hold up even when half the labels were still in flux — so the structure got built around stable verbs and groupings, not the volatile product names.
How I scoped it.
We inherited a working design system and the modular service split from the platform redesign, so the budget went into IA decisions instead of components.
The work ran in two passes — a structure pass (card sort + stakeholder workshops to settle the layer question) and a labeling pass (interviews + usability sessions to test names against the structure).
Four iterations total. Each round shipped a tighter tree and a longer list of names we'd ruled out.
Talked to people.
- Scalable as the service catalog grows — adding a service should not trigger an IA rewrite.
- Learnable without onboarding — first-time users should find what they need without a tour.
- Resilient to renaming — structure has to survive labels moving underneath it.
- Honest about the three layers — don't pretend packages and products don't exist, but don't force users through them either.
- Card sort with 15 participants to test which of the three layers matched real mental models.
- Interviews with stakeholders, customer support and several customers to surface label conflicts.
- Usability sessions across 4 iterations to validate the chosen structure against real tasks, not opinions.
The numbers we couldn't ignore.
- Customers thought in services, not packages or products — packages turned out to be a billing concept, not a navigation one.
- Categories tested well as optional grouping and badly as required hierarchy — users wanted to scan a flat list and use categories as visual chunking only.
- Naming consensus was impossible to reach in writing. It only converged in usability sessions, when users tried to actually find something.
What engineering said yes to.
- Must support new services landing every quarter without re-architecture.
- Must survive service renaming without breaking deep links or muscle memory.
- Must work for users who never read the onboarding — the menu has to teach itself.
Then & now.
Old nav → Shipped
From a Start-menu-style flyout tucked in the bottom corner into a top-bar launcher with a flat services list on the right and category filters on the left.
Concept → Shipped
The early concept grouped services into a category grid with a dashboard rail on the side. Testing showed users wanted to scan a single list — the shipped version keeps categories as an optional left-side filter, not a required path.
More details.
- Time-to-find for new users 60–90s → 25–40s, mistakes per task from "several" down to 1–2 max.
- Navigation now scales by adding a service to a flat list — no re-architecture when the catalog or categories grow.
- IA stayed intact across multiple service renames post-launch — the structure held even when labels moved underneath it.
Hierarchy is seductive on a whiteboard and brutal in production. The real win wasn't picking which of the three layers to surface — it was admitting categories work as scaffolding users can ignore, not as a path they have to walk.