What UI design patterns are and why they matter
A UI design pattern is a reusable solution to a commonly occurring interface problem. It's not a component library or a UI kit — it's a design decision that has been validated across countless products and users. When you use a hamburger menu on mobile, a search-as-you-type dropdown, or a card layout for browsable content, you're applying a pattern.
Patterns matter because users carry expectations from every product they've ever used. When your checkout flow behaves like every other checkout flow, users don't have to learn anything — they transfer existing knowledge. When you invent something novel where a pattern would do, you're asking users to learn your custom approach instead of recognizing a familiar one. Sometimes that's justified (your problem is genuinely new). Usually it's not.
The relationship between patterns and principles: usability principles (Nielsen's heuristics, Shneiderman's rules) tell you why something works. Patterns tell you what to build. "Recognition rather than recall" (principle) leads to "show recently viewed items on the homepage" (pattern). Principles are abstract and universal; patterns are concrete and contextual.
When to break a pattern
Patterns are defaults, not mandates. Break a pattern when your user research reveals that the standard approach fails for your specific users, when the problem genuinely hasn't been solved before, or when a novel approach is demonstrably better (test it). Never break a pattern for novelty's sake — "we wanted to be different" is not a design rationale.
Anatomy of a good pattern
Every pattern in this topic follows the same structure to make them useful during actual design work:
Problem: The specific interface challenge this pattern solves. Framed from the user's perspective.
Solution: The interaction model, layout, or component structure that addresses the problem.
When to use: The conditions under which this pattern is the right choice.
When not to use: Situations where this pattern breaks down or a different one is better.
Variants: Common modifications for different contexts (mobile, data-heavy, content-light).
Navigation patterns
Top Navigation Bar Core Pattern
Problem: Users need persistent access to the main sections of a product.
Solution: A horizontal bar at the top of every page with 5–9 primary links, a logo (linked to home), and utility items (account, search, notifications) at the right end. Highlights the current section.
When to use: Products with a clear, stable top-level structure. Websites, SaaS dashboards, admin panels. Works best when the primary sections are roughly equal in importance.
When not to use: When you have more than 9 top-level sections (restructure your IA instead). On mobile where horizontal space is scarce (switch to bottom nav or hamburger).
Variants: Sticky nav (stays visible on scroll — use for long pages), transparent nav (overlays hero images — use sparingly, ensure contrast), mega menu (expands to reveal sub-categories — use for large catalogs like e-commerce).
Bottom Navigation (Mobile) Core Pattern
Problem: On mobile, top navigation is hard to reach with one hand and competes with content.
Solution: A fixed bar at the bottom of the screen with 3–5 icon+label tabs. The active tab is visually highlighted. Each tab leads to a top-level section of the app.
When to use: Mobile apps with 3–5 primary destinations that users switch between frequently. Instagram, Spotify, and Airbnb all use this pattern.
When not to use: When you have more than 5 tabs (use a "More" tab or reconsider your IA). When the product is single-task focused (a calculator, a camera — no tabs needed). On desktop (wastes valuable space).
Key decision: Icons alone vs. icons+labels. Research consistently shows that labels improve discoverability — icons are ambiguous even when you think they're obvious. Always use labels unless space is absolutely critical.
Sidebar Navigation Core Pattern
Problem: Products with deep hierarchies (many sections with sub-sections) need navigation that shows structure without overwhelming.
Solution: A vertical panel on the left side with expandable/collapsible sections. Top-level items are always visible; sub-items reveal on click or hover. Can be collapsed to icons-only to save space.
When to use: Complex tools, admin panels, documentation sites, settings pages. Products where users need to navigate deep hierarchies. Gmail, Slack, VS Code, and most enterprise software use this pattern.
When not to use: Simple products with flat navigation. Mobile (use bottom nav or hamburger instead). Content-first sites where the sidebar competes with reading.
Variants: Collapsible (shrinks to icon rail), persistent (always expanded), contextual (changes based on current section), multi-level (supports nested hierarchies — use sparingly, gets confusing beyond 3 levels).
Breadcrumbs Support Pattern
Problem: Users navigating deep hierarchies lose track of where they are and how they got there.
Solution: A horizontal trail showing the path from the homepage to the current page. Each level is a clickable link. Format: Home > Category > Subcategory > Current Page.
When to use: Hierarchical sites with 3+ levels of depth — e-commerce categories, documentation, file systems. Essential when users arrive via search (they land deep with no context).
When not to use: Flat sites with no hierarchy. Single-level apps. As a replacement for primary navigation (breadcrumbs are secondary — they complement, not replace).
Tabs Core Pattern
Problem: Related content needs to be organized into parallel views within the same page.
Solution: A row of labeled tabs where clicking one reveals its content panel and hides the others. Only one tab is active at a time. The active tab is visually connected to its panel (shared border/background).
When to use: When content is naturally divided into 2–7 parallel categories of roughly equal importance. Settings pages (General / Privacy / Notifications), product pages (Description / Reviews / Specs), dashboards (Overview / Details / History).
When not to use: When content should be seen sequentially (use a single scrolling page instead). When there are more than 7 tabs (use a different pattern — dropdown, sidebar, or restructure). When users need to compare content across tabs (they can't see two tabs at once).
Search and filtering patterns
Search-as-You-Type (Autocomplete) Core Pattern
Problem: Users don't always know the exact term to search for, or want results before completing their query.
Solution: A search input that displays a dropdown of suggestions as the user types. Suggestions can be: popular searches, matching content titles, categories, or recent searches. Results update with each keystroke (debounced by 200–300ms to avoid excessive API calls).
When to use: Any product with searchable content. E-commerce, documentation sites, admin tools, content platforms. Google, Amazon, and Spotify have trained users to expect this.
Key decisions: What to show in suggestions (results vs. query completions vs. categories), how many suggestions (5–8 is optimal), what happens on Enter vs. clicking a suggestion, how to handle zero results in the dropdown.
Faceted Filtering Core Pattern
Problem: Users browsing a large catalog need to narrow results by multiple attributes simultaneously.
Solution: A panel (usually left sidebar on desktop, bottom sheet on mobile) with filter groups — checkboxes for categorical attributes (brand, color, size), range sliders for continuous attributes (price, rating), and toggles for binary attributes (in stock, free shipping). Results update as filters are applied. Applied filters are shown as removable chips above the results.
When to use: Catalogs with 50+ items that have structured attributes. E-commerce, job boards, real estate listings, travel booking, SaaS marketplaces.
When not to use: Small collections (under 20 items — just show them all). Content without structured attributes (blog posts — use search and tags instead).
Key decision: Filter-then-search vs. search-then-filter. Most products do both — search narrows broadly, facets refine precisely. Show the count of matching results per filter option so users know what they'll get before clicking.
Sort Controls Support Pattern
Problem: Users viewing a list or grid need to reorder items by different criteria.
Solution: A dropdown or segmented control near the top of the results. Common options: relevance (default for search), newest first, price (low to high / high to low), rating, popularity, alphabetical. Show the currently active sort clearly.
When to use: Any list longer than ~10 items where order matters. Product catalogs, search results, tables, feeds.
Key decision: What's the default sort? For search results: relevance. For content feeds: newest first. For products: "featured" or "best selling" (not random). The default sort is the most important design decision because most users never change it.
Content and layout patterns
Card Layout Core Pattern
Problem: Users need to browse heterogeneous content and make quick comparisons.
Solution: Contained units of content in a grid or list. Each card has: a visual (image, icon, or thumbnail), a title, a summary or key attribute, and a primary action (click to open, add to cart, etc.). Cards are uniform in size within a grid but flexible in content.
When to use: Any browsable collection — products, articles, projects, team members, recipes, properties. Cards work when each item has a visual component, a name, and a few key attributes. Pinterest, Airbnb, Netflix, and Trello all use card grids.
When not to use: When items have no visual component (use a list instead). When users need to compare many attributes across items (use a table). When items must be consumed sequentially (use a feed or timeline).
Variants: Horizontal scroll (Netflix-style rows for categories), masonry (Pinterest-style varied heights for visual content), list cards (full-width horizontal cards for text-heavy content).
Infinite Scroll vs. Pagination Decision Pattern
Problem: A content set is too large to display on one page. How should additional content load?
Use infinite scroll when: Content is homogeneous and exploratory (social feeds, image galleries, news). Users are browsing, not searching for a specific item. Each item is roughly equal in importance. Mobile-first experiences where tapping "next" feels heavy.
Use pagination when: Users need to reference specific positions ("it was on page 3"). Content has a clear ranking and items near the top matter most (search results). Users need to reach the footer (infinite scroll buries it). Users want to bookmark or share a specific page of results.
Hybrid approach: "Load more" button. Gives the control of pagination with the continuity of infinite scroll. User chooses when to load more rather than being forced by scrolling. Good middle ground for most cases.
Modal / Dialog Core Pattern
Problem: A focused interaction needs the user's full attention without losing the context of the parent page.
Solution: An overlay that appears above the page, dimming the background. Contains a focused task (confirm deletion, fill a short form, view an image). Has a clear close mechanism (X button, click outside, Escape key). Does not navigate away from the current page.
When to use: Short, focused interactions that don't warrant a full page: confirmations, quick edits, image previews, sharing dialogs, onboarding steps.
When not to use: Complex multi-step flows (use a full page). Content that should be indexable by search engines. On mobile where modals feel cramped (use a full-screen sheet instead). Nested modals — never open a modal from within a modal.
Modal abuse
Modals interrupt. Every modal says "stop what you're doing and deal with this." Use them sparingly. If your page has more than one unprompted modal (cookie banner + newsletter popup + chat widget), you're abusing the pattern. Each interruption erodes trust.
Skeleton Screens Core Pattern
Problem: Content takes time to load, and a blank page or spinner makes the wait feel longer.
Solution: Placeholder shapes that mimic the layout of the content about to appear — gray boxes where images will be, lines where text will be. Content replaces the placeholders as it loads, creating a seamless transition.
When to use: Any content that takes 0.5–3 seconds to load. Feed items, card grids, profile pages, dashboard widgets. Facebook, LinkedIn, YouTube, and Slack all use skeleton screens.
When not to use: When content loads instantly (<200ms). When the layout is unpredictable (you can't show a skeleton if you don't know what the content looks like). For error states (show an error message, not an endless skeleton).
Data display patterns
Data Tables Core Pattern
Problem: Users need to view, compare, sort, and act on structured data with multiple attributes per item.
Solution: A grid of rows and columns with: a header row for column labels, sortable columns (click header to sort), row actions (edit, delete, view — in a final column or on hover), and optionally: row selection (checkboxes), pagination, column resizing, and inline editing.
When to use: When users need to compare items across multiple attributes. Admin panels, CRMs, analytics, inventory, spreadsheet-like views. When precision matters more than visual appeal.
When not to use: When items have primarily visual content (use cards). When there are fewer than 3 attributes per item (use a simple list). On mobile without responsive adaptation (tables don't work on small screens without horizontal scrolling or column prioritization).
Responsive approach: On mobile, either prioritize columns (show only the most important, reveal others on tap), stack columns into cards (each row becomes a card), or allow horizontal scroll with the first column frozen.
Status Indicators Support Pattern
Problem: Users need to quickly assess the state of items in a list or dashboard.
Solution: Visual cues that communicate status at a glance: colored dots (green=active, yellow=pending, red=error), badges with labels, progress bars for completion percentage, or icon changes. Always pair color with a secondary indicator (shape, label, icon) for color-blind users.
When to use: Task lists, order tracking, deployment pipelines, notification systems, user account states, system health monitors.
Key decision: How many distinct statuses to show. 3 (good/warning/error) is easy to parse. 7+ becomes confusing. If you have more than 5 statuses, consider grouping them or using a different visualization.
Input and action patterns
Stepper / Multi-Step Form Core Pattern
Problem: A complex form has too many fields for a single page but needs to feel manageable.
Solution: Break the form into logical steps (2–5 steps). Show a progress indicator at the top (step 1 of 4, or a progress bar). Each step contains a related group of fields. "Back" and "Next" buttons allow navigation. A summary/review step at the end lets users check before submitting.
When to use: Checkout flows, registration, insurance applications, onboarding wizards — any form with more than ~8 fields that can be grouped logically.
When not to use: Simple forms (under 6 fields — just show them all). When users need to see all fields simultaneously for context. When steps don't have logical groupings (forced steps feel arbitrary).
Floating Action Button (FAB) Mobile Pattern
Problem: A primary creation action needs to be always accessible without consuming inline space.
Solution: A circular button floating above the content, typically in the bottom-right corner. Contains a single icon (usually +) for the product's primary creation action. Can expand to reveal 2–4 secondary actions on tap.
When to use: When the product has one dominant creation action (compose email, new post, add item) that should be accessible from any screen. Material Design popularized this — Google apps use it extensively.
When not to use: When there's no single dominant action. When the FAB would overlap important content (especially list items — users will accidentally tap the FAB instead of the last item). On desktop (use a button in the toolbar instead).
Toggle vs. Checkbox Decision Pattern
Problem: Users need to switch a binary setting on or off.
Use a toggle when: The setting takes effect immediately (no "Save" button). Think of it as a light switch — flip it and the change happens. Toggles represent a system state: "dark mode is on," "notifications are enabled."
Use a checkbox when: The setting is part of a form that requires a "Save" or "Submit" action. Checkboxes represent a selection: "I agree to the terms," "Include archived items." The change doesn't happen until the form is submitted.
Key rule: If the user expects the change to happen instantly, use a toggle. If they expect to save/submit, use a checkbox. Mixing these creates confusion about when changes take effect.
Collaborative and multiplayer patterns
Multiplayer UI Patterns Pattern Library
Use when: designing products where multiple users view or edit the same content simultaneously.
Real-time collaboration introduces UI patterns that single-user products don't need. Presence indicators show who's active in the same document, page, or workspace — avatar stacks, status dots, and "currently viewing" labels help users understand who else is here and what they're doing. Shared cursors and selections make other users' actions visible: colored cursors in collaborative editors (Google Docs, Figma), highlighted selections, and "currently editing" field locks prevent conflicting edits while maintaining awareness. Real-time conflict resolution handles what happens when two users edit the same content simultaneously — strategies range from last-write-wins (simple but lossy) to operational transformation (complex but preserves both edits) to explicit locking (safe but creates bottlenecks). Commenting and annotation systems layer conversation onto content: threaded comments anchored to specific elements, resolved/unresolved states, mention notifications, and comment visibility scoping (who can see what). Activity feeds and change history track what changed, who changed it, and when — essential for async collaboration where users don't overlap in time. The key design decision: how much awareness of others to surface without creating noise. Too little awareness leads to conflicting work; too much awareness becomes distracting.
Templates and checklists
- Does this pattern match the user's mental model? (Recognition over invention)
- Is it consistent with patterns used elsewhere in this product?
- Does it work on all target devices and screen sizes?
- Is the pattern accessible (keyboard navigable, screen reader compatible)?
- Have edge cases been considered (empty state, error state, max content)?
- Is there a clear interaction feedback loop (click → response)?
- If breaking a standard pattern, is there research justifying the deviation?
[e.g., Search-as-You-Type]
[The user needs to...]
[Conditions and contraindications]
[States, transitions, edge cases]
Real-world examples
Case study
Airbnb: card pattern mastery
Airbnb's search results demonstrate how a single pattern (the card) can carry enormous information density without feeling heavy. Each card contains: a photo carousel (swipeable), a heart/save icon, a location label, a title, a price, a rating with review count, and a "Guest favourite" badge if applicable. That's 7+ data points per card, yet it feels scannable because of strict visual hierarchy — the photo dominates, price is bold, everything else is secondary. The pattern is identical across desktop (grid), tablet (2-column), and mobile (stack) — only the layout changes, never the card content structure.
Case study
Slack: sidebar navigation at scale
Slack's sidebar handles a problem most sidebar patterns fail at: unbounded growth. Users can have hundreds of channels, DMs, and apps. Slack solves this with sections (Channels, Direct Messages, Apps), each collapsible. Within sections, items are sorted by recency. A "quick switcher" (Cmd+K) provides instant keyboard-driven navigation for power users. Starred and pinned items float to the top. Unread indicators (bold text + dot) draw attention without disrupting the structure. The sidebar is both a navigation pattern and a notification pattern — and it works because each layer has a clear purpose.
Case study
Stripe: data tables done right
Stripe's payment dashboard shows data tables at their best. Each table has: sortable columns, clickable rows (open the payment detail), a search/filter bar above, pagination below, and inline status indicators (colored dots + labels for "Succeeded," "Pending," "Failed"). The table adapts to context — the overview table shows fewer columns; clicking through reveals a detailed table with more. They never try to show all data at once. Column visibility and density controls let users customize their view. The result: complex financial data feels manageable.
Common pitfalls
Pattern cargo-culting
Copying a pattern from a successful product without understanding why it works. Uber has a map-first interface because their core interaction is spatial. Putting a map on your SaaS dashboard because "Uber does it" is cargo-culting. Understand the problem the pattern solves, not just the company that uses it.
Overloading patterns
Trying to make one pattern do too much. A card that contains a title, description, 5 tags, 3 action buttons, a status badge, a timestamp, an avatar, and a progress bar isn't a card — it's a dashboard in disguise. If a pattern needs more than 5–6 pieces of information, consider whether the content belongs in a detail view instead.
Ignoring mobile from the start
Designing a desktop pattern first and then "making it responsive" later inevitably breaks it. A sidebar nav that collapses into a hamburger menu on mobile is often worse than a bottom nav that was designed for mobile from the start. Consider the primary platform early and design for it first.
How to use this topic
This is a reference page, not a linear read. Come here when you're facing a specific design challenge:
"I need to design the navigation" → Navigation patterns section. Choose top nav, sidebar, or bottom nav based on your structure and platform.
"Users can't find what they're looking for" → Search and filtering patterns. Add search-as-you-type, faceted filtering, or better sort controls.
"I'm designing a list of items" → Content patterns. Choose between cards, tables, or lists based on what users need to do with the items.
"The form has too many fields" → Input patterns. Consider a multi-step form, progressive disclosure, or removing fields entirely.
"We need to show data" → Data display patterns. Tables for comparison, status indicators for at-a-glance assessment.
Social and engagement patterns
Notifications Core Pattern
Problem: Users need to be informed about events that happened while they weren't looking.
Solution: A bell icon with a badge count in the nav. Clicking reveals a dropdown of recent notifications. Each notification has: an icon or avatar, a description, a timestamp, and a read/unread state. Clicking a notification navigates to the relevant content.
Key decisions: What's worth notifying about? Not everything. Apply the "would the user thank me for this interruption?" test. Group related notifications ("3 people liked your post" not three separate notifications). Provide clear settings so users control what they receive.
Onboarding Patterns Core Pattern
Problem: New users don't know what the product does or how to get started.
Progressive onboarding: Reveal features as the user encounters them. Tooltips and coach marks appear the first time a user sees a feature. Doesn't interrupt the workflow — the user learns by doing.
Checklist onboarding: A visible task list of setup steps (add a profile photo, invite a team member, create your first project). Shows progress and gives a sense of accomplishment. Slack, Notion, and Asana use this pattern.
Empty state onboarding: The first time a user sees an empty section, show what it's for and how to populate it. The empty state is the tutorial.
When not to use a product tour: Multi-step modal walkthroughs ("Click next to continue") have high dismissal rates. Users skip them because they're not ready for the information. Progressive onboarding almost always outperforms product tours.