The 50 UX/UI Terms Designers Actually Use in Reviews

Learning Objectives

By the end of this chapter you will be able to:

• Recognize the 50 terms that come up most often in real UX/UI design reviews, portfolio critiques, and design-system audits
• Explain why each term matters, not just what it means
• Turn vague feedback ("this feels off," "I don't like this") into a precise, defensible critique using the correct term
• Spot the before/after difference each principle makes on a real interface
• Use this vocabulary credibly in a design review, a job interview, or your own self-critique

Prerequisites

Who this is for: junior and mid-level designers, developers who work closely with design, career changers moving into UX/UI, and anyone preparing for a design interview or portfolio review.

Required knowledge: none beyond having used apps and websites as a normal person. No design degree assumed.

Estimated reading time: 35–45 minutes for a full read, 5 minutes if you only use the Cheat Sheet and Glossary.

Difficulty: Beginner to Intermediate. A few sections (Fitts's Law, information foraging) touch research that's genuinely used at Senior/Staff level.

Why This Matters

Design critique has its own dialect. Walk into a review at Google, Airbnb, or a mid-size product team and you won't hear "I don't like the button." You'll hear "the primary CTA is competing with the nav for visual hierarchy" or "this violates recognition over recall — the user has to remember the code from the last screen."

That vocabulary isn't decoration. It exists because:

• It's faster than re-explaining intuition every time. "This has a discoverability problem" compresses a whole argument into four words that everyone in the room already understands.
• It converts a subjective opinion into a testable claim. "I don't like this" can't be argued with. "The touch target is under 44pt and will fail on mobile" can be measured and fixed.
• It's how you're evaluated. In design interviews and portfolio reviews, using precise language signals that your decisions were reasoned, not accidental. Saying "I increased contrast to meet WCAG AA" reads very differently than "I made it darker because it looked nicer."
• Standards bodies and platform teams write it into law. Apple's Human Interface Guidelines, Google's Material Design, and the W3C's Web Content Accessibility Guidelines (WCAG) all encode these terms directly — a 44×44pt minimum touch target in Apple's HIG is Fitts's Law turned into a rule.

This chapter treats the vocabulary as a toolkit. Each term below is something you can point at on a real screen and say, out loud, in a review.

First Principles

Before the list, three things worth understanding from zero.

A critique is not an opinion contest. A design review works when feedback is anchored to a principle, a user goal, or a piece of evidence (a heuristic, a usability test, an accessibility standard) rather than personal taste. "I'd make it blue" is taste. "The current color fails contrast requirements for low-vision users" is a critique.

Every UI decision is a tradeoff, not a right answer. Nearly every term below cuts both ways — more whitespace improves clarity but costs information density; more progressive disclosure reduces overwhelm but adds clicks. Good critique names the tradeoff being made, not just the direction.

The words describe the user's experience, not the designer's intention. "Affordance," "cognitive load," and "friction" all describe what happens inside the person using the product — not what the designer meant to happen. This is why user testing keeps correcting designers who are confident their interface is clear.

This diagram is the whole chapter in miniature: vague feeling → precise term → specific fix. That translation is the actual skill.

Core Concepts

The 50 terms are grouped into seven clusters that mirror how they actually come up in a review. A handful of high-frequency terms get full before/after treatment; the rest get a tight, usable definition — this keeps the chapter a reference you'll actually return to, instead of 50 essays you'll skim once.

Cluster A — Perception & Visual Design

Visual hierarchy — the deliberate ordering of elements by size, weight, color, and position so the eye lands on the most important thing first.

Misconception: hierarchy means "make the important thing bigger." In practice it's a system of contrast — size, weight, color, spacing, and position all working together. A huge button next to five other huge buttons has no hierarchy at all.

Before/After: A signup form where the "Create Account" button, "Learn More" link, and legal disclaimer are all the same size and weight forces the user to read everything to find the primary action. After: the CTA is the only filled, high-contrast button on the screen; everything else recedes in weight and color. Time-to-first-click drops because there's only one obvious thing to do.

Gestalt principles — a set of rules from early-20th-century perceptual psychology (Wertheimer, Koffka, Köhler) describing how humans group visual elements automatically. The ones that come up in reviews constantly:

• Proximity — items placed close together are read as related (this is why label-to-field spacing matters more than most people think)
• Similarity — items that look alike are read as the same category
• Closure — the eye completes incomplete shapes (used constantly in logo design and progress indicators)
• Continuity — the eye follows the smoothest path, which is why misaligned elements feel "off" even when nobody can say exactly why

Contrast — the visual difference between elements, used both for aesthetic hierarchy and for accessibility. In a review, "there's no contrast between these two states" usually means active and inactive tabs look identical.

Whitespace (negative space) — the empty space around and between elements. Its job is not decoration; it's grouping and pacing. Removing whitespace to "fit more in" is one of the most common ways a design becomes harder to use while looking more "complete."

Affordance — a property of an object that suggests how it can be used, independent of any label. A door handle affords pulling; a flat plate affords pushing. Don Norman introduced the term to design in The Design of Everyday Things (1988), borrowing it from perceptual psychologist James J. Gibson.

Common misconception: "affordance" and "signifier" get used interchangeably, but they're not the same thing (see below) — this mix-up is one of the most frequent vocabulary errors in junior reviews.

Before/After: A card in a UI that looks completely flat has no affordance of being clickable. After: a subtle shadow, hover state, and cursor change signal "this is pressable" before the user ever taps it — no label required.

Signifier — the visible cue that communicates an affordance. Norman later clarified this distinction because "affordance" was being misused for things that only look clickable. A blue, underlined word affords nothing physically — text doesn't afford clicking — but the styling signifies that it's a link. This is the correct term for "make it obvious this is tappable."

Visual noise — competing visual elements with no functional purpose (extra borders, redundant icons, decorative gradients) that increase scanning effort without adding information. "There's a lot of visual noise here" is reviewer shorthand for "strip this down."

Cluster B — Interaction & Feedback

Feedback loop — the system's visible response to a user action. Every action needs one: a button press without any state change (no color shift, no spinner, no confirmation) leaves the user unsure if anything happened at all.

Fitts's Law — a 1954 model from psychologist Paul Fitts predicting that the time to reach a target depends on the distance to it and its size: larger, closer targets are faster and more accurate to hit. In UI terms: bigger buttons placed closer to the user's current focus get tapped faster and with fewer errors.

Why it matters industrially: it's the direct mathematical basis for Apple's 44×44pt minimum tap target in the Human Interface Guidelines and Google's 48×48dp minimum in Material Design. It's also why the WCAG 2.2 success criterion 2.5.8 Target Size (Minimum) requires at least 24×24 CSS pixels for interactive targets at Level AA, with 2.5.5 recommending 44×44 CSS pixels at Level AAA.

Before/After: A mobile app's delete icon is a 20px glyph crammed next to four other icons in a dense toolbar — users mis-tap constantly. After: the target area is expanded to 44×44pt (the icon can stay visually small, but the tappable area is enlarged with padding), and it's spaced away from destructive-adjacent actions. Mis-tap rate drops without changing the visual design much at all.

Hick's Law — the time it takes to make a decision increases with the number and complexity of choices available. This is the research basis for "too many options" critiques and for patterns like reducing a 12-item nav down to 5 primary items plus a "More" menu.

Before/After: A settings screen lists 20 toggles in one flat list with no grouping — decision time is high and error rate climbs. After: toggles are grouped into 4 labeled sections with progressive disclosure on the advanced ones. The total number of options hasn't changed, but the number the user has to consider at once has.

Microinteraction — a small, single-purpose piece of feedback: a heart icon that pulses when tapped, a checkbox that animates a checkmark. Dan Saffer's Microinteractions (2013) is the standard reference. In review language: "this needs a microinteraction to confirm the save happened."

Perceived performance — how fast an interface feels, independent of actual load time. Skeleton screens, optimistic UI updates, and progress indicators are all techniques that manage perceived performance rather than raw speed — a 2-second load with a skeleton screen often feels faster than a 1-second load with a blank white screen.

Error prevention — designing so mistakes can't happen in the first place, rather than just handling them well after the fact. Confirming a destructive action, disabling a submit button until required fields are filled, and input masks (like auto-formatting a phone number) are all error prevention.

Forgiving design (undo) — the ability to reverse an action instead of confirming it up front. Gmail's "Undo Send" is the canonical example: instead of asking "are you sure?" before every send (which trains users to click through dialogs without reading them), it lets the action happen and offers a short window to reverse it. This is often a better solution than a confirmation modal because it doesn't add friction to the common case.

Cluster C — Cognitive & Psychological

Cognitive load — the amount of working memory a task demands. Every extra decision, unfamiliar icon, or piece of information the user must hold in their head adds to it. The term comes from John Sweller's Cognitive Load Theory (1988), originally developed for instructional design, and was adopted into UX almost wholesale.

Before/After: A checkout flow shows shipping options, tax calculations, promo code entry, and account creation all on one screen. After: the flow is split into shipping → payment → review, each screen asking for one category of decision. Total information hasn't decreased — the load at any one moment has.

Mental model — the user's internal belief about how a system works, built from past experience with other products. A shopping cart icon works because of an existing mental model from physical retail. When a product's actual behavior contradicts the user's mental model (e.g., a "trash" icon that archives instead of deletes), reviewers call it a "mental model mismatch."

Recognition over recall — one of Nielsen's usability heuristics: interfaces should make information and options visible, rather than forcing users to remember something from an earlier screen. A visible list of recent searches beats forcing the user to retype a query from memory.

Chunking — breaking information into small, related groups instead of one long stream, because working memory reliably handles only a handful of items at once (this idea traces to George Miller's 1956 paper on the limits of short-term memory). A 16-digit card number displayed as four groups of four is chunking in its purest form.

Jakob's Law — coined by Jakob Nielsen: users spend most of their time on other products, so they expect yours to work the same way. This is the standing justification for "don't reinvent the hamburger menu" style critique — novelty has a real cost in learnability.

Paradox of choice — a concept popularized by psychologist Barry Schwartz: more options can reduce satisfaction and increase decision paralysis, even when the options are all good. Comes up in reviews of pricing pages and product catalogs with excessive filtering.

Cognitive bias — a systematic pattern in how people judge and decide, relevant to critique because interfaces can accidentally (or deliberately, in the case of dark patterns) exploit them. The two that come up most in reviews: anchoring (the first price/number shown skews judgment of everything after it) and confirmation bias (users notice information that matches what they already expected, and design can either fight or exploit this).

Cluster D — Information Architecture & Navigation

Information architecture (IA) — the structural organization of content: how it's grouped, labeled, and connected so people can find what they need. IA is the blueprint underneath navigation, search, and site maps.

Information scent — a term from Peter Pirolli and Stuart Card's information foraging theory (developed at Xerox PARC in the 1990s), describing the cues (link text, icons, previews) that tell a user whether continuing down a path will lead to what they want. Strong scent means a label like "Return Policy" instead of "More Info"; weak scent forces users to click blindly to find out.

Before/After: A nav item labeled "Solutions" could mean anything — users click it, don't find what they expected, and bounce. After: it's relabeled "Solutions for Marketing Teams" — the scent now matches what a marketing-team visitor is actually foraging for, and click-through to the right page increases.

Findability — how easily a user can locate a specific piece of content, whether through navigation, search, or browsing. Distinct from IA itself — IA is the structure; findability is the outcome of that structure being good or bad.

Wayfinding — helping users understand where they are, where they've been, and where they can go, borrowed directly from architecture and signage design (Kevin Lynch's The Image of the City, 1960, is the foundational reference). Breadcrumbs, active nav states, and page titles are all wayfinding devices.

Breadcrumb navigation — a horizontal trail (Home > Category > Product) showing the user's location in a hierarchy. Named for the Hansel and Gretel story. Useful specifically in deep hierarchies; adds clutter in flat ones — a common review mistake is adding breadcrumbs to a two-level site that doesn't need them.

Content hierarchy — the relative importance of pieces of content on a page, which should drive both visual hierarchy and information architecture. "The content hierarchy doesn't match the visual hierarchy" is a way of saying the most important information isn't the most visually prominent.

Progressive disclosure — showing only what's needed now and revealing more as the user asks for it (an "Advanced settings" toggle, a "Show more" link). Reduces initial cognitive load at the cost of an extra interaction for users who do need the deeper option.

Cluster E — Usability & Accessibility

Usability heuristics — Jakob Nielsen's 10 general principles for interaction design (1994, still the industry reference), including visibility of system status, match between system and the real world, user control and freedom, consistency and standards, and error prevention. A "heuristic evaluation" (see Cluster G) is a review conducted by systematically checking a design against this list.

Discoverability — whether a user can find a feature at all, as opposed to findability, which is usually about content. "This feature has a discoverability problem" means it exists and works fine, but nothing in the UI hints that it's there.

Learnability — how quickly a new user can become proficient. One of the five components of usability in Nielsen's original definition (alongside efficiency, memorability, errors, and satisfaction).

Consistency — using the same patterns, language, and visual treatment for the same kinds of actions throughout a product (internal consistency), and following established platform conventions (external consistency, closely related to Jakob's Law). "This button style isn't consistent with the rest of the app" is the single most common line in any design system review.

Accessibility (a11y) — designing so people with disabilities (visual, auditory, motor, cognitive) can use a product. Not a feature to bolt on — a compliance and ethical baseline, and in the EU and US increasingly a legal one (the European Accessibility Act references EN 301 549, which in turn points to WCAG).

Before/After: Form fields rely on placeholder text alone for labels — the label disappears the moment the user starts typing, and screen readers may announce nothing meaningful. After: every field has a persistent, programmatically-associated <label>, and error messages are tied to their field with aria-describedby.

WCAG contrast ratio — the specific, testable rule set from the W3C's Web Content Accessibility Guidelines. As of WCAG 2.2 (the current published standard; WCAG 3.0 remains an early-stage draft), Success Criterion 1.4.3 requires at least 4.5:1 contrast for normal text and 3:1 for large text (18pt+, or 14pt+ bold) at Level AA; 1.4.11 requires 3:1 for non-text UI components like button borders and icons. Level AAA raises the text requirement to 7:1. This is one of the few terms in this list with a hard, unambiguous number attached — "it doesn't meet AA contrast" is not a matter of opinion, it's a measurement.

Error tolerance — how gracefully a system handles mistakes once they happen: clear error messages, the ability to correct without losing other input, no silent data loss. Distinct from error prevention, which stops the mistake before it occurs.

Legibility vs. readability — a distinction that comes up constantly and is frequently confused. Legibility is about the type itself — can individual letters be told apart at this size and weight? Readability is about the text as a whole — line length, line height, contrast, and layout. A font can be perfectly legible letter-by-letter and still unreadable in 90-character-wide paragraphs with no line spacing.

Cluster F — Design Systems & UI Structure

Design system — the complete, versioned collection of reusable components, patterns, guidelines, and design tokens that a product team draws from, so that consistency doesn't depend on individual designers remembering the rules. Google's Material Design and Apple's Human Interface Guidelines are public design systems; most large product companies (Shopify's Polaris, IBM's Carbon, Atlassian's Design System) maintain their own.

Design tokens — the smallest, named units of a design system's visual language (a color, a spacing value, a font size) stored as data rather than hard-coded, so a single change propagates everywhere it's used. "This should be a token, not a hardcoded hex value" is standard design-system review language.

Component — a reusable, self-contained UI element (a button, a card, a modal) with defined states (default, hover, active, disabled, error) that gets assembled into full interfaces. A review comment like "this needs its own component, not a one-off" is about long-term maintainability.

Atomic design — Brad Frost's 2013 methodology for structuring a design system in five increasingly complex layers: atoms (a single label or icon) → molecules (a labeled input) → organisms (a full search bar with button) → templates → pages. It's the most common mental model teams use to organize a component library.

Style guide — the documented rules for a brand and product's visual language: typography scale, color palette, iconography, voice and tone. Narrower than a full design system, which also includes interactive component behavior.

Grid system — the underlying structure (columns, gutters, margins) that all layout aligns to. "This isn't sitting on the grid" is a specific, checkable critique — not a matter of taste.

Alignment — whether elements share consistent edges (left, right, center, or baseline) with each other. One of the most common and most fixable issues junior designers get flagged for — misalignment is highly visible even to viewers who can't articulate what's wrong, because it violates Gestalt continuity.

Cluster G — Process & Critique Language

Heuristic evaluation — a structured review method where evaluators check a design against a known list of usability principles (usually Nielsen's 10) rather than testing with real users. Fast and cheap, but it finds known categories of problems — it can't surface issues nobody has thought to name yet.

Usability testing — watching real (or representative) users attempt real tasks on the design and observing where they struggle, as opposed to a heuristic evaluation, which uses expert judgment instead of live users. The two methods catch different things and are meant to complement each other, not replace one another.

A/B testing — showing two variants of a design to different user segments and measuring which performs better against a defined metric. Distinct from usability testing: A/B testing tells you what performs better at scale; it doesn't tell you why, which is what qualitative usability testing is for.

Edge case — a scenario outside the "normal" expected path: an empty search result, a username that's 200 characters long, a user with no internet connection mid-submit. "Did we design for the edge cases?" is one of the most common questions asked in any thorough review, because most interfaces are designed for the happy path first and the edge cases are where they visibly fall apart.

Empty state — the screen shown when there's no data yet (a new user's empty inbox, a search with zero results). A well-designed empty state explains why it's empty and what to do next; a bad one is a blank page that reads as broken.

Happy path — the ideal, no-errors sequence of steps a user takes to complete a task. Reviewers use this term specifically to contrast it with edge cases: "this only works on the happy path" is a direct challenge to check what happens when something goes wrong.

Friction — anything that makes a task harder, slower, or more effortful than necessary: an extra form field, a confusing label, an unnecessary confirmation step. Not automatically bad — checkout confirmation and delete confirmations are deliberate, useful friction. "Where's the friction, and is it intentional?" is the sharper version of this critique.

Deep Dive

A few things worth understanding at a level past the definitions.

Jargon can gatekeep as easily as it can clarify. The same vocabulary that compresses a good argument into four words can also be used to shut down a junior designer who doesn't yet have the term for what they correctly noticed. A senior reviewer's job is to translate observation into vocabulary for the team, not to require the vocabulary before the observation counts. If you're on the receiving end of jargon-heavy feedback you don't fully follow, "can you say what user problem that principle points to?" is a fair, professional question.

Most of these terms trade off against each other, and naming the tradeoff is the actual senior-level move. Progressive disclosure reduces cognitive load but adds clicks. Consistency reduces learnability cost but can lock in a worse pattern because "that's how we've always done it." Whitespace improves clarity but reduces information density on a screen. A junior critique invokes one term in isolation ("we should add progressive disclosure here"). A senior critique names the tradeoff explicitly ("progressive disclosure would reduce the load on first view, but this is a power-user screen where hiding the options costs more clicks than it saves attention — I'd keep it flat here").

Heuristics are a shortcut for user testing, not a replacement for it. Every term in Clusters A through E is, in effect, a compressed finding from decades of usability research and testing across thousands of products. That's exactly why they're useful in a fast review — but it's also why they can be wrong for a specific product and audience. A heuristic evaluation citing "recognition over recall" can still be contradicted by an actual usability test showing users in a specific niche product actually prefer typing a known command. When the heuristic and the test disagree, the test wins.

Practical Examples

Beginner: Rewriting vague feedback

Vague: "This login screen feels off."

Precise: "The 'Forgot password' link has the same visual weight as the primary 'Log in' button — there's no visual hierarchy distinguishing the primary action from the secondary one. I'd reduce the link's contrast and increase the button's."

Why this is better: it names the specific element, the specific term, and the specific fix — instead of an unfalsifiable feeling.

Intermediate: Critiquing a checkout flow

Observation: A checkout form asks for shipping address, billing address, card details, promo code, and account creation on a single page, with an unlabeled dropdown showing only country codes.

Critique using vocabulary:

• "This is a cognitive load problem — five distinct decisions live on one screen. I'd split it into shipping → payment → review."
• "The country dropdown has an information scent problem — showing only codes (DE, FR, US) gives no scent for what to select without already knowing ISO codes."
• "The 'Create account' checkbox is unchecked by default with no signifier explaining why creating an account matters at this exact moment — most users will skip it and possibly lose order history access."

Advanced: Design system audit

Scenario: A team's button component has four visual variants used inconsistently across the product: a blue filled button, a blue outlined button, a text-only blue link styled to look like a button, and a gray filled button — all triggering the same class of action (form submission).

Critique using vocabulary:

• "We have a consistency failure at the component level — four visual treatments for one semantic action. This needs to collapse into a single primary-button component with defined states, not four ad hoc treatments."
• "None of these are backed by design tokens — the blues are three slightly different hex values, which means a brand color update requires hunting down every instance instead of updating one token."
• "The text-only variant fails WCAG contrast ratio for UI components (1.4.11) against the page background — I measured 2.1:1, and 3:1 is the minimum at Level AA."
• "This is exactly the kind of finding a heuristic evaluation catches quickly, but I'd still want a short usability test to confirm users aren't already routing around the confusion by ignoring the outlined variant entirely."

Code Examples

Two small, concrete examples tied directly to terms above — not because UX vocabulary requires code, but because these two are graded by exact numbers, and numbers are worth seeing in context.

Fitts's Law in CSS — expanding a tap target without changing the visible icon size:

/* Icon looks small (24px), but the actual tappable area
   meets Apple's 44pt / Material's 48dp minimum via padding,
   satisfying WCAG 2.5.8 Target Size (Minimum) at Level AA. */
.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 44px;
  height: 44px;
  padding: 0;
}

.icon-button svg {
  width: 24px;
  height: 24px;
}

WCAG contrast ratio — checking a text/background pair meets Level AA before shipping:

// Simplified relative-luminance contrast check (WCAG formula, SC 1.4.3).
// In practice, use a vetted library like `wcag-contrast` or a design tool's
// built-in checker — this is here to show what the ratio actually measures.
function relativeLuminance([r, g, b]) {
  const [R, G, B] = [r, g, b].map((c) => {
    const s = c / 255;
    return s <= 0.03928 ? s / 12.92 : Math.pow((s + 0.055) / 1.055, 2.4);
  });
  return 0.2126 * R + 0.7152 * G + 0.0722 * B;
}

function contrastRatio(rgb1, rgb2) {
  const L1 = relativeLuminance(rgb1);
  const L2 = relativeLuminance(rgb2);
  const lighter = Math.max(L1, L2);
  const darker = Math.min(L1, L2);
  return (lighter + 0.05) / (darker + 0.05);
}

// Example: #777777 text on #FFFFFF background
console.log(contrastRatio([119, 119, 119], [255, 255, 255]).toFixed(2));
// → 4.48 — fails the 4.5:1 minimum for normal text at Level AA by a hair

Diagrams

How the 50 terms cluster in practice:

Diagnosing a complaint during a review:

Tables

Master Reference Table (all 50 terms, by cluster)

Comparison: Terms That Get Confused

Common Mistakes

Using a term as a verdict instead of an argument. Saying "this fails Hick's Law" and stopping there isn't a critique — it's a label. The useful version names the specific choices causing the problem and what to cut or group.

Confusing affordance with signifier. This is the single most common vocabulary mistake in junior reviews. If in doubt, ask: is this about what the object physically permits (affordance), or about the visual hint that it permits it (signifier)? Nearly every real critique is actually about the signifier.

Treating heuristics as absolute rules. "Consistency" and "recognition over recall" are strong defaults, not laws of physics. A product built for expert daily users (a code editor, a trading terminal) can correctly favor efficiency and keyboard recall over beginner-friendly recognition patterns.

Applying WCAG numbers loosely. "It probably has enough contrast" is not a valid check — 4.5:1 and 3:1 are exact, measurable thresholds. Eyeballing them is one of the most common ways accessibility issues make it to production.

Confusing A/B test results with usability findings. A/B testing can tell you Variant B converts 8% better; it cannot tell you why, and teams sometimes stop there instead of following up with qualitative testing to understand the mechanism — which matters if you want the win to generalize to the next redesign.

Real Industry Examples

These are documented, verifiable practices — not invented anecdotes.

• Apple's Human Interface Guidelines codify Fitts's Law directly: a documented minimum tappable area of 44×44 points for any interactive control, a rule that has held since the original iPhone HIG.
• Google's Material Design sets its own Fitts's Law-derived minimum at 48×48dp, explicitly reasoning that a larger minimum accommodates a wider range of users and motor abilities than the smallest technically usable size.
• The W3C's WCAG 2.2, published as a formal Recommendation, added new success criteria including 2.5.8 Target Size (Minimum), directly formalizing target-size guidance that had previously lived only in platform style guides, not in an accessibility standard.
• Nielsen Norman Group's usability heuristics (Jakob Nielsen, 1994) remain the most widely taught heuristic-evaluation framework in the industry and are the direct ancestor of terms like "recognition over recall" and "consistency and standards" used in this chapter.
• Brad Frost's Atomic Design methodology (2013) is the naming convention behind component libraries at a large share of design systems built since, including publicly documented systems like Shopify's Polaris and IBM's Carbon.
• Gmail's "Undo Send" is the standard, widely cited example of forgiving design substituting for a confirmation dialog — letting an action complete and offering a short reversal window instead of interrupting the user up front.

Best Practices

• Anchor every critique to a term and a specific element. "The hierarchy is off" is vague; "the secondary button has more visual weight than the primary CTA" is actionable.
• State the tradeoff, not just the direction. Naming what you're giving up (an extra click, less information density, more visual noise) is what separates a senior critique from a junior one.
• Reach for a number when one exists. Contrast ratio and target size are two of the only UX terms with hard numeric thresholds — use them instead of "feels low contrast."
• Don't let vocabulary replace testing. Heuristics predict where problems are likely; only watching real users confirms they're actually happening, and how badly.
• Translate jargon for anyone in the room who needs it. If a stakeholder or junior teammate doesn't know a term, explain the underlying observation, not just the label.

Interview Questions

Beginner

Q: What's the difference between usability and UX? A: Usability is one measurable quality within UX — specifically, how easily and error-free a task can be completed (Nielsen's definition includes learnability, efficiency, memorability, errors, and satisfaction). UX is broader: it includes usability but also emotional response, perceived value, and business context. A product can be highly usable and still have poor UX if it doesn't meet a real need.

Q: What's the difference between an affordance and a signifier? A: An affordance is what an object actually permits you to do, independent of any visual cue — a flat surface affords pushing. A signifier is the visible hint telling you that affordance exists — a "push" label on a door, or button styling on a UI element. Most visible design decisions in an interface are actually signifiers, not affordances.

Intermediate

Q: A stakeholder wants to add a fourth primary CTA to a landing page. How do you push back using UX vocabulary? A: I'd invoke Hick's Law — adding more equally-weighted choices increases decision time and can reduce the conversion rate of the action we actually care about most. I'd also point out this creates a visual hierarchy problem: if all four CTAs look equally important, none of them reads as primary. I'd propose picking one primary action and demoting the others to secondary or tertiary treatment rather than removing them outright.

Q: How would you explain the difference between a heuristic evaluation and a usability test to a non-designer stakeholder? A: A heuristic evaluation is an expert reviewing the design against known usability principles — fast, cheap, and good at catching well-understood categories of problems. A usability test is watching real users attempt real tasks — slower and more expensive, but it surfaces problems specific to this product and audience that a general checklist can't predict. I'd use heuristic evaluation early and often, and usability testing before any major decision that's expensive to reverse.

Senior

Q: Walk me through how you'd audit an existing product's design system for consistency issues. A: I'd start by inventorying every instance of a given component type (buttons, form fields, cards) across the live product, screenshotting real usage rather than relying on the documented system, because drift between documentation and shipped product is where most inconsistency actually lives. I'd check them against design tokens rather than raw values — the goal is finding places where a hardcoded hex or pixel value has drifted from the token it should reference. I'd separate "differences that are intentional variants" (a destructive-action button that's correctly red) from "differences that are unintentional drift" (three near-identical blues from copy-pasted, slightly-off hex values). I'd close by prioritizing fixes by user-facing impact and by how many places the underlying token change would need to propagate, not just by how visually obvious the inconsistency is.

Q: When should you override a usability heuristic instead of following it? A: Heuristics are compressed research findings, not laws — they hold for the majority case they were derived from, and that majority case is usually general consumer software used occasionally by non-experts. For expert tools used daily (IDEs, trading terminals, CAD software), some heuristics correctly flip: recall-based keyboard shortcuts beat recognition-based menus for daily power users, because the cost of learning is paid once and the efficiency gain compounds over thousands of repetitions. The judgment call is knowing your actual user's frequency of use and expertise level well enough to know when the general-case heuristic doesn't apply to your specific case — and backing that decision with usability data from your actual users, not just theory.

Exercises

Easy: Take a screenshot of any app on your phone. Identify five terms from this chapter that apply to what you see — at least one from Cluster A (Perception) and one from Cluster E (Usability & Accessibility).

Medium: Find a piece of feedback you've given or received that was vague ("this feels cluttered," "I don't like this flow"). Rewrite it as a precise critique using at least two terms from this chapter, and state the specific fix it implies.

Hard: Pick a real checkout or signup flow you've used recently. Map every screen against Nielsen's 10 usability heuristics and flag every violation you can find, citing the specific heuristic by name for each one.

Project: Audit a live product's button styles (or another single component type) the way the Senior interview answer above describes: screenshot every instance you can find across at least 10 screens, group them by whether they're intentional variants or unintentional drift, and write a one-page critique using at least eight terms from this chapter.

Cheat Sheet

Glossary

A/B testing — Comparing two design variants against a defined success metric with real traffic. Accessibility (a11y) — Designing so people with disabilities can use a product. Affordance — A property of an object suggesting how it can be used. Alignment — Elements sharing consistent edges with each other. Atomic design — Brad Frost's methodology structuring components into atoms, molecules, organisms, templates, and pages. Breadcrumb navigation — A trail showing a user's location within a content hierarchy. Chunking — Grouping information into small, related sets to ease memory load. Cognitive bias — A systematic, predictable pattern in human judgment. Cognitive load — The working-memory demand a task places on a user. Component — A reusable, stateful UI building block. Consistency — Using the same treatment for the same class of action throughout a product. Content hierarchy — The relative importance of content on a page. Contrast — The visual difference between two elements. Design system — The full, versioned collection of components, patterns, and rules a team uses. Design tokens — Named, reusable design values (color, spacing, type) stored as data. Discoverability — Whether a feature can be noticed to exist at all. Edge case — A scenario outside the expected, ideal path. Empty state — The screen shown when there is no data yet. Error prevention — Designing so mistakes cannot happen in the first place. Error tolerance — Handling mistakes gracefully after they occur. Feedback loop — The system's visible response to a user action. Findability — How easily specific content can be located. Fitts's Law — Time to reach a target depends on its size and distance. Forgiving design — Allowing an action to be reversed instead of confirmed upfront. Friction — Anything that adds unnecessary effort to a task. Gestalt principles — Perceptual rules describing how humans group visual elements. Grid system — The column and gutter structure layout aligns to. Happy path — The ideal, error-free sequence to complete a task. Heuristic evaluation — Expert review of a design against known usability principles. Hick's Law — Decision time increases with the number of choices available. Information architecture — The structural organization of content. Information scent — Cues predicting whether a path leads to a user's goal. Jakob's Law — Users expect your product to work like the ones they already use. Learnability — How quickly a new user becomes proficient with a system. Legibility — The clarity of individual letterforms. Mental model — A user's internal belief about how a system works. Microinteraction — A small, single-purpose piece of interface feedback. Paradox of choice — More options can reduce satisfaction and increase decision paralysis. Perceived performance — How fast an interface feels, independent of actual speed. Progressive disclosure — Revealing detail only as the user asks for it. Readability — How easily a full block of text can be read at scale. Recognition over recall — Making options visible rather than requiring memory. Signifier — The visible cue communicating an affordance. Style guide — Documented rules for a brand and product's visual language. Usability heuristics — Nielsen's 10 general principles for interaction design. Usability testing — Observing real users attempt real tasks. Visual hierarchy — Deliberate ordering of elements so importance is read first. Visual noise — Non-functional visual elements that increase scanning effort. WCAG contrast ratio — The W3C's testable numeric contrast standard (4.5:1 / 3:1 at AA). Wayfinding — Helping users understand where they are and where they can go. Whitespace — Empty space used deliberately for grouping and pacing.

References

• Norman, D. (1988/2013). The Design of Everyday Things. Basic Books.
• Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group.
• Fitts, P. M. (1954). "The information capacity of the human motor system in controlling the amplitude of movement." Journal of Experimental Psychology.
• Hick, W. E. (1952). "On the rate of gain of information." Quarterly Journal of Experimental Psychology.
• Miller, G. A. (1956). "The magical number seven, plus or minus two." Psychological Review.
• Sweller, J. (1988). "Cognitive load during problem solving." Cognitive Science.
• Pirolli, P., & Card, S. (1999). "Information foraging." Psychological Review.
• Lynch, K. (1960). The Image of the City. MIT Press.
• Schwartz, B. (2004). The Paradox of Choice: Why More Is Less. Harper Perennial.
• Frost, B. (2013–present). Atomic Design. atomicdesign.bradfrost.com
• Saffer, D. (2013). Microinteractions: Designing with Details. O'Reilly.
• Apple Inc. Human Interface Guidelines. developer.apple.com/design/human-interface-guidelines
• Google. Material Design 3 Guidelines. m3.material.io
• W3C. Web Content Accessibility Guidelines (WCAG) 2.2. w3.org/TR/WCAG22
• WebAIM. Contrast and Color Accessibility. webaim.org/articles/contrast

FAQ Schema

Q: What's the difference between affordance and signifier? A: An affordance is what an object physically permits you to do; a signifier is the visible cue that communicates that affordance exists.

Q: What contrast ratio does WCAG require? A: WCAG 2.2 Level AA requires at least 4.5:1 for normal text and 3:1 for large text and non-text UI components; Level AAA raises normal text to 7:1.

Q: What is the minimum tap target size for mobile UI? A: Apple's Human Interface Guidelines specify 44×44 points; Google's Material Design specifies 48×48dp. WCAG 2.2's Success Criterion 2.5.8 sets a 24×24 CSS pixel minimum at Level AA.

Q: Do I need a design degree to use this vocabulary correctly? A: No. Every term here describes an observable effect on a real user, not a theoretical concept — the fastest way to learn them is applying them to interfaces you already use daily.