Design hierarchy levels by what question each answers…
Before creating or reorganizing any hierarchical structure, ask what question each level answers—top level for domain identification, leaf level for specific item selection, and intermediate levels for navigation steps between.
When This Fires
- Creating a new folder structure, taxonomy, or hierarchical navigation
- Reorganizing an existing hierarchy that's hard to navigate
- When users can't find items in a hierarchy despite "logical" organization
- During any information architecture design for a knowledge system
Common Failure Mode
Creating intermediate levels based on how you created the content, not how you'll retrieve it. "2024/Q1/Week-3/" makes perfect chronological sense but is useless when you're looking for "the security audit results" — you'd have to know when you did the audit to navigate the hierarchy. Topic-based intermediate levels ("Security/Audits/") serve retrieval; time-based ones often don't.
The Protocol
Before designing any hierarchy: (1) For the top level, ask: "What broad domain identification question does this answer?" (2) For the leaf level, ask: "What specific selection does the user need to make at this point?" (3) For each intermediate level, ask: "What question does a searcher ask at this point during retrieval?" (4) If an intermediate level doesn't answer a clear retrieval question → it's a navigation dead-end. Remove it or redesign it to answer a question searchers actually ask.