UX case study · Ahotu

Mega Menu 2.0

Redesigning the primary navigation for Ahotu, the world's largest endurance sports calendar. A click here has to work for three different purposes at once: the athlete hunting for their next race, the first-timer who's never used the site before, and search engines trying to crawl the whole thing.

Role
UX Designer
Team
Design Lead, Product Manager, Developer, Tech
Scope
Flyout Mega Menu for Improved Navigation and Event Visibility
Source
Jira DEV-5924 · DEV-5881 (SEO)
01

The short version

Ahotu lists endurance races in 193 countries. Its old navigation was a flat dropdown that couldn't hold that, and every fix had to work two ways at once: for a person clicking through, and for a search engine crawling every link. Along the way, we ran into real problems. At certain breakpoints the columns started overriding the available screen space, so we had to design a fallback instead of forcing everything to fit. Some sports also needed their distances rethought into curated spans rather than raw numbers, so users could filter by something they'd actually recognize. Mobile turned out to need a completely different filtering solution than the desktop mega menu, and a 'Right Now' column went through a lot of testing but ultimately didn't make it into the final release.

6

top-level categories

4

filter columns, shipped

28

sports, distance-audited

Jira DEV-5924 · parent epic DEV-5881 (SEO)

02

The brief

Behind the ticket was a simpler problem: the old filtering hadn't kept up with how the site had grown, and a menu that couldn't keep up made Ahotu feel outdated to the athletes it needed to convert. The goal wasn't just a new component: it was a menu effective enough that someone could find their race without friction, and credible enough that Ahotu looked like the platform it actually is.

The ticket asked for a flyout mega menu that made bookable events, top event countries, and event highlights easy to find, while staying fully crawlable. Two disciplines had to agree on the same component: Usability and SEO.

Had to work for people

  • Expands on hover or click, without hiding content from search engines
  • Responsive and accessible: ARIA roles, full keyboard navigation
  • Menu load time can't hurt page speed

Had to work for crawlers

  • Every item a real HTML <a> link, not a JS click handler
  • Rendered server-side, present in the initial HTML
  • schema.org SiteNavigationElement markup
03

Research & discovery

Before drawing anything, we built a reference board to explore how other e-commerce and outdoor retail sites approach mega navigation. We looked at ka-yo.com, Zalando, The North Face, YETI, Care of Carl, and Dometic's. IKEA also became a recurring reference throughout the project. Its approach to navigation helped inform several different decisions at different stages of the design process.

Click to view full size
References board. Benchmarking flyout structures across ka-yo.com, Zalando, The North Face, Boozt, Bataleon, YETI, Care of Carl, Outnorth and IKEA before any Ahotu screens were drawn.

Research also meant testing our own site. An earlier exploration looked at what happened after someone clicked a category in the menu and landed on the results page, and that's where we found the real problem the whole project ended up solving.

Click to view full size
Filter Exploration @ahotu. Clicking through a flat category list pre-selected every subcategory as a removable chip at once: 8 tags a user had to manually clear before the results meant anything. Our own note on the board: "users are met with multiple pre-selected filters which creates friction."

Three iterations later, that same click led to just two filters being applied: 'Trail running' and 'Half marathon.' The country wasn't forced on the user either: it was just a suggestion they could pick or ignore. That's the real reason behind the final menu layout: instead of clicking one category and having everything pre-selected for you, Distance, Popular Countries, Month, and Popular Events each became their own separate option, so a user could pick from any of them, in any combination, on their own terms.

04

Finding the structure

The final column structure didn't emerge all at once. It evolved step by step, starting with sports, then adding Distance, Popular Countries, and eventually exploring two different approaches to the Popular Events section.

Each iteration was tested against real data as early as possible. Placeholder content was quickly replaced with actual event names and event counts to understand how the structure would perform at scale. From 2,406 events in the United States and 1,406 in France to 650 in Canada and 320 in South Korea.

Sport prioritisation was also based on sales data rather than intuition. Running generated 454 sales, followed by Trail Running with 239, Triathlon with 71, and Walking with 49. This helped guide where we focused our attention first, with Running and Multisports receiving the deepest exploration early in the process.

05

Building the system

The sub-nav pill started as a single Figma component with three states: default, hover and active. It is the small selector used to switch between categories like Triathlon, Duathlon and Swimrun. I first built it for Running, then adapted it for Cycling before scaling it up to the full eight-item Multisports navigation. From there, every pill across the project was built from the same component, keeping the interaction and visual behaviour consistent.

The less visible part was making everything work. With seven or more horizontal sub-nav variations, every click, hover and active state had to behave consistently, including the correct underline state. It's the kind of work that disappears in the final design, but getting those small interactions right is what makes the experience feel seamless.

Click to view full size
The sub-nav pill component. Built once with default, hover and active states, then reused across every pill in the project, and scaled from Running and Cycling up to the full eight-item Multisports navigation.

A parallel taxonomy problem, running underneath the UI work: the old site's distance filters used checkboxes on some sports and free min/max fields on others. A fixed, clickable mega-menu column can't hold either: it needs one curated list, decided sport by sport.

Click to view full size
Distance exploration. A sport-by-sport audit across roughly 28 sports: Alternative (external reference standards) against Ahotu (existing site) against Final (adopted list), with a change/no-change legend for every row.

Doing this by hand for Running surfaced something nobody had caught before: the live filter order was Ultramarathon, Marathon, Half marathon, 5 km, 10 km. Five kilometers listed before ten, in a list that's supposed to run longest to shortest. A real ordering bug, live in production, found only because every value was being manually re-typed and checked. "Nobody had seen it, but I found it."

The same audit is also where the 'span' idea came from. Niche disciplines like Aquabike and Aquathlon don't have a few standard race distances the way a marathon does. On the old site, that was handled with a free-text field where a user typed in their own minimum and maximum distance, but a fixed menu column can't offer that kind of open-ended input. So instead of forcing a text field into a simple menu, I researched the distance names athletes would actually recognize, things like world championship or Olympic-distance conventions, and turned those into a small, named list instead. For Aquabike, for example, that list is: Long distance (140.6 km), Middle distance (70.3 km), Olympic, and Sprint. It's a UX decision about what a user recognizes, not a technical shortcut.

06

Five things worth slowing down for

1

The existing search icon already solved it

The homepage's prominent "Filter & Search" CTA sits centrally in the hero, and the open mega menu visually covers it. Returning users who already relied on that button could lose it entirely. The fix required no new design: the header already had a persistent search icon, top-right, that stays visible and clickable with the menu open. The real work was noticing the risk and confirming the existing pattern already covered it, rather than adding something new to solve a problem that already had an answer.

2

"SHOW ALL" ON EVERY COLUMN

Two separate testing moments converged on the same fix. Stress-testing the Popular Countries column with a long list raised the obvious question: what about a country that isn't in it? Testing the mobile version made it concrete: dead ends. Note on the design-review board: "To not create dead ends, I think we need to add 'Show all…' to all filter categories. I realised this especially when I tested the mobile version." It also came from watching how athletes actually search: most look for a sport or a distance before they think about a country. That's why Distance became the more important column to get right, and why Popular Countries, being more of a secondary path, needed its own "Show all" link the most, since a country missing from that short list had no other way to be found.

3

The ideal fix was too slow to ship, so we shipped the honest fallback

Fully populated columns plus longer translated copy (French routinely runs longer than English) could push the menu wider than its breakpoint. The ideal fix, extending the horizontal-scroll-with-arrows pattern already used for overflowing pills to the whole menu was more complex for engineering to build on the release timeline. Rather than delay, V1 shipped a simpler compromise: drop the Popular Countries column entirely at tight breakpoints, giving the space back to Distance, Month and Popular Events. Not the solution I'd have chosen with unlimited time, but the one that actually shipped on schedule.

4

"RIGHT NOW" WASN'T CUT FOR SCOPE, THE DATA DIDN'T EXIST

The columns are automatically populated, using data the backend already had: which countries had events, which months, which distances existed for each sport. But a 'Right Now' column (New events, Early bird, Registration closing soon) needed something the backend had never tracked before: there was simply no existing way to know 'this event is new' or 'registration closes soon.' That wasn't a decision to cut a lower-priority feature. It was a real gap in what the system could do, and we only found it once we sat down with tech to actually scope the build.

5

A curated distance "span," not a free-form range

This one's covered in full back in Building the system, but it's worth flagging here because it's easy to mistake for a small technical detail. It isn't one: it was a deliberate choice about what a user could quickly recognize and pick from, researched sport by sport, instead of the flexible but overwhelming free-text input the old site offered.

07

MOBILE: A DIFFERENT PROBLEM WITH A DIFFERENT BEHAVIOR

The desktop pattern depends on hover or click to open a flyout, with columns laid out side by side. That doesn't survive a resize down to a phone. The key thing I'd take from this project: mobile needed a genuinely different interaction, not a smaller version of the same component.

What we built instead is a four-level drill-down: tap the hamburger for six sport categories, tap one to reveal its individual sports, tap a sport to reach its filter overview (Distance, Popular Countries, Month, Popular Events beneath), tap a filter to reach its values.

Click to view full size
Mobile prototype, the full drill-down. The hamburger menu and top-level categories, then the per-sport menus for Running through Other, and the filter levels beneath (Distance, Popular Countries, Month) mapped end to end. A hierarchy the user moves forward into, not a shrunk copy of the desktop columns.

The convention for desktop mega menus is to drop down from the top. That doesn't fit a hierarchy you're moving forward into. So each level instead slides in from the right: the same direction, every time, tap after tap. The reference for that motion, again, was IKEA's mobile navigation. The back control follows the same logic: identical position, identical behavior, on every single screen in the drill-down, so a user can always step back predictably no matter how deep they've gone. Small rule, but it's the kind of consistency that decides whether a four-level flow feels smooth or feels lost.

08

What didn't make it

Two ideas got real design work and didn't make v1, for different reasons.

Click to view full size
The "Right Now" column, mid-exploration. Positioned deliberately first, leftmost, the position a user's eye reaches first, following the same convention retail sites use to surface "New" releases.

"Right Now" column

Got as far as a full mockup with icons and copy for New events, Early bird, and Registration closing soon, see the groundwork above. The reasoning for the cut is covered in finding 4: the backend had no concept of "new" or "closing soon" to query. A candidate to revisit if that data ever gets modeled.

Not shipped — genuine backend gap

Commercial / promotional slot

A fifth position at the far right of the desktop menu, inspired by IKEA's own flyout, which uses that spot for a lifestyle image and a "Best sellers!" callout. Our version leaned more commercial: sports-gear placements or event sponsor slots tied to the selected category. A real monetization opportunity riding on space the menu already occupies.

Deliberately deferred — planned for a future release

09

DESIGN REVIEW OF PRODUCTION

Once tech had a working prototype, we ran a structured review pass: priority-labeled sticky notes, each tracked to sign-off with separate Dev and Des checkboxes.

Click to view full size
Design review board. "Switch order of 5k and 10k" (the self-discovered ordering bug from the taxonomy audit) tracked through to a confirmed fix, Dev✓ Des✓; "Selected sport category should stay underlined" signed off by Dev, Des still pending, shown against the built menu it applies to.
  • ✓Selected top-nav category (e.g. "Running") stays underlined while its menu is open, closing the gap flagged earlier as "select state needed"
  • ✓Winter sports sub-nav reordered by actual race volume, not alphabetically
  • ✓Tab selection resets on menu close or category switch, so a stale sub-tab can't persist where it shouldn't
  • ✓Mobile account buttons (Log in / Create account) kept in their existing position: continuity over novelty
  • ✓Drop-shadow removed from the top edge; a plain visual clean-up
10

Tested, not just designed

Every sub-tab across every category was wired into an actual click-through prototype in Figma, not a set of static comps handed over with a hope. That's the difference between a design that looks finished and one that's been proven to actually work as a sequence of real interactions, mobile included.

Click to view full size
Wired prototype. Every sub-menu tab, Triathlon, Duathlon, Swimrun, Aquabike and the rest, connected into one testable flow, used for stakeholder walkthroughs before a line of production code was written.
11

The outcome

The point where I'd say the project actually "nailed it": every top-level category finished to the same standard, with real, category-specific content throughout, not just Multisports, which had carried nearly all the detailed exploration.

Click to view full size
All six categories, one system. Running, Cycling, Multisports, Water sports, Winter sports and Other, each with its own real data: Cycling's distance column in km ranges, Winter sports reordered by race volume.

And then the version that matters most: what's actually live.

Click to view full size
Live on ahotu.com: Running. Distance, Popular Countries, Month and Popular Events, each with its own "Show all." Popular Countries shows real, live counts up to twelve countries (United States 27,820 down to Australia 190). Both "Right Now" column and the promotional slot stayed out of V1.
Click to view full size
The homepage this menu lives on top of. "Discover the world through endurance," with the "Filter & Search" CTA the mega menu had to learn to coexist with, not compete with.
12

What I'd carry forward

A PATTERN DOESN'T SURVIVE A BREAKPOINT BY DEFAULT. The desktop mega menu and the mobile drill-down solve the same problem with genuinely different interactions, treating mobile as "the small version" would have shipped something worse on both ends.

THE BEST FIXES ARE SOMETIMES FINDABLE, NOT INVENTABLE. The single biggest navigation risk in this project, the mega menu hiding the site's main search CTA, was solved by noticing an existing pattern already covered it, not by designing something new.

Rigor shows up as data, not opinion. The 5 km/10 km ordering bug, the Popular Countries edge case for niche sports, the "span" categories: none of these were visible from the interface alone. They came from manually auditing the actual underlying data, sport by sport.

Honesty about trade-offs is part of the deliverable. The Popular Countries breakpoint fallback and the cut "Right Now" column weren't failures to hide: they're evidence of decisions made deliberately, against a real deadline, with the reasoning intact.