Browse by category

Problem Context

• The collection contains enough destinations that a flat list, global navigation, or single search box would force users to guess terms or scan too much.
• Users can recognize meaningful topic areas, service areas, resource types, or product families if the taxonomy uses their language.
• The category structure needs ongoing content tagging and review because categories can drift, overlap, empty out, or reflect internal ownership rather than user mental models.

Selection Rules

• Choose browse by category when the primary task is exploratory recognition: users know the area but not the exact item name or query.
• Use a category landing page when categories lead to multiple destinations, subcategories, or task pages that need explanation before selection.
• Limit each visible category level enough for scanning; when there are too many children, split, group, prioritize, or add within-category search.
• Name categories by what the content is about, not by the department, owner, content format, or backend index that produced it.
• Add short descriptions or examples when category names could overlap or when users need help predicting the contents.
• Show item counts, most viewed tasks, recently updated content, or representative examples only when they help users choose and stay current.
• Provide a clear parent path, sibling categories, and back route so users can recover from the wrong category.
• Omit or explain empty categories; do not present an empty child page as a valid browse destination.
• Use basic search when users know words or identifiers; use filter panel after users already have a result set; use tabs only for sibling panels in one page context.
• Review tagging accuracy by spot-checking category contents and correcting misplaced items.

Required States

• Top-level category state with clear names, descriptions, and enough examples or counts to choose.
• Category selected state showing parent, current category, children, and relevant destinations.
• Subcategory state with a clear route back to parent and siblings.
• Empty or merged category state with explanation and recovery to parent, search, or replacement category.
• Popular or most-viewed destination state that remains visibly secondary to the taxonomy.
• Long category list state with grouping, prioritization, or search-within-category.
• Mobile compact state where hierarchy and descriptions remain scannable.
• Mis-tagged or stale category review state for editors or maintainers.
• Deep-linked category state that restores location and content.

Interaction Contract

• Activating a category navigates to a category view or expands a category hierarchy, not a filter chip on an unrelated result set.
• The selected category, parent path, and available children update together so users know where they are in the taxonomy.
• Category descriptions accurately summarize the content behind the category and are updated when the contents change.
• Most-viewed or popular links do not replace the full category path unless the page explicitly says they are shortcuts.
• Search fallback preserves the selected category only when it genuinely searches within that category and labels that scope.
• Empty categories explain whether content moved, no content exists, or the user lacks permission, and provide a next route.
• Changing category clears stale item selections, counts, and previews that belonged to the previous category.

Implementation Checklist

• Define the category taxonomy, parent-child relationships, category labels, descriptions, item ownership, and tagging rules before building the UI.
• Use analytics, search logs, support queries, card sorting, tree testing, and content audits to validate category names and hierarchy.
• Show category descriptions, example items, counts, or popular links where labels need disambiguation.
• Render category links with normal navigation semantics and preserve the hierarchy in URL, breadcrumb, or page heading.
• Keep categories mutually exclusive enough for discovery, and add cross-links only where users reasonably expect content in more than one place.
• Spot-check category contents after imports, migrations, or automated tagging.
• Design empty, merged, permission-limited, and stale category states before launch.
• Test keyboard navigation, screen reader link lists, mobile wrapping, long labels, and categories with few or many children.

Common Generated-UI Mistakes

• Using the organization chart as the category taxonomy.
• Showing category cards without descriptions when labels overlap.
• Treating categories as filters while navigating away and losing result context.
• Leaving empty categories visible because the schema still has a category record.
• Adding popular links without preserving the complete category path.
• Putting the same content into many parent categories to avoid making taxonomy decisions.
• Using icons or colors as the only way to distinguish category meaning.

Critique Questions

• Can users predict what they will find inside each category without opening it?
• Are category labels based on user language and content meaning rather than team ownership?
• How many choices appear at each level, and does that exceed what users can scan?
• What happens when a category has no content, stale content, or content users cannot access?
• Do category pages show the parent path, sibling choices, and a route back to search?
• How are tagging errors found and corrected after launch?