A mockup built from the design screens of the new tree, which shipped in the app in 2024.
In 30 seconds
- The app's category tree had grown to mirror Bemol's buying teams. The most used paths sat as deep as the ones almost nobody opened, and the labels didn't say what was inside.
- I redesigned the information architecture from a benchmark, a CSD matrix, UX Cam data and cross-department critique, and ran the usability test inside the store with five staff and eight customers.
- Shipped in 2024, with qualitative evidence gathered in the store. The usage numbers stayed with the product team.
- Bemol Digital
- Senior Product Designer
- Product Design · Research
- Bemol App
- Launched · 2024
The premise
A customer walking the aisles of a physical store finds things they weren't looking for. The app had no equivalent: the category tree had grown by accretion, mirroring internal org structure rather than how anyone shops.
A prettier menu would have missed the point. The goal was to make browsing feel like walking, where discovery happens on the way to something else.
Three problems in the same tree
The tree mirrored the company, not the customer
Departments were organised the way Bemol's buying teams are organised. A customer looking for a fan had to know whether it counted as appliances or home comfort, a distinction that only exists internally.
Depth punished the most common paths
The categories people used most sat as deep as the ones almost nobody opened. Frequency of use had never been an input to the structure.
No signal of what was inside
Entries were text-only labels. Nothing indicated scale, price range, or what a section actually contained, so choosing between two plausible paths was a guess.
Where the structure came from
Four sources, deliberately different in kind: one on the market, one on alignment, one on behaviour, one on language.
None of them decided the tree on its own. Each one ruled out a kind of mistake the others let through.
Showed the conventions customers already carry from other apps. Breaking them only pays off with a strong reason.
Separated what we knew from what we were assuming, and surfaced technical constraints before they became rework.
Told us which categories were actually opened, at what depth, and where people abandoned. That's the input that reordered the tree.
Caught the internal-jargon labels that people inside the company read as obvious and nobody else does.
We tested inside a physical store, with customers and staff. The people who answer 'where do I find this?' all day were the sharpest critics of the structure.
Five staff and eight customers
Staff are in the sample for a practical reason: in a physical store, they are who the customer turns to first, and in plenty of cases they are the ones teaching the app. If the structure doesn't hold up for the person in the aisle, it won't reach the people they serve intact.
A session run inside the store.
They also give more than the script asks for. They spend the day with the customer in front of them, so halfway through a task they start telling you what they have already watched go wrong. That is the kind of thing you cannot learn from home or from an office, without the direct contact.
What we know, and what we don't
The evidence here is qualitative, and it came from the shop floor. The behavioural numbers stayed with the product team.
- —
- Reduction in tap depth to category
- —
- Change in category entry rate
What didn't ship
Category imagery for every entry
Producing and maintaining art for hundreds of categories had no owner after launch. Shipping it half-populated would have looked broken, so it stayed out.
Personalised ordering by purchase history
The recommendation service couldn't be called at that point in the flow without a latency cost we weren't willing to pay on the entry screen.
Merging two overlapping departments
The structure argued for it, but the split maps to how buying teams are organised internally. That's the organisation's call rather than a design one, so I flagged it and left it as it was.
Who did what
- Information architecture of the new category tree
- Benchmark and CSD matrix, facilitated with stakeholders
- UX Cam analysis and the reordering it drove
- Usability test script and in-store facilitation
- Rounds of design critique with designers from other departments
- Front-end implementation, with the app team
- Category taxonomy review, with the buying teams
Reflections
The source I hadn't planned for, and the mistake I repeated.
The sharpest feedback came from store employees. They answer 'where do I find this?' dozens of times a day and had a working mental model of customer language that no benchmark would have produced.
If I ran this again, I'd fix the measurement before the redesign. The qualitative case is solid and the number was left for later, which is exactly the mistake the Fulfillment project was designed to avoid.