Why PatternMode

PatternMode started as a personal collection of UI patterns I kept referencing across projects. Dropdown menus with specific animation curves, card layouts with particular hover states, navigation patterns that solved mobile and desktop differently. I had screenshots scattered across Figma, bookmarks, and a markdown file that was getting unwieldy. The project was supposed to be simple: organise these patterns into a browsable library. The interesting problem turned out to be classification.

The taxonomy problem with design patterns is that categories overlap constantly. A card component is also a layout pattern. A navigation dropdown is an interaction pattern and a disclosure pattern and sometimes an accessibility pattern. Strict hierarchical categorisation -- the kind where each pattern lives in exactly one category -- forces decisions that feel arbitrary. Is a search-as-you-type input a "search pattern" or a "form pattern" or a "filtering pattern"? The answer depends on context, which means a single hierarchy will always feel wrong to someone looking for it from a different angle.

I tried three classification approaches before landing on one that worked. First, a strict hierarchy (navigation > dropdowns > mega-menu). Too rigid -- patterns that bridged categories had to live in one place arbitrarily. Second, a flat tag system with no hierarchy. Too loose -- 200 patterns with 15 tags each produced results that were technically correct but not useful for browsing. The third approach combined tags with weighted relevance: each pattern has multiple tags, but each tag carries a weight indicating how central that classification is. A mega-menu might be tagged "navigation" at weight 1.0, "disclosure" at 0.7, and "layout" at 0.4. Browsing by "navigation" surfaces it prominently. Browsing by "layout" still includes it, but further down.

The weighted tag system solved the browsing problem but created a curation problem: who decides the weights? I spent a weekend manually weighting 150 patterns before accepting that the weights were subjective and that was fine. The value isn't in perfectly objective classification -- it's in having a classification at all that reflects how I actually think about these patterns. When I'm looking for navigation solutions, I want navigation-primary patterns first. The weights encode editorial judgment, not taxonomy. That distinction turned out to be the whole insight: a pattern library is an editorial product, not an information architecture exercise.