Max Retail · B2B SaaS · Wholesale marketplace · 2025
Lifting marketplace conversion 7%
By rebuilding search around the inventory we actually had — not the one the filters assumed.
Background
I owned the information architecture, not a reskin
Max Retail is a wholesale marketplace where boutiques buy surplus inventory from other retailers. I joined as the only designer, working across three product teams.
This wasn't a tidy-up of the existing search. The back end behind it was being rebuilt from scratch, and I owned the whole structure and flow on top of it — how buyers browse, filter and move through the marketplace.
Problem
Five hundred items listed, three in the results
Click a category showing 500 items and get three. Filter, find something, hit back — your filters are gone. Add something to your cart and you're returned to the marketplace homepage to start over.
The filters were also the wrong filters. The same set appeared on every category: heel height on activewear, age group on dresses, shoe width on bags. One set of filters applied to inventory that was nothing like uniform.
"The search back end had accumulated so much technical debt that meaningful change to the experience wasn't practical on top of it. The team's word for it was spaghetti."
Why it was a rebuild, not a fix
Discovery
I kept finding data problems dressed as design problems
The phantom filter counts weren't a UX bug. Neither were the wrong-category attributes. Both were dirty data surfacing through a filter system that didn't know what category it was in.
The clearest one I found while testing the build before release. Has size run — a filter meant to surface items stocked in three or more sizes — was passing items that had Medium and medium. The same size, spelled two ways, counted twice.
Boutique buyers use that filter specifically to buy a full size run to resell. Returning junk would have cost us the exact buyer it was built for. I flagged it, documented it, and pushed for the fix before launch.
Decision
I chose the filter system that was harder to build
There was an easier path, and it was genuinely available: keep the single filter set the old search used and ship weeks sooner. The alternative meant rebuilding the whole filter structure and deciding, category by category, which attributes belong to what.
One filter set for everything
Keep the one-size-fits-all set the old search used. Faster to build, nothing new to map.
Trade-off: a heel-height filter on activewear isn't a neutral cost. It's noise the buyer reads past on every single search, and it was already the loudest complaint about the old experience.
Category-specific dynamic filters
Filters change with the category being browsed. Dresses get sleeve length, neckline, pattern. Shoes get heel height, toe shape, width. Bags never show heel height at all.
Trade-off: rebuilding the filter structure from nothing, mapping attributes to every category, and a long tail of edge cases — items filed in the wrong place, categories with barely any stock, attributes that only make sense once a category is broad enough.
I took the harder one. Generic filters ship faster and help less — they assume uniform inventory, and ours was the opposite of uniform.
The edge cases were calls made in testing rather than in spec. Has pockets became a boolean toggle rather than a filter option. Has size run was switched off for Bath & Body, where sizes don't apply.
Three other changes shipped with it: normalised colour, so a seller's "dusty rose", "blush" and "baby pink" all collapse into one option a buyer can actually filter on; a discounted-items filter; and filter state that survives navigation, with a cart that no longer ejects you back to the homepage.
Launch
Deciding what counts as a blocker is design work
Testing surfaced three issues in the week before release. Breadcrumb text set at 10px and a bug when switching between filter variants were blockers — both were fixed before launch.
Adding multiple sizes of the same item to the cart was not. In the launch decision meeting we named the risk, shipped, and fixed it in the following release. Holding a rebuilt search experience for it would have cost more than the bug did.
Shipped to production on 17 March 2025.
Impact
Buyers could finally see what was in the marketplace
The filters now reflect real inventory, state survives navigation, and the path from search to cart and back holds together.
Conversion rose 7% after launch
Measured in our product analytics after launch, against the baseline before the rebuild.
Filters became category-aware
Each category got its own set of filters, so what a buyer can narrow by now matches what they're actually looking at.
Three data defects caught before buyers saw them
Duplicate-size counting, attributes on the wrong categories, and filter counts that didn't match the results — all found in testing rather than by buyers.
Data quality became a design concern
Raising these in testing rather than after release changed what the team treated as a design problem rather than only an engineering one.