BOTHER
Improving Product Discovery to Increase Order Value
Role
Lead Product Designer
When
2023 (Q1 )
Focus Areas
Match Rate · Discoverability
Platform
Web · App
Results
Conversion increase 3x
Match rate increased from 29% to 37%
Context
User education to earn user action.
Grocery delivery startup, Bother, was a service that offered to deliver non-perishable, household essentials (but not fresh produce) to alleviate you of your 'boring' shopping… so you can focus on the fun groceries.
"We Bother, so that you don't have to", the motto promised.
However, despite our large product range across many categories, this new and unique value proposition made it hard for new users to understand exactly what we offered.
Adding to this, we had a minimum spend of £40 to place an order, so it was tremendously important that new users understood our range and could easily navigate cross-category as they explored what else we had to offer.
The thinking, then, was that to unlock greater average order values, and thus better overall conversion, we'd need to design a better solution to achieve two product goals:
Expose the full range to new customers
Make it easier to find what you want
To achieve this, I led a product design initiative addressing these across both web and native apps (iOS and Android), working alongside a product manager, two full-stack engineers, and the commercial team.
Problem
The current design limited users' ability to understand and navigate the catalogue That Goes Onto Two Lines
A quick survey with 25 customers and a design audit I ran surfaced the same issues, all of which got in the way of product discovery.
1 · Homepage grid dropped customers into top-level PLPs
No way to drill down, and no exposure to the more specific categories underneath.
2 · Desktop sidebar reordered itself dynamically as you switched PLPs
Customers couldn't build a reliable mental model of where things lived.
3 · Sub-category nav on mobile relied on horizontal scrolling
It saw minimal interaction and hid most of the category tree from view.
Together, these meant customers often only ever saw the category they arrived for, capping basket size, and leaving first-time baskets abandoned short of the £40 minimum required to checkout.
Process
The new menu had to show more, without feeling like more.
I presented these current limitations, as well as what we were trying to achieve, to team members in engineering, product, and commercial and ran a solution session, which generated 30+ ideas.
We then grouped them into 3 strong directions, where I also noted the possible risks each of them exposed us to, and the assumptions each of them had to prove out in tests (e.g. Does it feel familiar? Is it overwhelming?)
Those three directions were:
1 · Horiztonal mega-menu
A common pattern in e-commerce that shows the whole range at once.
2 · Sub-category carousels
Replaces top-level categories on homepage carousels a level down.
3 · Prominent search + categories
Guiding customers to search with new entry point (search converted well).
I took these 3 directions and turned them into prototypes that I could have people interact with in a usability test.
This involved 25 testers completing a specific navigation task, after which I also asked testers to name everything they thought Bother sold. This way we could measure whether the navigation was doing a good job of educating people about the range, as well as just helping them navigate it.
The result? The horizontal mega-menu won.
But the test surfaced a new problem.
The mega-menu won across every metric (including time to complete the task and number of wrong turns) but it exposed so many categories at once that it risked both overwhelming people and creating a menu too tall to hover away from on smaller desktop screens.
So I ran a session with commercial to show them the problem, then asked them to restructure the category tree in order to reduce the number of total categories.
I provided constraints of working within a three-level depth limit and a cap on sub-categories per top-level category.
As that was being worked on, I explored 4 executions of the overarching 'mega-menu' pattern:
A: L1s in a side panel off three featured top-level items
B: L1s as tabs in a floating panel, L2s on hover
C: L1s in a persistent second bar, L2s on hover
D: Same second bar, but click-to-reveal L2s and L3s
These were then turned into prototypes and taken through one last round of usability testing which revealed (D) was the strongest and most commonly recognised design.
On mobile, I took a deliberately different approach.
The core problem there was access rather than structure, since the menu that was buried behind the burger menu icon already had a great interaction for navigating cross categories.
However, we doing little to re-surface this menu for users once they were within a PLP already.
So rather than test competing directions, I simply added a new in-page entry point to the pre-existing full category nav instead of leaving it buried in the top bar.
Existing mobile menu
Easy to navigate menu hidden behind unlabelled burger icon menu, which got little interaction 8% tap-through.
New menu entry point
Added an explicitly labelled 'Browse Aisles' button in-page on every PLP to facilitate category discovery.
It was a low-risk change, so we chose speed: opting to build and validated it with an A/B test rather than usability testing first.
Lastly ran an updated desktop prototype, now populated with the new category architecture, through customer interviews (as part of the weekly interviews product manager, Lorin Minxhozi, and I were running) to ask people to navigate it and complete a specific shop so we could watch behaviour and ask questions in real-time.
Ultimately, I mapped the use cases in Figma, documented the decisions, built the navigation as reusable components in the design system, and presented the finalised work to company stakeholders in an All-Hands demo.
Solution
Everything on offer, always one step away.
Ultimately for desktop we built an intuitive, and familiar mega-menu pattern.
This allowed:
The commercial, marketing, and product teams to feature each of their own high-level menu items
Main L1 categories to be revealed using a hover interaction on 'Browse Aisles'
Sub-categories (L2s & L3s) to appear when an L1 was clicked.
Distinguishing 'click' from 'hover' was crucial: customers could scan the L1 categories without being overwhelmed by the L2s and L3s beneath them. Them followed the principle of progressive disclosure, so that sub-categories were revealed only when a customer intentionally chose to explore further.
With navigation now owned by the mega-menu, we removed the self-reordering sidebar that had undermined customers' mental model, freeing up real space for product cards to breathe on the PLP.
For mobile web and native apps (iOS and Android), the existing menu got some UX improvements:
An improved side-nav with new icons against the L1 categories
Clearer labelling on the back arrow so that people always knew where 'back' led.
I also made the mobile nav more easily discoverable throughout the whole customer journey, with a new homepage entry point plus a persistent category button across all category pages.
The menu was also built to always be context-aware: meaning that opening the menu would no longer reset each time and take users to the top level, but would rather open to the position that you actually sat in the category tree at that point in time.
The Impact
User education earned user action.
During the usability testing stage: the new navigation designs produced positive signs:
Customers who strongly agreed they could find what they needed rose from 29% to 37%.
When asked to name what Bother sold, customers on the new design listed 15% more of the range.
And once launched to 20% of users behind a feature-flag, that understanding showed up in customer behaviour:
'Browse Aisles' button triggered:
2x nav opens
From within a listing page, rising from 8.1% to 16.3%
Order conversion had:
~3x uplift
As new basket value went >£40 went from 0.86% to 2.4%
Learnings
What I'd do differently now in 2026
I'd test less, and trust the pattern more · As David Epstein notes in his book on constraints, we tend to spend more time agonising over the details that matter less, since the options they present usually look most similar. I think whilst there were risks, perhaps my newness in the company, and thus desire to display confidence had me entertaining more tests then were perhaps needed for a design pattern like this.
I'd build the prototypes in Claude Code · Obviously a luxury I didn't have back in 2023, but this is now where much of the time is saved in my process… but more importantly, what facilitates more insights. Product designers design software people can use, not flat, un-interactable, mockups you look at for ages and critique. Faster execution of prototypes, means more of the feedback is tied to what actually matters - how people use what you're designing.
I'd recognise sooner that the architecture was the design, not the UI · I'm far better now at recognising that my job is really about looking first for the highest-leverage decisions; and here it lived first getting commercial to restructure the category tree within a strict depth-and-breadth constraint. The menu only worked once the architecture underneath it did, so why not unlock this first to garner a quick win for the business that would only do more to prove the impact of improving category navigation.