Look-alike terms

Good for

Items share the same structure, each only needs three to five fields, and users pick by browsing

Not for

Many similar items, each with lots of fields that need column-by-column comparison (use a Data Table)

Good for

The content is mostly images with different aspect ratios that you don't want to crop

Not for

Items have a clear order (time, ranking) and users need to view them in that order

Good for

The content is mostly images or videos and the text can be left out

Not for

Each item needs text like a title, description or price (use a Card Grid)

Good for

Items share the same structure, there are many of them (dozens to thousands), and users need to filter, sort and page through them

Not for

The content is mostly images and users pick by looking at them (use a Card Grid or Gallery)

Good for

Items share the same structure and each has only two or three fields

Not for

Each item has many fields that need column-by-column comparison (use a Data Table)

Good for

Each item is complete content that can be read directly, and items vary in length and format

Not for

Items are just entry points, each with only a title and one or two bits of info (use a List View)

Good for

Users need to view or handle records of the same kind one after another

Not for

The left column is just a fixed feature menu, not data records (use a Sidebar Layout)

Good for

There are many feature modules (more than seven) or menus two or more levels deep

Not for

The left column shows data records that users click to see details (use a Master-Detail Layout)

Good for

The page has both navigation categories and side info that should stay visible on either side of the main content

Not for

There's only navigation and no side info, so the right column would be empty or stuffed with filler

Good for

The task has clear steps in order, and each step depends on the result of the one before it

Not for

There aren't many fields (ten or fewer) and they have no order between them (use a Single Page Form)

Good for

Creating or editing a record with twenty or fewer fields

Not for

The task has clear steps in order, or there are so many fields that they span several screens (use a Wizard)

Good for

There are many independent options that can be grouped by category

Not for

A set of fields that needs to be filled in and submitted together (use a Single Page Form)

Good for

Before an irreversible action like delete or submit, the user needs to clearly confirm

Not for

You're just reporting the result of an action, like "Saved," and no decision is needed

Good for

Viewing or editing a single record from a list page while keeping the list in view

Not for

You only need the user to confirm one sentence; a modal or popover fits better

Good for

Hovering or clicking an item needs to show a few lines of extra info or a profile card right there

Not for

You only need one line of plain text to explain an icon or button; a tooltip is lighter

Good for

After save, copy, delete, or similar actions, one sentence is enough to report the result

Not for

The error needs to be read carefully or acted on, and a few seconds isn't enough time

Good for

You need to keep reminding the user about an unresolved state, like an unverified account or ongoing maintenance

Not for

You're just reporting the result of an action that just finished, like "Copied"

Good for

A background task finished or failed while the user may be doing something else

Not for

You're just reporting the result of what the user just clicked; a toast is enough

Good for

Waiting for an API response after clicking a submit button, usually a second or two

Not for

The page is loading for the first time and the layout is known; a skeleton reduces jumping

Good for

A page, list, or card is loading for the first time, and its content layout is known ahead of time

Not for

A short wait after clicking a button; a spinner inside the button fits better

Good for

Upload, download, export, and other long tasks where you can get the actual percentage done

Not for

You can't get real progress and are just waiting for an API response; a spinner is more honest

Good for

6 or more options that take too much room when laid out, like cities, countries, or departments

Not for

Only 2 to 5 options, and you want users to see them all at a glance. Use radio buttons.

Good for

When an object has 3 or more secondary actions and laying them all out as buttons would feel crowded, like the extra actions on a table row

Not for

Letting users pick a value in a form and submit it. Use a select.

Good for

Picking a single value with fixed levels in a form, like state, county, and city, or a product category

Not for

You need to check several nodes at different levels at once; use a tree with checkboxes

Good for

When one object has several peer blocks of info and users look at one at a time, like overview, history, and logs on a detail page

Not for

Flows with a set order that must be completed step by step, like sign-up or checkout. Use steps.

Good for

Switching between two or three ways of showing the same data, like list and grid views

Not for

You're switching between completely different content areas; tabs fit better

Good for

Multi-step flows with a fixed order, like sign-up, checkout, or activating a service

Not for

Blocks of content that are independent and can be viewed in any order. Use tabs.

Good for

When the user needs to trigger something that changes data, like submit, save, or delete

Not for

When clicking only goes to another page or an external URL. Use a link.

Good for

Edit, delete, more, and similar actions repeated in table rows, cards, and list items

Not for

When the action isn't intuitive and users can't guess what happens from the icon alone

Good for

Going to another page on the site, like from a list to a detail page

Not for

When clicking submits, deletes, or saves data. Use a button.

Good for

Picking any number of options from a group, like interests, permissions, or fields to export

Not for

When only one option in a group can be chosen. Use radio buttons.

Good for

2 to 5 mutually exclusive options that users should see and compare without opening anything

Not for

Options where several can be picked at once. Use checkboxes.

Good for

Turning a feature on or off on a settings page, where the change applies immediately

Not for

Options that only apply after filling in the whole form and clicking submit, like agreeing to terms. Use a checkbox.

Good for

Uniform items in large numbers with four or more fields each, where users need to compare column by column

Not for

Only two or three fields per item, like a title and a time. A list is cleaner.

Good for

Items with just a title and a line or two of description that users browse top to bottom, like messages, notifications, or comments

Not for

Uniform items with many fields that need comparing or sorting by column. Use a table.

Good for

Items that are mainly visual, like cover images or product photos, where users pick by looking

Not for

Uniform items in large numbers that need field-by-field comparison or sorting. Use a table.

Good for

The data has clear parent-child relationships, like an org chart, folders, or product categories

Not for

A form only needs one value picked along the hierarchy, like state and city; a cascader is more compact

Good for

Picking a single value with fixed levels in a form, like state, county, and city, or a product category

Not for

You need to check several nodes at different levels at once; use a tree with checkboxes

Good for

Picking a batch from dozens to hundreds of flat options while always seeing what's already selected

Not for

There are only a few options; a checkbox group or multi-select dropdown saves space