UI design patterns are the reusable answers to problems every interface has: how to navigate, how to fill in a form, how to show that something worked. Users learn them across thousands of products, so a familiar pattern costs them nothing to understand. Here are twenty common ones, grouped by job, with when to use each.
Navigation patterns
1. Top navigation bar. For sites with a handful of main sections. Keep it to five to seven items.
2. Sidebar navigation. For apps with many sections or deep hierarchy. Collapsible on smaller screens.
3. Tab bar (mobile). For three to five top-level destinations in an app. Always visible, one tap away.
4. Tabs. For switching between related views of the same object. Not for steps in a process.
5. Breadcrumbs. For deep hierarchies, so users know where they are and can go up a level.
6. Command palette. A searchable list of actions opened with a shortcut. Great for power users in complex tools.
Input patterns
7. Inline validation. Show errors next to the field, after the user leaves it, not on every keystroke.
8. Search with suggestions. Show recent searches and suggestions as the user types. Handle empty results kindly.
9. Multi-step form. For long forms, break into steps with a progress indicator, and let users go back without losing data.
10. Smart defaults. Pre-fill what you can reasonably guess. Fewer decisions, faster completion.
Feedback patterns
11. Toasts. Brief confirmation that an action worked. Add Undo for destructive actions instead of an "Are you sure?" dialog.
12. Inline alerts and banners. For messages that relate to the page and must stay visible until resolved.
13. Skeleton screens. Placeholder shapes while content loads. They feel faster than spinners.
14. Empty states. What a screen shows when there is nothing yet. Explain what goes here and give one clear action. See empty state design.
Data display patterns
15. Cards. For browsing collections of similar items with an image and a few details.
16. Tables with filters and sorting. For comparing many items across many attributes. Sticky headers, sensible defaults, bulk actions.
17. Pagination vs infinite scroll. Pagination for finding and returning to specific items; infinite scroll for browsing feeds.
18. Dashboards. Key numbers first, details on demand. See dashboard design best practices.
Onboarding and conversion patterns
19. Onboarding checklist. A short list of setup steps with progress, rather than a tour of every feature. See onboarding UX best practices.
20. Pricing table with toggle. Plans side by side with a monthly or yearly switch and a recommended plan. See pricing page design best practices.
Using patterns well
- Use the familiar version unless you have evidence it fails your users.
- Be consistent. The same pattern should behave the same way everywhere in your product.
- Check the edge cases: long text, no data, errors, slow connections and small screens.
- Learn from real products, not concept shots, which often skip the hard states.
Build your own pattern library
The best pattern reference is the one you collected from products you trust. Save real examples with the link and a note on what each does well, tagged by pattern. In GetRef, the text in each screenshot is searchable, so "toast with undo" or "table bulk actions" brings back your examples. For sources, see the best Mobbin alternatives and design system examples.
Common questions
- What are UI design patterns?
- UI design patterns are reusable solutions to common interface problems, such as tabs for switching between views, a modal for a focused task, or inline validation for forms. Users learn them across products, so using familiar patterns makes interfaces easier to understand.
- What are the most common UI patterns?
- Common patterns include navigation bars, tabs, breadcrumbs, search with suggestions, cards, tables with filters, forms with inline validation, modals, toasts, empty states, onboarding checklists, progress indicators and pagination or infinite scroll.
- Where can I find UI pattern examples?
- Real-product libraries like Mobbin and Refero, public design systems like Material Design and GOV.UK, and your own library of saved screens from products you use.
- When should I break a UI pattern?
- Only when you have evidence that the familiar pattern fails your users and the new one performs better in testing. Breaking conventions has a learning cost for every user.
