De-risking a navigation overhaul with research and post-launch evidence

The 60-second version

The problem

The site offered multiple overlapping navigation systems, and behavioral analytics suggested confusion but could not tell us whether users actually understood labels such as "Live," "Learn," and "Work."

I owned

Research framing, stakeholder buy-in, study architecture, participant framework, task design, moderator scripts, execution materials, and the independent 28-day post-launch evaluation.

The pivotal decision

Before funding more design and development, validate whether the apparent navigation problem was real using human research rather than treating click behavior as self-explanatory.

What changed

The study validated the IA concern and helped support approval of a consolidated mega menu. After launch, early behavior was promising, but I recommended waiting for a 90-day sample before removing additional navigation.

My scope

Analytics showed behavior. They couldn't explain the behavior.

The Beltline site serves residents, visitors, volunteers, businesses, and community members looking for very different information. It offered several overlapping ways to navigate, and the behavioral data showed interaction across all of them.

Analytics gave us the what. Research was the only way to get at the why behind it.

My working hypothesis was that users did not understand the site's information architecture. Continuing to layer design and development on top of a potentially weak foundation would only make later corrections more expensive. That was the reason to research first.

The study wasn't on the roadmap. I first had to make the case for it.

Over approximately one month I did the work required to bring the study from an inference to an execution-ready program: research goals and success criteria, two proposed rounds, participant strategy, tool selection, recruitment approach, and schedule.

1. {{ step.n }} {{ step.label }}

The study was deliberately scoped to be practical and low-friction to approve. Participant incentives came to approximately $300.

I designed the study around what people actually came to the site to do

The six scenarios deliberately moved past generic navigation prompts. Each one represented a real reason a different audience relied on the site.

1. Task {{ task.n }} {{ task.label }}

Ten participants across three audience groups

• {{ p.n }} {{ p.label }}

The study was designed to travel cleanly from strategy to execution. The moderator reported that very little needed to change while running it.

The navigation problem was real, and it was broader than one label

The findings validated the central hypothesis. Rather than walk through all six tasks, three systemic themes carry the result.

1. {{ theme.n }} {{ theme.label }}
   • {{ item }}

Participant remarks are paraphrased. The source research decks were provided in confidence and are not reproduced here.

01 / Decision

Replace overlapping navigation with one clearer mental model

The study established that top-level navigation was the dominant starting point, the hamburger menu was largely avoided and explicitly described as redundant, on-page navigation mattered, and the Explorer hero became useful once discovered.

1. Before
   • Top nav
   • Hamburger
   • Side rail
   • Utility links
   • Explorer
2. Research
   • Users guessing
   • Redundancy
   • Buried tools
3. Direction

   One clearer primary navigation system

What the research supported

• {{ b }}

Launch was not the end of the research question

Twenty-eight days after the new mega menu launched, I independently returned to the behavioral data. I pulled the available Hotjar records, compared before and after navigation behavior, analyzed how interaction was distributed across the mega menu, sidebar, and utility links, and produced the July navigation check-in and its recommendations.

1. {{ step.n }} {{ step.label }}

My analysis  ·  28-day post-launch check. The research helped support and secure approval for the navigation change; it was not the only input into the team's implementation decisions.

02 / Decision

The numbers looked good. That did not make them conclusive.

• {{ ind.value }} {{ ind.label }}

A promising metric had at least four reasons not to declare victory

1. {{ c.n }} {{ c.label }} {{ c.note }}

Users wanted the tools. They did not necessarily want the sidebar.

Low sidebar usage did not prove users rejected the underlying tools. The same tools performed better elsewhere, which made the real question one of placement and redundancy.

03 / Decision

The most valuable recommendation after launch was to wait

The early evidence leaned toward consolidating navigation further and retiring or slimming the sidebar. Twenty-eight days was not enough to justify an irreversible change.

1. Early signal Simplify
2. Evidence quality Not mature enough
3. Decision Wait for 90 days

What I recommended

• {{ r }}

This preserved the team's ability to simplify the experience without making an irreversible decision from an immature data set.

Research changed the navigation decision, then measurement protected the next one

• {{ item }}

The 90-day check should answer a narrower question

• {{ m }}

If moderated research were available in a later phase, it could test whether comprehension and task success actually improved. That follow-up had not been scheduled at the time of the check-in.

Research leadership includes knowing when the evidence is not ready

The first decision required human research because analytics could not explain intent. The second required restraint because early analytics looked better than the evidence quality justified.

In both cases the goal was the same: make the next product decision with the strongest evidence available, not the most flattering story.