8.6 UX patterns: what to use where

These are the decisions that quietly make or break a product: should this be a modal or a page? a table or cards? a dropdown or radio buttons? infinite scroll or pagination? Each has a right answer most of the time, and getting them wrong makes an app feel clumsy even when every feature works. This chapter is the decision rules — say which pattern you want and why, and the AI builds the one that fits.

Key vocabulary

Modal vs page vs inline: A modal interrupts for one focused decision. A page is for complex, multi-step, or shareable (deep-linkable) work. Inline editing is for changing a single value in place.
Infinite scroll vs pagination: Infinite scroll loads more as you reach the bottom (good for feeds). Pagination gives numbered pages (good for findable, referenceable data). Load-more is a button — the safe middle ground.
Segmented control: A small set of side-by-side options (2–5) where you want all choices visible at once — a view switcher. Use it instead of a dropdown when the options are few and worth showing.
Toast vs banner vs inline error: A toast auto-dismisses (transient confirmation). A banner persists (an ongoing condition). An inline error sits next to the thing that failed (a form field).

The most over-reached-for pattern is the modal. Reach for a modal only when the user must make one short, focused decision before continuing — a confirm, a quick create. Use a full page when the work is complex, multi-step, or should be deep-linkable (you can share or bookmark the URL). Use inline editing when someone’s just changing one value in place. Stacking modals on modals, or cramming a whole multi-step form into a dialog, is the clearest “didn’t think about it” smell.

FIG 1 · choosing the container for an action A two-question decision: must they decide before continuing, and is the work deep enough to deserve a URL?

Table, cards, or list? Pagination, infinite, or load-more?

For showing a collection: a table wins when rows are comparable and you scan down columns (transactions, users). Cards win for visual or heterogeneous items where each has an image or varies a lot (products, dashboards). A plain list is right for simple linear items. Watch the mobile reflow — a wide table is miserable on a phone and often wants to become cards there. For loading more of a collection: pagination suits findable, referenceable data (search results you might cite “page 3”); infinite scroll suits endless feeds; and a load-more button is the safe default that avoids infinite scroll’s broken footer and lost-scroll-position problems.

Decision	Reach for A when	Reach for B when
Table vs cards	rows are comparable, you scan columns	items are visual/varied, each is rich
Dropdown vs radios	many options; seeing all is noise	≤5 options worth showing at once
Pagination vs infinite	findable/referenceable data	an endless feed to browse
Tabs vs accordion	a few peer sections, one at a time	many sections, or tight mobile space
Toast vs inline error	transient confirmation (“Saved”)	a problem tied to one field/action

Each row is one sentence you can hand the AI to get the right pattern.

FIG 2 · the same data, as a table vs as cards A table wins when rows are comparable and you scan columns; cards win when each item is visual or varied. Same data, different call.

Tabs vs accordion, and where to put the message

Tabs are for a few peer sections viewed one at a time (Profile / Billing / Security). An accordion is better when there are many collapsible sections or space is tight, as on mobile, where a row of tabs would overflow. And match your notification to its severity and lifespan: a toast for a transient success (“Copied”), a banner for an ongoing condition the user should keep seeing (“Payment failed — update your card”), and an inline error for a problem attached to a specific field or action. A critical error the user must act on should never be a toast that vanishes in three seconds.

01 Learning objectives

0 / 6 done

02 Curated reading

NN/g — Modal & Nonmodal Dialogs: When & How to Use
essential 12m — The decision rule for the most-overused pattern.
NN/g — Infinite Scrolling: When to Use It
optional 10m — Infinite scroll vs pagination vs load-more, and the traps.
NN/g — Tabs, Used Right
optional 10m — Tabs vs accordion and how to label them.

03 Knowledge check

knowledge check3 questions · pass ≥ 70%

01easy
A critical error the user must act on should be shown as…
02medium
A complex, multi-step, shareable (deep-linkable) flow should be a…
03medium
For findable, referenceable data (e.g. search results), prefer…

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

★ must-know Commonly asked mid concept common How do you decide whether something should be a modal or its own page?
Use a modal only for a short, focused decision the user must resolve before continuing — a confirm, a quick create. Use a full page when the work is complex, multi-step, or should be deep-linkable (shareable/bookmarkable by URL). The tell that you've reached for the wrong one is a modal that scrolls, has multiple steps, or that you wish you could link someone to — all signs it wanted to be a page. Inline editing covers the third case: changing a single value in place.
What a strong answer covers
- Modal = one short, focused, blocking decision.
- Page = complex, multi-step, or deep-linkable work.
- Inline = changing a single value in place.
- A scrolling/multi-step modal is a page in disguise.
Quick self-check
You're building a 3-step 'create project' flow users may want to share a link to. Modal or page?
Follow-ups they push on
- Why is deep-linkability a reason to prefer a page?
- What's wrong with stacking a modal on top of another modal?
Red flag Reaching for a modal by default — it's the most over-used pattern, and complex flows crammed into one feel cramped and can't be linked to.
source: NN/g — Modal & Nonmodal Dialogs: When & How to Use ↗