Practice — Information Architecture and Navigation (9 questions)

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.

1. What specifically will go wrong with the current flat structure as the catalog triples, and what's the mechanism (name it)?
2. Propose a restructured hierarchy. How many levels deep, and roughly how many items per level — justify the numbers, don't just assert them.
3. What research method would you run before committing to your proposed structure, and what would a bad result from it look like?
4. What's the risk of going too deep instead, and how would you know you'd overcorrected?

A mobile app's IA has seven validated top-level sections, and the team is deciding whether a persistent bottom tab bar can hold all of them.

Per this subject's stated deciding factor for tab bars, what's the practical ceiling on top-level items?

A team runs a tree test on a proposed category structure, asking 20 participants where they'd look to cancel a subscription.

What's the key metric this method is built to produce?

A team is redesigning a settings page and doesn't yet know whether their current category structure matches how users actually think about the content.

Which card-sorting approach fits, and when should it run?

A team chunks a broad, 40-item flat menu into labeled top-level groups to reduce the Hick's Law cost of scanning it.

Per this subject's practical guidance, roughly how many top-level items should a well-chunked menu land on?