Thirty UI elements every designer should know
Thirty essential UI elements fall into five groups: input controls such as buttons, text fields, checkboxes and sliders; navigation such as menus, tabs, breadcrumbs and pagination; information display such as cards, tables, tooltips and badges; feedback such as alerts, toasts, progress bars and spinners; and containers such as modals, accordions and panels. Using each for its intended purpose keeps interfaces familiar and easy to use.
Why UI elements matter
User interfaces are built from a common vocabulary of elements: buttons, text fields, menus, cards, alerts and more. People have learned how these elements behave from years of using websites and apps, so using them correctly makes products easier to understand. Using the wrong element, such as a checkbox where a toggle is expected or a modal for content that should be a page, creates confusion. This guide lists thirty essential elements grouped by purpose. Our UI patterns guide covers how these elements combine into larger patterns.
Input controls
| Element | Use it for |
|---|---|
| 1. Button | Triggering actions such as submit, save or next |
| 2. Text field | Short free-text input such as names or emails |
| 3. Text area | Longer text such as comments or messages |
| 4. Checkbox | Selecting zero, one or several options |
| 5. Radio button | Choosing exactly one option from a short list |
| 6. Toggle switch | Turning a setting on or off immediately |
| 7. Dropdown or select | Choosing one option from a longer list |
| 8. Slider | Selecting a value within a range |
| 9. Date picker | Choosing dates without typing errors |
| 10. Search field | Finding content by keyword |
Choosing the right input saves users effort. Radio buttons work best for two to five visible options; dropdowns suit longer lists. Toggles should take effect immediately, while checkboxes usually require a separate save or submit action.
Navigation elements
| Element | Use it for |
|---|---|
| 11. Navigation bar | Main sections of a site or app |
| 12. Tab bar | Switching between key views, especially on mobile |
| 13. Tabs | Switching between related content on one page |
| 14. Breadcrumbs | Showing location in a hierarchy |
| 15. Pagination | Moving through long lists of results |
| 16. Side menu or drawer | Secondary navigation and settings |
| 17. Links | Moving to another page or resource |
Information display
| Element | Use it for |
|---|---|
| 18. Card | Grouping related content such as products or articles |
| 19. Table | Comparing structured data across rows and columns |
| 20. List | Showing items in a simple, scannable sequence |
| 21. Tooltip | Brief help text on hover or focus |
| 22. Badge | Small counts or statuses such as unread messages |
| 23. Avatar | Representing people or accounts |
| 24. Icon | Recognisable symbols, ideally with labels |
Cards suit varied, browsable content, while tables suit comparing many similar items. Icons work best alongside text labels, since few icons are universally understood. Our post on UX for data-heavy apps covers table design in more depth.
Feedback elements
| Element | Use it for |
|---|---|
| 25. Alert or banner | Important messages that need attention |
| 26. Toast or snackbar | Brief, non-blocking confirmation messages |
| 27. Progress bar | Showing progress through a task or upload |
| 28. Spinner or skeleton | Indicating that content is loading |
Containers
| Element | Use it for |
|---|---|
| 29. Modal or dialog | Focused decisions that interrupt the flow |
| 30. Accordion | Showing and hiding sections of content |
Modals should be used sparingly for short, important interactions, such as confirming a deletion. Accordions help organise long content, such as FAQs, but hide information, so avoid them for content most users need to see.
UI elements on mobile
Many elements behave differently on touchscreens. Hover-based tooltips do not work without a mouse, so important hints should be visible or available on tap. Dropdowns often open native pickers, which are easier to use with a thumb. Bottom sheets frequently replace modals, and tab bars replace top navigation. Touch targets should be at least 44 to 48 pixels for comfortable use. Our guide to mobile-first design explains how to prioritise elements on small screens.
Common mistakes
- Using icons without labels for important actions
- Relying on placeholder text instead of labels
- Overusing modals and alerts
- Using custom controls that break keyboard access
- Mixing different elements for the same purpose
Designing every state
- Default: The normal appearance.
- Hover and focus: Shows that an element is interactive and selected.
- Active or pressed: Feedback during the action.
- Disabled: Indicates an unavailable action.
- Error: Shows invalid input with a clear message.
- Loading: Indicates work in progress.
Missing states are a common source of confusing interfaces. Defining them in a design system ensures every team uses them consistently.
Choosing the right element
- Identify the task: What is the user trying to do?
- Consider the options: How many choices or how much content is involved?
- Follow conventions: Use the element people expect for that task.
- Check accessibility: Ensure it works with keyboard and screen readers.
- Test: Confirm users understand it in context.
Accessibility for UI elements
- Use native HTML elements where possible, such as real buttons and inputs
- Give every control a visible label or accessible name
- Ensure keyboard access and visible focus states
- Meet contrast requirements for text and controls
- Make touch targets large enough on mobile
- Announce dynamic changes such as toasts to screen readers
Frequently asked questions
What are UI elements?
The building blocks of interfaces, such as buttons, text fields, menus, cards and alerts, that users interact with.
What is the difference between a checkbox and a toggle?
A checkbox selects options that are usually saved later; a toggle changes a setting immediately.
When should I use a modal?
For short, important interactions that need focus, such as confirming a destructive action. Avoid them for long content.
How do I make UI elements accessible?
Use native elements, clear labels, keyboard support, visible focus states and sufficient contrast.
Should we build custom UI elements?
Only when standard elements cannot meet the need. Custom elements must replicate keyboard, focus and screen reader behaviour.
How many button styles does an interface need?
Usually three: primary for the main action, secondary for alternatives and a text or tertiary style for minor actions.
Where can we find guidance on UI elements?
Platform guidelines from Apple and Google, the W3C ARIA Authoring Practices Guide and established design systems.