Structural patterns are the solutions information architects use to define a coherent, navigable structure for a digital information space's pages. The hierarchy, or taxonomy, is the most common structural pattern: a top-down structure with the home page at the top, comprising content organized into categories that have parent-child relationships, progressing from general to specific.
A strict hierarchy keeps categories mutually exclusive, with each page belonging to just one category. A polyhierarchy allows a page to belong to more than one category, which is often necessary for large spaces but should be used sparingly to avoid confusing users' mental model of the structure. Designing a hierarchy means balancing its breadth, the number of items at each level, against its depth, the number of levels overall. As a general guideline, keep the number of categories at any one level below fifty; if a category has too many items, divide it, and if there are too many categories, combine similar ones.
A hierarchy that's too broad overwhelms with choices; one that's too deep buries content beneath too many clicks. Neither failure looks the same, but both send users away empty-handed.
1: Too broad. 68 subcategories at a single level far exceeds the guideline of keeping categories under fifty per level. A flat alphabetical list of that size gives users no meaningful way to narrow down before scanning nearly seventy options, which lines up with the high bounce rate on that landing page.
2: Too narrow and shallow. Only 2 categories, each holding more than 40 articles with no further breakdown, is the opposite failure, the guidance to divide an oversized category into subcategories was never applied here. Users end up wading through undifferentiated lists, which matches the long sessions and repeated back-clicks as they hunt through each bucket.
These two sections fail in opposite directions but for the same underlying reason: nobody applied the breadth-and-depth balancing guidance. Reference needs to be divided, for instance, grouping the 68 endpoints by product area or resource type before listing individual endpoints, so no single level presents more than a manageable number of choices. Troubleshooting needs the reverse: its 2 oversized categories should be split into meaningful subcategories, perhaps by symptom or feature area, so users aren't scanning 40-plus undifferentiated articles to find the one that matches their problem.Neither section needs more levels for their own sake, the goal is balance, not depth. Adding one well-chosen intermediate grouping level to each section would likely resolve both problems without making the hierarchy needlessly deep.