Rebuilding eazle's mobile navigation

A reordering journey with too many taps

On a B2B platform built for bar owners, restaurant managers, and shop owners placing recurring orders, every extra tap is friction. These are people ordering between shifts, often on mobile, with limited time and a clear goal: get in, reorder, get out. The faster they can move between the product catalogue, their order history, and their loyalty points, the better the experience. And for a long time, that journey was more cumbersome than it needed to be.

Why were users always opening the hamburger menu?

The signal came from the data, specifically from a User Behavior Watchparty session where the team was observing real user behaviour together. Heatmaps from our users in Myanmar consistently showed the hamburger menu as one of the most interacted-with elements across the PLP, Club page, and Order confirmation page. Meanwhile, our Q3 UX insights report showed that Orders and Club were among the most visited pages, with Order History ranking particularly high in South Asia and Singapore.

The pattern was clear: users were repeatedly navigating back and forth between the product list and their order history to cross-reference previous orders while building a new one. The only route available was through the hamburger menu, every single time. For a reordering journey built on speed and familiarity, that was a meaningful obstacle.

The A/B test

What if the key sections were one tap away?

If key sections were made more visible and directly accessible in the mobile navigation, users would move between the platform's core areas more efficiently. We expected to see an increase in visits to Orders and Club, and a reduction in the friction caused by repeatedly opening and closing the hamburger menu.

A navigation bar, tested for six weeks in Myanmar

I designed a bottom navigation bar for mobile, giving direct access to Products, Orders, eazleClub, Account, and Cart. To run a clean test, we also removed the Cart icon from the header bar and kept the hamburger menu visible, specifically to see whether users would gravitate toward the more obvious navigation option even when the familiar one was still there. The A/B test ran for six weeks across all mobile sessions in Myanmar, with a 50/50 traffic split.

Users preferred the bar, but missed their Cart

The primary goal was achieved. Visits to the Orders page increased by 27.9% and Club visits grew by 3.4%. The bottom bar was used in 64.3% of all sessions, and hamburger menu usage dropped by 22.1%, which told us users preferred the more accessible navigation when it was available.

But the test also introduced friction we hadn't fully anticipated. Users expected the Cart icon to stay in the header bar, where they'd always found it. Moving it to the bottom bar led to a spike in Account page visits driven largely by mis-clicks from users aiming for the Cart. The reduced viewport also made product browsing slightly harder.

The Cart went back where users expected it

The recommendation from the test was clear: don't implement as tested, iterate first. The bottom bar needed to be purely a navigation surface, not a home for transactional actions like the Cart. So the Cart went back to the header, and the bar now hides on scroll to give the product list its space back: top bar for session-critical tasks, bottom bar for moving between sections.

The navigation we shipped

As we iterated on the variant, it became clear that the navigation bar was changing more than how our users moved between sections. Since Products, Orders and eazleClub were now one tap away, we no longer needed the hamburger menu, so we replaced it with a More section that hosts Account settings and other low-engagement actions. It also gave us the space to introduce our first iteration of a Home screen and learn from our users' perception of it. What we ended up with was a bottom bar to navigate between sections, a More section for everything else, and the Cart back in the header.

What I took from it

We didn't implement a popular UI pattern because it felt right: we traced a real behavior in the data, tested it, and read the results honestly, including the parts that didn't go our way. We shipped the navigation bar because six weeks of data proved it was the right solution, not because it looked good in a mockup. Familiar patterns set expectations, and moving the Cart showed us the cost of disrupting too much too soon. Testing it is what let us find that out, and fix it before we shipped.