Design Pattern

A design pattern is a reusable answer to a problem that has already been solved, not once but dozens of times across the industry, documented and distilled into a recommendation you can apply without starting from scratch. The concept migrated into software from architecture, specifically Christopher Alexander's 1977 book "A Pattern Language," which cataloged 253 recurring solutions to building and urban design problems. Software designers borrowed the framework in the 1990s; UI and UX practitioners narrowed it to the decisions that actually haunt design reviews: dropdown versus radio group, modal versus new page, empty state versus placeholder content.

A design pattern is not a component, and this conflation is the most common mistake. A button is a component; primary action hierarchy is a pattern. A dropdown is a component; progressive disclosure is a pattern. A design system gives you the Lego: patterns tell you when to build a castle and when to build a car.

Patterns are also not rules. A rule says never use more than seven items in a navigation menu. A pattern says when users need to navigate between five or more distinct top-level areas, horizontal navigation outperforms a sidebar below 1280px, but at mobile breakpoints the sidebar wins. Rules are brittle because they carry no reasoning; patterns carry the tradeoff, which is what lets you adapt when your situation doesn't quite fit the standard case.

Material Design, which Google first released publicly in 2014, is the most-cited living pattern library at scale. It documented patterns like bottom navigation for mobile apps with three to five destinations, FABs for the single most common action on a screen, and cards for heterogeneous content of unpredictable density. None were aesthetic recommendations. Each came with explicit reasoning, edge cases, and counterexamples showing exactly where the pattern breaks.

Apple's Human Interface Guidelines have been doing the same work since 1987, when the first Mac HIG established that menus belong at the top of the screen, not floating over the canvas. The pattern persisted for almost 40 years not because Apple said so but because the reasoning held: a consistent menu location lets users build muscle memory without looking, which matters when the same user opens hundreds of different applications on the same machine. Nielsen Norman Group has been cataloging web UI patterns since the late 1990s, and their research on things like "infinite scroll works for passive content consumption but destroys productivity tools where users need to remember where they were" is exactly what separates a documented pattern from a designer's gut feeling.

The Figma community has also surfaced what a bad pattern library looks like. Thousands of UI kit files get marketed as pattern libraries but contain only components: buttons, inputs, cards, no decision criteria, no edge cases, no reasoning. Hand that to a new designer and they have raw materials with no blueprint. The gap between those two things is the gap between a component kit and a pattern library.

Use patterns when your team keeps having the same design debate. If a settings screen's navigation structure comes up in four consecutive design reviews, that debate belongs in a documented pattern, not a Figma comment thread. Patterns earn their keep in products with multiple designers, long timelines, or regular onboarding. The cost of writing them down pays for itself the first time a new designer doesn't have to reinvent the wrong wheel.

Where patterns lose value is in genuinely novel interaction spaces. Forcing a new problem into an existing pattern because the pattern exists produces mediocre work. The pattern for real-time collaborative document editing didn't exist in 2000; some team at Writely, later acquired by Google to become Google Docs, figured it out from scratch. Solve the problem first, then document what you learned so the next team doesn't start from zero.

The pattern for disclosure of complex financial data in a mobile context is still being written. Robinhood got widely criticized in 2020 for borrowing UI patterns from simple stock trading to display options positions, patterns that weren't designed for instruments where the displayed gain metric actively misleads retail investors. Some team will crack it, document it, and everyone else will copy it. That's how patterns get made.

A pattern is someone else's hard-won scar tissue, written down so you don't have to earn the same scar.