Choosing Depth vs. Breadth for a Growing Product Catalog
A retailer's app currently has a flat product hierarchy: one "Products" screen lists all 40 categories (Shoes, Shirts, Jackets, Belts, Hats, Socks, ...) in a single scrollable list, one tap from home. The catalog is about to triple in size as the retailer adds home goods, electronics, and groceries.
- What specifically will go wrong with the current flat structure as the catalog triples, and what's the mechanism (name it)?
- Propose a restructured hierarchy. How many levels deep, and roughly how many items per level — justify the numbers, don't just assert them.
- What research method would you run before committing to your proposed structure, and what would a bad result from it look like?
- What's the risk of going too deep instead, and how would you know you'd overcorrected?
1. What breaks, and the mechanism
A flat list of ~120 categories one tap from home is a maximally broad, minimally deep hierarchy — every category is a sibling of every other, with no grouping. The mechanism is Hick's Law: decision time increases with the number of choices presented at once, and scrolling past 120 undifferentiated options to find "Electronics" or "Groceries" measurably slows down and frustrates the very task the screen exists to support. The current 40-item version is already pushing this; tripling it makes the homepage screen actively hostile to browsing users who don't already know the exact category name they want.
2. Proposed restructuring
Introduce one intermediate level: a small set of top-level departments (Clothing, Home Goods, Electronics, Groceries — 4-6 items, well within the range where Hick's Law cost is low and scanning is fast), each expanding to its existing sub-categories (Shoes, Shirts, Jackets... under Clothing). This keeps the original 40 categories exactly as they were — nothing about them changes — it just adds one chunking level above them so no single screen shows more than roughly 6-15 items. Two levels total (Department → Category) is enough; a third level isn't justified unless a specific department's category count is itself large enough to repeat the same problem (Electronics alone growing to 30 sub-categories, for instance).
3. Research before committing
Run an open card sort with the full set of ~120 categories (existing plus new) and no predefined departments, to see how real users naturally group them — the department names and boundaries should come from that data, not from how the retailer's internal merchandising teams already think about the business. A bad result would be low agreement: if participants scatter categories across many idiosyncratic groupings with little overlap, it signals the domain doesn't cleanly chunk into a small number of departments the way assumed, and a different scheme (maybe a matrix of category × use-case facets) might fit better than a strict hierarchy.
4. Risk of overcorrecting toward depth
Going too deep — say, Department → Category → Sub-category → Sub-sub-category before reaching an actual product type — trades the Hick's Law cost for a click-cost: users now have to make 3-4 sequential decisions, each one a chance to guess the wrong branch and have to backtrack, before seeing any real content. The tell that you've overcorrected is if a tree test on the proposed structure shows a low first-click success rate specifically because users hesitate or backtrack at an intermediate level that doesn't map to any category distinction they actually care about — that's a sign a level was added for organizational tidiness, not because it reflects a real grouping.
Share this question