Interaction Design Principles

If UX vs. UI is the vocabulary interview and the design process is the process interview, this is the pattern-recognition interview. Interviewers hand you a screenshot, a Figma frame, or a described interaction and ask "what's wrong with this?" — and the strong answers name a specific, citable principle instead of saying "it feels off." "The submit button is too small and it's in the corner, which violates Fitts's Law" is a stronger sentence than "the button placement is awkward," not because it sounds smarter, but because it's falsifiable and teachable: another designer can look at the same screen, understand exactly what you mean, and fix it without guessing.

This subject collects the small set of named laws and heuristics that show up again and again in interaction-design interviews — not because they're an exhaustive theory of design, but because they're the shared vocabulary the field converged on for talking precisely about very common failure patterns. Most of them were formalized decades before mobile touchscreens existed (Fitts published his law in 1954, Nielsen his heuristics in 1994) and still apply directly to a modern app, which is itself a useful interview point: these aren't trends, they're descriptions of how human perception and motor control actually work.

Several of these principles connect directly to later subjects in this track — heuristic evaluation as a testing method (usability-testing-and-evaluation), touch-target sizing thresholds (accessibility-and-inclusive-design), and the navigation-depth tradeoff Hick's Law explains (information-architecture-and-navigation). Where a connection exists, this subject names it explicitly rather than re-deriving it.

Nielsen's 10 Usability Heuristics

Jakob Nielsen published these in 1994 as heuristics for expert evaluation — a checklist a trained evaluator uses to inspect an interface and predict where real users will struggle, not a from-scratch design methodology. That distinction matters in an interview: if asked "how would you evaluate an existing product's usability without running a study," the correct named method is heuristic evaluation against this list (covered as a technique in usability-testing-and-evaluation), not a generic "I'd look for problems."

1. Visibility of system status — the system always tells the user what's happening, in a reasonable time. Example: a progress bar during a file upload, a spinner plus "Saving…" label after a form edit, a delivery-tracking screen showing "Out for delivery."
2. Match between system and the real world — use words, concepts, and conventions familiar to the user, not internal jargon. Example: a shopping app uses "Cart," not "Order Aggregation Object"; a trash-can icon for delete, because it maps to a real-world mental model.
3. User control and freedom — users need an "emergency exit" for actions taken by mistake, without a forced multi-step process. Example: Undo after deleting an email; a clearly reachable "Cancel" on a multi-step checkout, not just a browser back button as the only escape.
4. Consistency and standards — don't make users guess whether different words, icons, or actions mean the same thing. Example: if a trash icon means "delete" on one screen, it should mean delete everywhere in the product, not "archive" on another screen; follow platform conventions (iOS back-swipe, Android back-button behavior) rather than inventing new ones.
5. Error prevention — better than a good error message is a design that prevents the problem from occurring at all. Example: graying out a "Send" button until required fields are valid; a confirmation dialog before a destructive, irreversible action like permanently deleting an account. (Expanded on its own below — this heuristic implies a whole hierarchy of error handling.)
6. Recognition rather than recall — minimize memory load by making objects, actions, and options visible, rather than forcing users to remember information from an earlier screen. Example: showing recently used items or autofill suggestions instead of requiring the user to retype a value they entered three screens ago.
7. Flexibility and efficiency of use — accelerators invisible to novices but usable by experts speed up interaction for frequent users, without cluttering the interface for everyone else. Example: keyboard shortcuts in a productivity app; saved filters or bulk actions for a power user who repeats the same task daily.
8. Aesthetic and minimalist design — interfaces shouldn't contain irrelevant or rarely needed information that competes with the relevant information. Example: a settings screen with 40 flat options overwhelms; grouping and progressive disclosure (a pattern also relevant to Hick's Law, below) surfaces only what's needed now.
9. Help users recognize, diagnose, and recover from errors — error messages in plain language (no error codes), that precisely indicate the problem, and constructively suggest a fix. Example: "This email is already registered — log in instead?" beats "Error 409."
10. Help and documentation — even though it's best if the system needs no explanation, it may be necessary to provide help — and that help should be easy to search, focused on the user's task, and not overly long. Example: contextual tooltips on a complex form field, a searchable help center linked from the specific screen where the user got stuck, not a single monolithic FAQ page.

Why this list specifically, in an interview. These ten aren't the only usability principles that exist, but they're the ones almost every interviewer has memorized, so citing them by name (not paraphrasing loosely) signals you've actually studied the field rather than just "designed things." The strongest answers don't stop at naming a heuristic — they name the heuristic and the concrete fix, the way the examples above do.

Heuristic evaluation as a formal method. When Nielsen's list is used as an actual evaluation technique (rather than a design checklist consulted while building), 3-5 independent evaluators each review the interface separately against all ten heuristics, then pool findings and rate each one's severity — typically on a 0-4 scale from "not a usability problem" to "usability catastrophe, must fix before release." Using multiple evaluators matters because any single reviewer only catches a fraction of the real problems; Nielsen's own research found roughly 5 evaluators together catch about 75% of usability problems in an interface, with diminishing returns past that. If an interviewer asks "how would you run a heuristic evaluation," naming this structure — independent review, then pooled severity ratings, not a single person's opinion — is the difference between describing the method and describing "looking at the screen and complaining."

A quick self-check when applying the list to a screenshot: ask, for each heuristic in turn, "does this screen tell me what's happening right now (1)? Does it speak my language (2)? Can I undo what I just did (3)? Is this consistent with how the rest of the product behaves (4)? Could this mistake have been prevented (5)? Am I being asked to remember something from another screen (6)? Is there a faster path for someone who does this daily (7)? Is anything on this screen competing for attention that doesn't need to be here (8)? If I made an error, would I know how to fix it (9)? If I'm stuck, is help close at hand and specific to this task (10)?" Working through the list in order, rather than free-associating, is what keeps a heuristic evaluation from turning into an unstructured list of personal opinions about the design.

Gestalt Principles

The Gestalt principles come from early-20th-century perceptual psychology and describe how the human eye and brain group visual elements automatically, before any conscious reasoning happens. This is the critical interview point: Gestalt violations create confusion that no amount of labeling or copy can fix, because the confusion happens at the perceptual layer, before the user has even started reading.

• Proximity — elements placed close together are perceived as related; elements placed far apart are perceived as unrelated, regardless of what a label says. Example: a form label positioned closer to the wrong input (e.g., equal spacing above and below, or closer to the field above it) reads as belonging to the wrong field, even if the label text is unambiguous.
• Similarity — elements that share visual traits (color, shape, size) are perceived as part of the same group or category. Example: using the same blue, underlined style for both real hyperlinks and non-interactive emphasized text tells users they're the same kind of thing — so users click the non-interactive text and get nothing.
• Common region — elements enclosed within a shared boundary (a border, a background fill, a card) are perceived as one group, even without proximity or similarity cues. Example: a bordered card containing a product image, title, and price reads as one unit — "this is one product" — even if the three elements aren't otherwise closer together than they are to the next card.
• Closure — the eye completes incomplete shapes, perceiving a whole where only partial information is given. Example: a progress ring that's 75% drawn is still read as "a circle, mostly complete," not as an ambiguous arc — logos and icons rely on this constantly (the WWF panda, a partially drawn checkmark).
• Continuity — elements arranged along a line or curve are perceived as a continuous sequence, and the eye follows that path. Example: a horizontally scrolling carousel of cards reads as one continuous sequence to explore, because the eye follows the implied line across the cards, not as unrelated isolated tiles.

The reason these matter more than they might sound: a designer can write a perfectly accurate label ("Shipping Address") and still produce a confusing form if that label sits equidistant between two inputs — the visual structure told the user something the text didn't. Interviewers use this to test whether you understand that interaction design operates on perception, not just information architecture.

A minimal ASCII illustration of proximity doing the work labels alone can't:

  Ambiguous (equal spacing — which field does the label belong to?)

  Email
                              ← equal gap
  [_____________________]
                              ← equal gap
  Password

  Fixed (tight-then-loose spacing — proximity now matches the intended pairing)

  Email
  [_____________________]     ← tight gap: label owns this field

                               ← loose gap: visually separates the pairs
  Password
  [_____________________]     ← tight gap: label owns this field

Gestalt principles are perceptual, not decorative. It's tempting to file these under "visual polish," but they operate before the user starts reading — the brain groups shapes by proximity, similarity, enclosure, and continuity automatically, in the same fast, pre-conscious way it recognizes a face in a cloud. That's exactly why an interviewer asking "why doesn't this form read cleanly, even though every label is technically correct" is testing whether you'll reach for a Gestalt explanation instead of guessing at copy tweaks that won't fix a spatial problem.

Fitts's Law

Fitts's Law (Paul Fitts, 1954) states that the time required to move to and acquire a target is a function of the distance to the target and the target's size — closer and larger targets are faster and easier to acquire; smaller and farther targets take longer and produce more errors. Originally a model of human motor control for physical pointing tasks, it applies directly to cursor movement and touch interaction.

Practical design implications:

• Touch target sizing. Interactive elements need a minimum tap-target size to be reliably and quickly tappable — this subject foreshadows the specific numbers (44×44pt on iOS, 48×48dp on Android) covered in accessibility-and-inclusive-design, but the reason those minimums exist is Fitts's Law: below a certain size, acquisition time and error rate both increase sharply, independent of how visually clear the target is.
• Placement of frequent actions. Put actions a user reaches for constantly (a primary CTA, a close button, a "back" action) where they're fast to reach — not buried at the end of a long scroll or requiring a precise, deliberate movement.
• The "Fitts's Law corner" trick. Screen edges and corners are, for pointer-based interfaces, effectively infinite-size targets — the cursor can be moved to a screen edge without needing to stop precisely, because the OS boundary stops it. This is why macOS puts the menu bar and traffic-light controls flush against the top edge and corner: you can throw the cursor at the corner without aiming carefully, and it always lands.
• A common violation: a large modal with a tiny "×" close button tucked in a corner, several pixels from the modal's actual edge. It combines a small target with imprecise placement (not flush against a screen or container edge, so the corner trick doesn't apply), which is why users often miss it or give up and click outside the modal instead.

Fitts's Law is one of the most commonly misquoted principles in interviews — candidates often state "bigger is always better" without the distance half of the relationship. The precise, citable form is: acquisition time increases with distance and decreases with target size — both variables, not just one. The commonly cited (Shannon) formulation is T = a + b·log2(D/W + 1), where T is movement time, D is distance to the target, and W is target width — you don't need to reproduce the formula in an interview, but knowing that the relationship is logarithmic (not linear) explains why the first increase in a tiny target's size buys a much bigger speed improvement than the same size increase applied to an already-large target.

Where the same principle shows up outside buttons. The macOS Dock's "magnification" effect — icons growing as the cursor approaches — is a direct Fitts's Law application: it enlarges the effective target right as the user is acquiring it, without permanently consuming screen space. Right-click and long-press context menus are another case: they appear centered at the cursor's current position, so the distance term of Fitts's Law is effectively zero for whichever option is nearest the pointer, which is why frequently used context-menu items are often placed near the top, closest to where the cursor lands.

Hick's Law

Hick's Law (William Edmund Hick, 1952) states that the time it takes to make a decision increases with the number and complexity of choices available — more options, or more complex options, mean slower decisions, not just more thorough ones.

Design implications:

• Navigation and settings screens benefit from a small number of well-organized top-level choices rather than exposing every option at once. This is the theoretical basis for progressive disclosure: show the common path first, and reveal less-common options only when the user asks for them (an "Advanced settings" section, a "More" menu).
• The completeness tension. Hiding options to reduce decision time can also hurt discoverability — a user who needs a buried option may never find it if it's tucked two levels deep. This is the exact same tradeoff raised in information-architecture-and-navigation's discussion of hamburger menus: collapsing navigation into an icon reduces visible choice (helping Hick's Law) at the direct cost of making the available options invisible until tapped (hurting discoverability). Neither side of that tradeoff is free, and a strong interview answer names both directions rather than treating "fewer choices" as an unconditional good.
• Grouping reduces effective choice count even when the total number of options doesn't shrink. Twelve settings organized into three labeled groups of four are cognitively lighter to scan than twelve settings in one flat list, because the user decides "which group" before "which item," rather than scanning all twelve at once.

Hick's Law is frequently paired with Fitts's Law in interviews as "the two laws," but they describe different bottlenecks: Fitts's Law is about the motor cost of reaching a known target; Hick's Law is about the cognitive cost of deciding which target to reach for in the first place. A screen can violate one without the other — a menu with only two large, well-spaced buttons (good Fitts's Law) can still present an agonizing choice if those two options are ambiguously worded (bad Hick's Law).

The formal relationship is also logarithmic — decision time scales with log2(n) for n roughly-equally-likely choices, not linearly — which is the mathematical reason grouping helps even when the total option count is unchanged: splitting 12 flat options into 3 groups of 4 turns one log2(12) decision into a log2(3) decision followed by a log2(4) decision, and the sum of the two smaller logs is meaningfully less than the one larger log. You don't need the formula in an interview, but "grouping reduces the effective branching factor of the decision, not just the visual clutter" is a stronger sentence than "grouping makes it feel less busy."

Affordances and Signifiers

Don Norman's distinction, from The Design of Everyday Things, separates two things interviewers often conflate:

• An affordance is what an object actually allows you to do — a physical or digital property of the object itself. A button is clickable; that's the affordance, independent of whether anyone can tell just by looking at it.
• A signifier is the perceivable cue that communicates an affordance exists — the visual signal that tells the user "this is clickable." A drop shadow under a button, a slight bevel, a color that differs from surrounding text, a cursor change on hover — these are signifiers, not the affordance itself.

The common failure this explains: over-flattened "flat design." A design trend that strips shadows, borders, bevels, and other dimensional cues in favor of pure flat color removes signifiers while leaving the underlying affordance untouched — a button is still clickable, but nothing about its appearance tells the user that anymore. The result is UI elements that are functionally interactive but visually indistinguishable from static text or decoration, so users don't discover them, or hesitate before tapping something that might not do anything. This is a real, citable critique of the mid-2010s flat-design era (post-iOS 7), and naming it precisely — "flat design didn't remove affordances, it removed signifiers, which is worse because the interaction is now invisible" — is a stronger interview answer than a vague "flat design looks nice but is less usable."

The fix isn't reverting to heavy skeuomorphism — it's ensuring some signifier survives simplification: a subtle color shift, consistent placement convention, or a hover/press state that at least confirms interactivity once touched, even if the resting state is minimal.

Norman's other classic example — the "Norman door." A door with a flat metal plate affords pushing (there's nothing to grip and pull), but many such doors are labeled "Pull" anyway because the design's own signifiers contradict the affordance — the flat plate signifies "push here," while a printed sign has to override that signal with text. The digital equivalent is a UI element whose shape or styling signifies one behavior (a toggle switch that looks like it should slide) while its actual behavior does something else (it opens a modal instead of toggling instantly). Whenever a design needs an explanatory label to compensate for a misleading signifier, that's a strong sign the signifier itself is wrong, not that the label needs to work harder.

A quick diagnostic for a signifier-affordance mismatch in review: cover the label text of an interactive element and ask "would a first-time user still guess this is interactive, and guess correctly what it does?" If the answer only becomes yes once the label is visible, the element is relying entirely on text to do a signifier's job — which fails the moment a user is scanning quickly, has the label truncated on a small screen, or is using a screen reader that reaches the element out of visual context.

Feedback Loops and System Status

This section is the direct, practical extension of heuristic #1 (visibility of system status): every user action needs a perceivable response. A button press needs a visible state change (pressed styling, a ripple, a disabled state while processing). A form submission needs a loading indicator. A background process (an export, a sync) needs a completion signal the user will actually see, not just a log entry.

The specific failure mode: the "dead click." A dead click happens when a user performs an action — taps a button, submits a form — and nothing perceivable happens in response. The system may actually be processing correctly in the background, but from the user's point of view there's no way to distinguish "it's working" from "it didn't register" from "it's broken." The predictable consequences:

1. The user doesn't know whether the action succeeded, so they can't proceed with confidence.
2. The user often repeats the action — clicking submit again, tapping the button harder or multiple times — which can trigger a duplicate submission (a double-charged payment, a duplicate form entry, a duplicate API call), turning a missing-feedback problem into a data-integrity problem.
3. Trust erodes faster than a single bad interaction would suggest, because the user has no information to distinguish "slow" from "broken," and defaults to assuming the worst.

The fix is cheap relative to the cost of the failure: disable the button and show a spinner immediately on press (even before the network call resolves), and always resolve to an explicit success or error state — never leave the UI in an ambiguous, unchanged-looking state after an action was taken.

Matching feedback latency to action weight. Not every action needs the same kind of feedback — the right response scales with how long the underlying operation takes and how consequential it is:

Getting the category wrong is its own failure mode distinct from the dead click: an indefinite spinner on a ten-second operation with no percentage or explanation produces the same "is this broken?" uncertainty as no feedback at all, just delayed by a few seconds before the doubt sets in.

Error Prevention vs. Error Recovery

Nielsen's heuristic #5 (error prevention) implies a hierarchy that's worth stating explicitly, because it's a strong structural answer to "how would you handle errors in this flow":

1. Prevent the error from being possible at all — the strongest option. Use constraints: disable a submit button until required fields are valid, use a date picker instead of a free-text date field so an invalid date literally cannot be entered, restrict a numeric field to numeric input.
2. Catch the error immediately and explain it clearly — the fallback when prevention isn't feasible. Inline validation as the user types or on field blur, with a specific, actionable message ("Password needs at least one number") rather than a generic one ("Invalid input").
3. No error handling — the failure mode. The user submits something invalid, gets a generic failure with no explanation, and has to guess what went wrong — the worst outcome, and one that compounds with the "dead click" problem above if the failure isn't even clearly communicated.

Worked example — a date-of-birth field:

• Prevention (best): a date picker component that only allows selecting valid calendar dates, with the future disabled if the field requires a past date (e.g., date of birth can't be tomorrow). An invalid date is never representable in the first place.
• Recovery (acceptable fallback): a free-text date field that accepts "02/30/2026," lets the user submit, and only then shows "February doesn't have 30 days" — functionally correct, but it cost the user a submit-and-fail round trip that prevention would have avoided entirely.
• No handling (failure): the same free-text field silently accepts "02/30/2026," stores it, and the invalid date surfaces as a downstream bug somewhere else in the system, days later, disconnected from the moment the user entered it — the most expensive version of the same root cause, because it's no longer even visible to the person who could have prevented it.

The interview-relevant framing: when asked to critique a form or flow, checking which tier of this hierarchy each field sits at — and proposing a move up a tier, not just a better error message — is a noticeably stronger answer than only polishing the wording of an error state.

This hierarchy isn't infinitely applicable — know its limit. Some failures genuinely can't be prevented client-side (a card declined by a bank for reasons the client has no visibility into, a username that's already taken and only discoverable by asking the server). For those, tier 2 — a fast, specific, actionable message — is the realistic ceiling, not a failure to reach tier 1. The interview-relevant skill isn't reflexively answering "prevent it" for every case; it's correctly sorting which failures are preventable client-side and which aren't, and applying the right tier to each.

Quick Reference: Naming the Principle Under a UI Critique

Interviewers reward precision over vibes. This table maps the symptom you'll see in a screenshot to the principle that names it — useful as a fast lookup when practicing critiques out loud:

Committing this table's logic (not the exact wording) to memory is what lets you produce a fast, named diagnosis on the spot rather than a slow, generic "this feels off" when handed an unfamiliar screenshot mid-interview.