Impact

Incrementally improving navigation using a cheap & cheerful approach

Summary

ChartHop’s navigation had grown through years of feature additions without a coherent plan — cluttered, inconsistently organized, and showing users things they couldn’t even access. Wayfinding was a problem for everyone: daily admin users who got lost after interruptions, and infrequent users who just needed to find one specific thing quickly. The team was lean after three rounds of layoffs. A full IA overhaul was off the table due to engineering constraints. The challenge was delivering real, lasting improvement within those limits.

Note: a parallel workstream on list tables, standards, and design system adoption — which ultimately enabled some of the Phase 2 nav work — is covered in a separate case study.

Problem/Context

For daily users (admins): navigation was cluttered and not organized as expected. Hard to find things, hard to find them again after an interruption.

“It always takes me more clicks than it should” — a consistent pattern across user feedback.

For infrequent users (managers, employees): visiting with a specific goal, often time-sensitive, but confronted with a nav full of items they didn’t have access to.

“I’ve grown to love the utility of ChartHop, but it’s not a delightful experience” — a user’s honest assessment that stung because it was accurate and preventable.

The constraint: engineering confirmed early that the underlying nav implementation was brittle enough that a fundamental IA restructuring — workflow-based primary nav, consolidating core nav items — wasn’t feasible on our timeline. Bit of a bummer, but better to know that upfront and design within it than to discover it after months of work.

The Solution

Discovery and working groups

Keeping the approach cheap & cheerful, I mined existing data (previous user research, Delighted, Zendesk, ProductBoard, Slack, Heap), conducted a staff survey, did a platform audit, and looked at competitive solutions. To maximize efficiency & collaboration, I set up working groups (PM/Design leads, Eng leads, CX SMEs, internal HR users) with weekly 30-minute sessions to gain user insights, prioritize upcoming work, validate designs early and often, and build alignment.

Quick wins, shipped first

High-value, low-effort fixes went straight to the backlog as written stories — no design file needed. Back buttons now consistently return to previous context rather than resetting state. Clicking a job or person opens a contextual panel overlay rather than navigating away. Right-click to open in a new tab became consistent platform-wide. Small changes, but they removed friction that daily users repeatedly encountered.

Phase 1: top bar and utility nav

Global search moved front and centre. Breadcrumbs standardized across all pages. Linked the org switcher to the org name in the breadcrumb to make context explicit. Utility icons (help, support, notifications) moved to the top header for prominence. Consolidated the two menus for Settings and More into a single menu. These changes were impactful and structurally safer — a better platform for the harder left nav conversation to follow.

Phase 2: left nav — scoped redesign and an unexpected opportunity

The left nav was where the biggest problems lived and where the engineering constraints were sharpest. Originally, significant changes were scoped out as too expensive. Then, partway through the initiative, work on the parallel list table and UI library project had an unexpected side effect: engineering flagged that the brittleness blocking left nav changes had been substantially addressed. I moved fast.

Final designs

The redesign: visual design and interaction overhauled, secondary nav became a scrollable panel instead of flyout menus, separators to break long lists into digestible groups; all menus moved to alphabetical order; and — most impactful for managers and employees — items users didn’t have meaningful access to were hidden. The nav went from showing everyone everything to showing each user what was actually relevant to them.

What I’d Do Differently

There are always strong opinions when it comes to nav, and this project was no different. When the opinion belongs to the founder and it contradicts a data driven decision, the situation can become fraught.

For example, we spent a lot of time going back and forth on the secondary nav in Settings, where it was clear he had strong opinions though user data was indicating a different structure. However, Settings was only relevant to admin users (about 10% of the user base) and even though they were in ChartHop every day, they rarely dipped into Settings.

In this case, I think I would release with his vision of structure sooner, then make a case for changes post-alpha/beta if a larger corpus of user data led us that way.

Ask me more

Happy to go deeper on the phased approach, the working group model, the validation process, or how the parallel list tables work unexpectedly unlocked Phase 2.