UX/UI and product design fundamentals

UX is the decision about what the product does and in what order a person does it; UI is the decision about what that looks like and how it responds to touch. The reason the distinction matters practically is that they fail differently and are fixed by different people. A beautiful screen that asks for information the user does not have is a UX failure, and no amount of restyling repairs it. A well-sequenced flow rendered with unreadable contrast and inconsistent spacing is a UI failure, and it is repairable in an afternoon. Interviewers ask this because candidates who conflate the two tend to describe visual work when asked about outcomes.

How content and functions are organised, labelled and related, independent of how any screen looks. It is the answer to where a thing lives, what it is called, and what sits alongside it. The reason it is a separate discipline from screen design is that navigation problems are almost never solvable at the screen level: if a user cannot form a mental model of the categories, a better menu component does not help. The cost of getting it wrong compounds, because URLs, search, analytics event names and the sitemap all encode the structure, so a late reorganisation is a migration rather than a redesign.

To make structural argument cheap. A wireframe deliberately strips colour, imagery and finished typography so the conversation is about what is on the screen, its priority and its sequence, rather than about whether the blue is right. That constraint is the whole value: stakeholders reviewing a polished mock discuss the polish. The cost is that a wireframe cannot answer anything about feel, timing or perceived performance, so it is the wrong artefact for a gesture-heavy interaction. Teams that have good component libraries increasingly skip wireframes for routine screens and reserve them for genuinely novel structure.

A segment is a group defined by attributes you can query — plan tier, region, tenure — so it is measurable and shows up in your analytics. A persona is a narrative composite standing in for a behaviour pattern, with goals, context and constraints attached, and it exists to make design trade-offs arguable in a room. The failure mode is a persona built from imagination rather than research, which becomes a device for laundering the team's assumptions into a document with a stock photograph on it. A persona should be traceable to interviews you can name.

A flow diagram shows the states a user can be in and the transitions between them, which is a description of your product. A journey map shows the whole arc of getting something done, including the parts that happen outside your product — the email they were reading, the phone call to support, the two-day wait for an approval — with what the person is trying to achieve and how frustrated they are at each stage. That off-product context is where most of the real improvement sits, and it is invisible to a flow diagram because your system never observed it.

An affordance is what an object makes possible: a surface affords pressing whether or not it looks pressable. A signifier is the perceptible cue that tells a person the affordance is there — the shadow, the underline, the label. Software gets this wrong in one specific direction: flat visual styles removed signifiers while keeping affordances, so elements remained clickable but stopped looking clickable. Keeping the words distinct lets you diagnose precisely, because "they did not know they could tap it" and "they tapped it and nothing happened" are different bugs with different fixes.

Naming them in sequence is the fastest way to show you have worked on a real product rather than read about the process.

artefact              answers                          who consumes it
--------------------  -------------------------------  ---------------------
research findings     what problem, for whom           PM, design, leadership
journey map           where the pain sits, end to end  PM, support, design
IA / sitemap          where things live, what they are engineering, SEO, content
user flow             which states and transitions     engineering, QA
wireframe             what is on the screen, priority  stakeholders, PM
high-fidelity design  exact appearance and states      engineering
prototype             feel, timing, sequencing         research participants
spec / redlines       tokens, breakpoints, edge states engineering, QA
usability findings    what broke when people used it   whole team

Read the right-hand column rather than the left, because the interview question underneath this is who the artefact is for. An artefact with no consumer is process theatre, and the most commonly produced example is a fully redlined static design handed to a team that already has the component library the design was drawn from.

The second thing to notice is that the list is not a waterfall even though it reads as one. Research findings and usability findings are the same activity at two points in the loop, and the interesting version of this answer says which artefacts you skip on a small change. A copy change needs none of them; a new onboarding flow needs most.

The artefact candidates most often omit is the spec, and it is the one engineering actually needs. A high-fidelity design shows one state at one width. The spec says what happens at 360px, what the disabled state looks like, which token the border uses, what the field does with a 200-character input, and what appears while the request is in flight. Everything omitted there gets decided by an engineer at speed, which is how a consistent design becomes an inconsistent product.

It is the whole apparatus that makes repeated interface decisions once: the design language and its principles, tokens, a component library implemented in code, usage documentation, contribution and governance rules, and the people who maintain it. It is not a Figma file, and it is not a package on your registry — those are two of its outputs. The distinction has a practical consequence, which is that a design system without documented governance and a funded team degrades predictably: the code drifts from the design source, the version everyone pins becomes old, and teams reimplement components locally because that is faster than waiting.

A component library is the coded implementation: buttons, inputs, dialogs, with props and tests. A design system is that plus the reasoning — when to use which component, what the tokens mean, what a valid new addition looks like, and who decides. You can have a library without a system, and it is a recognisable state: forty components, no guidance on which of the three card variants applies, and every team choosing differently. The consequence is visual consistency without behavioural consistency, which users experience as a product that looks like one thing and behaves like several.

Almost always funding and staffing rather than technology. The build is exciting and gets resourced, the adoption push happens, and then the team is reassigned to product work. The library falls behind the framework version everyone else moved to, upgrades start costing consumers a day of visual regression triage, and at that point forking is the rational choice for a product team with a deadline. The second cause is a governance model that gates instead of enabling: a review council meeting fortnightly becomes the bottleneck, and the observable result is more local components rather than fewer.

A component that implements behaviour and accessibility without appearance: keyboard interaction, focus management, ARIA roles and states, and the open-close logic, with the styling left entirely to you. The reason this layering exists is that the hard, easily-got-wrong part of a combobox or a dialog is the behaviour, and the part that must differ between brands is the appearance. Splitting them lets one team maintain the difficult logic while several visual languages sit on top. The cost is a second layer to learn and document, and the risk that each product's styled layer diverges anyway if nobody owns the one on top.

The state list is where a design is judged complete, and most reviews find the gaps here rather than in the default appearance.

state         who triggers it     commonly missing
------------  ------------------  ---------------------------------------
default       -                   -
hover         pointer             ignored on touch, so never the only cue
focus-visible keyboard            removed by a CSS reset and not restored
active        press               too subtle to confirm the tap landed
disabled      app logic           contrast drops below readable
loading       in-flight request   layout shifts when the label swaps
error         validation          message placement not specified
empty         no data yet         designed as a blank area

The right-hand column is the answer to "what do you look for in a design review". Two of these are worth saying unprompted. Focus-visible is the one that breaks accessibility outright, because a keyboard user who cannot see where they are cannot use the screen at all, and it disappears silently the moment someone removes an outline they thought was ugly. Hover-only cues are the mobile equivalent: a signifier that exists only on a device that has no pointer.

Loading and empty are where the design and the implementation diverge most. A loading state that swaps a label for a spinner changes the button's width and moves everything after it, so the specification has to say the size is held. An empty state drawn as blank space is the one users hit on day one, before they have created anything, and it is the cheapest place in the product to teach them what to do next.

Disabled is the quiet accessibility failure. Designers grey it down until it reads as inert, which frequently takes the text below a readable contrast, and the control is often unreachable by keyboard as well, so a user cannot even inspect why they are blocked. Where you can, prefer an enabled control that explains the problem on activation.

Every prop is a contract you will be asked to keep, and removing one is a breaking change for consumers you cannot see. That makes the initial surface a long-lived decision rather than a convenience. The rule that survives is to expose closed sets — a variant enum whose members the design language defines — plus slots that take content while the component keeps appearance, and to resist props that encode one screen's taste. Boolean flags are the specific decay pattern: six of them are sixty-four combinations, most never rendered, several contradictory, and all of them nominally supported.

The same requirement, modelled twice, with different consequences a year later.

// Options grow: four props, and the combinations multiply.
<Button iconName="spinner" iconPosition="left" iconSize="sm" iconColour="muted" />

// A slot: the caller owns the content, the component owns the appearance.
<Button>
  <Spinner />   {/* sizing and colour inherit from the button's own tokens */}
  Saving
</Button>

The first version puts you in the icon business. You now maintain a name registry, a position enum, a size scale that must stay in step with the button's own sizes, and a colour prop that can be set to something the design language does not sanction. The test matrix is the product of all four, and nobody will ever render most of it, but every combination is nominally supported and someone will find the broken one.

The second version moves the variation to children. The button keeps the decisions that belong to it — padding, alignment, gap, how the content is coloured — and stops having an opinion about what the content is. Adding a badge next year requires no change to the button at all, which is the property you are buying.

The cost is real and worth stating. A slot lets a caller put something in that the design never anticipated, including something that breaks the layout, and it makes the component's rendered output less predictable in snapshot tests. You buy that back by constraining the slot's container rather than its contents: fix the gap, the alignment and the maximum height in the component, so whatever arrives is composed consistently even if it is unexpected.

Semantically, with the unusual addition that a purely visual change is a consumer-visible change even though nothing fails to compile. That means a changed appearance ships as at least a minor release, with the visual delta in the changelog and screenshots attached, so a consumer can decide whether to take it now. Removals and renames get a deprecation period in which the old name still works and warns. The release cadence matters as much as the numbering: if upgrading costs a consumer a day, they will batch upgrades into a yearly ordeal, and your adoption number quietly becomes a fiction.

A named binding of a design decision — a colour, a spacing step, a radius, a duration, a font size — that consumers reference by name rather than by value. The indirection is the point: the value has one definition, so a retheme is a data change rather than a code change, and the same source can be compiled into CSS custom properties, native resources and design-tool variables so web, iOS and Android inherit the same decision. The cost is that a value change ships silently into every consumer at whatever version each one is pinned to, and nothing in any build will tell you it happened.

The middle tier is the one that gets skipped, and it is the one that makes a rebrand possible.

{
  "color": {
    "blue": { "50": { "$value": "#1a73e8", "$type": "color" } },
    "text": {
      "link": { "$value": "{color.blue.50}", "$type": "color" }
    }
  },
  "space": { "4": { "$value": "16px", "$type": "dimension" } }
}

The primitive tier is a palette named after what a value is: color.blue.50. The semantic tier names what it is for: color.text.link. The component tier, where it exists, lets one component be retargeted without touching semantics shared across the product. Application code should reference the semantic tier only. The $value and $type keys and the {curly.reference} alias syntax come from the Design Tokens Community Group format, which most token build pipelines now read or emit.

Skip the semantic tier and every usage in the codebase says color.blue.50. That reads fine until the brand changes, at which point you cannot distinguish the four hundred places that meant "a link" from the ones that meant "our blue", and you are grepping hex values again — the exact problem tokens were introduced to remove.

There is a naming discipline underneath this that is worth stating. A semantic token is named for its role, never for its appearance: color.background.danger, not color.background.red. The moment a semantic name contains a colour word, the rename is coming, because the day danger becomes orange the name becomes a lie that still compiles.

You rebind the semantic tier and leave every component untouched. color.background.surface points at a near-white primitive in the light theme and a near-black one in the dark theme, and a button that references the semantic name is correct in both without knowing which is active. What does not survive the switch automatically is anything encoding an assumption about lightness: shadows read as dirt on a dark surface and usually need to become lighter borders, images with baked-in white backgrounds float, and a palette that had adequate contrast at one end can lose it at the other, so pairings must be checked in both themes rather than one.

A small closed set of steps — often a 4px base with steps at 4, 8, 12, 16, 24, 32 — that every margin, padding and gap must come from. The benefit is not tidiness, it is that vertical rhythm becomes a property of the system rather than of whoever built the screen, so unrelated screens look related. The second benefit is reviewability: a value outside the scale is visible in a diff and can be questioned. Allow arbitrary pixel values and you get eleven near-identical gaps, none of them wrong individually, which together read as sloppiness nobody can point at.

Keep one semantic name and resolve the value per platform in the build, rather than creating space.4.web and space.4.ios. Platform divergence is legitimate in specific places: minimum touch target sizes differ by platform convention, native type scales respond to the operating system's own text-size setting, and motion durations often follow platform norms. Encoding the divergence in the name pushes the decision into every consumer's code, where it will be applied inconsistently. Encoding it in the build keeps the design intent single and the output correct, at the cost of a build configuration someone has to understand.

A closed set of styles, each bundling family, size, weight, line height and letter spacing, named by role rather than by size — body, body-strong, heading-m, caption — because a role survives a decision to make headings smaller and a name like text-18 does not. Line height belongs in the token rather than being set per screen, since it is the main determinant of how a block of text reads and it is the property most often forgotten. The scale should be short enough that the choice is obvious; a system offering nine heading sizes will be used inconsistently, and the inconsistency is invisible until two screens sit side by side.

The pipeline is what makes tokens more than a naming convention, and the interesting part is what happens after the outputs are published.

flowchart TD
    A["Token source of truth"] --> B["Transform and build"]
    B --> C["CSS custom properties"]
    B --> D["Android and iOS resources"]
    B --> E["Design tool variables"]
    C --> F["Web app on v4"]
    C --> G["Admin app on v2"]
    D --> H["Mobile app on v3"]

Follow the versions at the bottom rather than the transforms in the middle. One source of truth produces three consumers sitting on three different releases, and every one of them is showing the company's brand to a user right now. Nobody looking at a single repository can see that divergence, which is why a rebrand takes as long as the slowest consumer's upgrade cadence rather than as long as the token change.

The design-tool branch matters more than it looks. If the tokens in the design tool are maintained by hand alongside the ones in the pipeline, they will diverge, and then designers and engineers are working from different values while both believe they are aligned. Generating that binding from the same source removes an entire category of hand-off argument.

The mitigations for the version spread are dull and they work: publish the visual delta with each release so a consumer can judge the risk, assert contrast pairings as tests inside the token repository so a bad pairing fails at the source, keep an inventory of who is on which version, and ship renames as aliases that keep the old name working for a release or two. A rename is the one token change a build can catch, which makes it far safer than editing a value in place.

They are three conformance levels, each adding requirements to the one below. AA is the level nearly everyone targets, because it is the one public-sector procurement rules and most accessibility legislation reference, and because AAA includes requirements that are impractical across a whole product rather than a specific component. Saying "we are WCAG compliant" without a level and a version is the tell of someone repeating a phrase, since conformance is claimed against a specific version at a specific level for a specific set of pages. Treat AA as the floor for anything user-facing and be explicit about which content is out of scope.

The numbers are short, and the interesting part is which pairings people forget to check.

content                                  AA minimum
---------------------------------------  -----------
normal-size text against its background  4.5:1
large text                               3:1
icons and UI component boundaries        3:1

commonly unchecked pairings
  disabled text on a disabled background
  placeholder text inside an input
  white text on a brand colour chosen for the brand's sake
  text over an image or gradient, at its lightest point
  the same pairing again in the other theme

Contrast is a property of a pair, not of a colour, which is why a token change reviewed on its own can break it. Darken a surface token for aesthetic reasons and any foreground token that was sitting near the line goes under, in components nobody opened during review.

The list of unchecked pairings is where audits actually find failures. Disabled states are greyed until they read as inert, which is usually well below the threshold. Placeholder text is styled light because it is meant to recede, and it is often the only label present. Brand colours are chosen by marketing against a white background and then used behind white text, which frequently fails.

The practical control is to assert pairings as tests where the tokens live, so the failure appears in the design system's pipeline rather than in a product's audit six months later. Checking one colour tells you nothing; checking every sanctioned pairing in both themes is a finite list and can be automated.

A native element brings its role, its keyboard behaviour, its focus handling and its state reporting for free, all of it already correct in the assistive technologies people actually use. A div with a click handler brings none of that, and reconstructing it takes a role, a tabindex, key handlers for Enter and Space, and state attributes you must keep in sync. ARIA adds semantics where no native element expresses the pattern — a tablist, a combobox, a live region — but it changes only how the element is described, never how it behaves. That asymmetry is why the guidance is to reach for the native element first and treat ARIA as the exception.

Constraining keyboard focus to a container so Tab cycles within it rather than escaping to the page behind. A modal dialog needs one, because a sighted keyboard user whose focus has wandered behind an overlay is interacting with content they cannot see. Doing it properly means more than intercepting Tab: focus must move into the dialog when it opens, land somewhere sensible rather than on the close button by default, return to the element that opened the dialog when it closes, and Escape must dismiss. The return is the step most implementations miss, and it is the one that determines whether a keyboard user loses their place.

Because it takes two minutes, needs no tooling, and surfaces a disproportionate share of real failures. Put the mouse down and complete a task with Tab, Shift-Tab, Enter, Space and the arrow keys. You immediately find controls that cannot be reached, a focus indicator that was removed by a CSS reset, a tab order that jumps around because the DOM order does not match the visual order, a menu that opens but cannot be dismissed, and a dialog that leaks focus. None of that requires understanding a screen reader. It is not a substitute for testing with one, but it is the check with the best ratio of findings to effort.

The string an assistive technology announces for a control, computed from several sources in a defined order of precedence: an explicit ARIA label, then an associated element such as a label bound to an input, then the element's own content, then in some cases a title attribute. Two failures dominate. Icon-only buttons have no content and no label, so they announce as "button" and a user cannot tell save from delete. And a visible label that differs from the accessible name breaks voice control, because a user saying the words they can see does not match the name the control actually carries.

A live region tells assistive technology to announce changes to a container's content without moving focus, which is how you communicate something that happened away from where the user is working: a search result count updating, a save confirmation, a validation summary appearing. Without one, a sighted user sees the toast and a screen reader user gets silence. The failure mode in the other direction is worse than silence: a region marked as interrupting, or one wrapping frequently-changing content, produces constant announcements that make the page unusable, so the default should be the polite behaviour that waits for a pause.

Because a meaningful proportion of users cannot distinguish the specific pairs you chose, and because colour disappears in a printout, in bright sunlight and in a high-contrast mode. A red border on an invalid field, a green dot for healthy, a chart with six lines distinguished only by hue: each of these encodes information a user may not receive. The fix is redundant encoding rather than different colours, so add an icon, a text label, a pattern, or a direct label on the line. This is also the single most common finding in a first accessibility review, because status indicators are exactly where designers reach for colour first.

Generative research asks what problem exists and for whom, before there is a solution to react to; it produces a reframed understanding, and its methods are interviews, contextual observation and diary studies. Evaluative research asks whether a specific solution works, and its methods are usability tests, comparative studies and instrumented experiments. The reason to keep them apart is that teams routinely run evaluative research and report it as generative: a usability test on the design you already built can tell you the labels confuse people, and cannot tell you whether anyone needed the feature.

The loop matters more than the individual method, because the common failure is research that arrives after the decision it was meant to inform.

flowchart TD
    A["Problem believed"] --> B["Generative research"]
    B --> C["Problem reframed"]
    C --> D["Design candidate"]
    D --> E["Evaluative test"]
    E -- "works" --> F["Build and instrument"]
    E -- "fails" --> D
    F --> G["Behaviour in production"]
    G --> B

The arrow to look at is the one from production back to generative research. Most teams draw the loop and never traverse that edge, so what shipped is never used to revise what they believe about the problem, and the next cycle starts from the same assumptions with a new feature attached.

The second thing in the diagram is that the failing branch returns to the design candidate rather than to the problem. That is correct most of the time and dangerous occasionally: if three consecutive design candidates fail the same way, the loop you need is the long one, because the problem framing is what is wrong rather than the interface.

The practical version of this in an interview answer is to say what you would do with two weeks rather than to name a method catalogue. Two weeks buys five interviews and a synthesis, or a prototype and five usability sessions, and choosing between those two is exactly the judgement being tested. Pick the one that addresses the risk that would kill the work soonest.

Fewer than people expect, and the arithmetic is worth carrying out once because it changes how you argue for research budget.

Assume each participant independently has probability p of hitting a
given problem. Probability that at least one of n participants finds it:

  1 - (1 - p)^n

p = 0.3   n = 1   30%
          n = 3   66%
          n = 5   83%
          n = 8   94%
          n = 12  98%

Under that model the returns flatten quickly, which is the basis for the widely used rule of thumb that five participants per round is enough for a qualitative usability study. Note what the model assumes: one homogeneous user group, independent discovery, and a single problem probability. None of those is exactly true.

The consequences of the assumptions are where a strong answer goes. If you have two genuinely different user types — an administrator and an end user — you need the sample in each, because a problem only administrators hit has a probability near zero for the others. If the problem is rare rather than common, a small sample will not find it, and no amount of qualitative testing substitutes for instrumentation. And this arithmetic says nothing about preference or magnitude: five people cannot tell you which of two designs converts better, only that both confused the same three people.

The stronger use of the number is to argue for more rounds rather than bigger ones. Three rounds of five, each on a revised design, finds and fixes more than one round of fifteen on a design that is already frozen.

Large, systematic and predictable in direction. People report intentions rather than behaviour, they rationalise choices after making them, they under-report anything socially awkward, and they will politely tell you a feature sounds useful. That is not dishonesty; it is that introspective access to your own behaviour is poor. The methodological consequence is to prefer observation and instrumentation for questions about behaviour and reserve self-report for questions about goals, context and mental models, where the person genuinely is the only source. Asking "would you use this?" is the canonical wasted question.

Almost every flawed test is flawed in the task wording rather than in the analysis.

bad   "Use the filter panel to find invoices from March that are unpaid,
       then export them as a CSV."

why   Names the mechanism, so you learn nothing about discoverability.
      Bundles three subtasks, so a failure cannot be located.
      Uses the product's own vocabulary, cueing the label to look for.

better "Your manager wants a list of everything a customer still owes you
        from last month, in a spreadsheet. Show me how you would get that."

why   States a goal, not a route. Uses the user's words. One outcome,
      so success and failure are unambiguous.

The rule underneath is that a task should specify the outcome and leave the path entirely open, because the path is the thing under test. The moment you say "use the filter panel", you have answered the only interesting question, which was whether they would find it.

Vocabulary is the subtler trap. Products name things in ways that make sense to the team, and repeating those words in a task turns a comprehension test into a matching exercise. Write tasks in the language your interview participants used, which is one of the more concrete reasons to do the generative work first.

The facilitation discipline is the other half. When a participant stalls, the instinct to help destroys the data, so the responses to rehearse are neutral: "what were you expecting to happen", "talk me through what you are looking at", "what would you do if I were not here". Silence for ten seconds is usually more productive than any question.

Whenever the question is why, or when the answer requires the respondent to predict their own behaviour. Surveys are good at measuring the distribution of something you already understand well enough to write closed questions about — which of these four things you use, how satisfied on a scale, how often — across a sample large enough for the proportions to mean something. They are bad at discovery, because you can only ask about what you already thought of, and the free-text box is not a substitute for a conversation. They also carry a selection bias that is easy to forget: the people who answer are the ones with the strongest feelings.

Why the losing variant lost, whether a metric moved for the reason you assume, and anything about a change too small or an audience too narrow to reach significance in a reasonable time. It also cannot tell you about long-run effects, since a variant that lifts a click rate this week may be doing so by degrading trust in a way that shows up in retention next quarter. The pairing that works is an experiment to establish whether the change moved the number, and qualitative work to explain the mechanism, because acting on the number alone means you cannot generalise the finding to the next decision.

They are the reason a layout communicates structure before anyone reads a word. Proximity is the strongest and most misused: elements close together are perceived as related, which is why a label sitting equidistant between two fields is genuinely ambiguous and why generous spacing between groups does more for comprehension than any border. Similarity groups by shared appearance, common region groups by an enclosing surface, and continuity makes the eye follow an alignment. The practical use is diagnostic — when a screen feels confusing and nothing is obviously wrong, the grouping is usually fighting the actual relationships in the data.

Size, weight, colour and contrast, position, and space, applied so that the order in which things are noticed matches the order in which they matter. The most common failure is not the absence of hierarchy but a flat one, where five elements all claim primary emphasis and therefore none does — three buttons of equal weight on a dialog, or a page where every heading is bold and large. The corrective is subtractive: reduce the emphasis on everything secondary rather than adding emphasis to the primary thing, because a screen where everything shouts is fixed by quietening, not by shouting louder.

It states that the time to move a pointer to a target depends on the distance to the target and its size, so bigger and nearer is faster. Its useful consequences are concrete: primary actions deserve larger hit areas, controls used together should sit together, small targets in a dense toolbar are slow and error-prone, and a screen edge or corner is effectively an infinitely deep target because the pointer cannot overshoot it. On touch devices the same reasoning produces minimum touch target sizes, and it also argues for placing destructive actions away from the ones next to them, since proximity makes a mis-tap likelier.

Because a spinner communicates only that something is happening, and after a second or two users cannot distinguish it from a hang. What reduces perceived wait is structure: a skeleton that shows the shape of what is coming makes the wait feel shorter and prevents the layout jump when content arrives, and progressive rendering of the parts that are ready beats an all-or-nothing reveal. Where the operation is genuinely long, determinate progress with a sense of what stage it is at is worth the implementation cost. Optimistic updates go further by removing the wait from the interface entirely, at the cost of having to design the reversal when the request fails.

Teaching, not apologising. It is the first screen a new user sees, before any data exists, so it is the highest-leverage place in the product to explain what the thing is for and offer the one action that gets them started. Three distinct situations get collapsed into one design and should not be: nothing exists yet, which needs onboarding; a filter or search matched nothing, which needs the filter shown and a way to clear it; and something failed, which needs an explanation and a retry. Designing a blank area with a grey illustration handles none of the three.

Error copy is the highest-density design work in a product, and it is usually written last by whoever was implementing the validation.

bad     "Error: invalid input."

better  "That card number is 15 digits. Card numbers are 16 digits, so
         check for a missing one."

bad     "Something went wrong. Please try again later."

better  "We could not reach the payment provider. Your card has not been
         charged. Try again, or we can email you when it is back."

Three properties separate the columns. The better version says what happened in the user's terms rather than the system's, it says what the state of the world now is — which is the sentence people actually need after a payment error — and it offers the next action rather than an instruction to wait.

The state-of-the-world sentence is the one candidates omit and the one users care about most. After a failed payment, the question is not what went wrong, it is whether they have been charged. After a failed save, it is whether the work is gone. An error message that resolves that ambiguity prevents most of the support contacts the error would otherwise generate.

Placement is part of the design rather than an implementation detail. A field error belongs next to the field, announced when focus leaves it rather than on every keystroke; a form-level error belongs at the top with focus moved to it, so a keyboard or screen reader user finds out at all. Blaming the user in the copy is the last thing to strip: "you entered an invalid date" and "that date is in the past, and bookings must be in future" describe the same event with different consequences for whether they try again.

Motion earns its place when it explains a spatial or causal relationship — where a panel came from, that an item moved rather than being replaced, that this action caused that change. It stops earning its place when it delays a response, and a transition long enough to notice on a screen used forty times a day becomes an irritant. There is also a specific harm: large, parallax or continuously looping motion can trigger nausea and dizziness for people with vestibular conditions. Browsers and operating systems expose a reduced-motion preference for exactly this reason, and honouring it means substituting a cross-fade or an instant change, not just shortening the duration.

Everything the static design does not show, because that is where the reinterpretation happens: which token each colour, space and radius comes from, behaviour at each breakpoint, every component state, validation and error copy with placement, empty and loading states, what happens to long content and unexpected input, and the keyboard and focus behaviour for anything interactive. What it does not need is a pixel measurement of something the component library already decides. Handoff quality is best judged by the number of questions engineering has to ask afterwards, and by how many of those get answered in a chat thread that nobody records back into the design.

A redline is a design annotated with exact measurements and values. Where a mature design system exists, most redlining is obsolete and actively harmful, because it re-specifies in pixels what the component and its tokens already determine, and the two will disagree the moment either changes. What replaces it is a reference: this is the standard input at medium size, this heading is the semantic heading style, this gap is the fourth step of the spacing scale. Redlines remain genuinely necessary for anything the system does not cover, which is usually novel layout, illustration and one-off marketing surfaces.

Because designs are drawn at a small number of widths and built for a continuum.

design provided       what engineering must decide
--------------------  ---------------------------------------------
1440 desktop mock     what happens between 1024 and 1440
375 mobile mock       what happens between 375 and 1024
                      whether the sidebar collapses or becomes a drawer
                      whether the table scrolls, stacks, or drops columns
                      which columns are droppable, and in what order
                      where a fixed max width stops the layout growing
                      what the layout does at 320 and at 2560

Two mocks describe two points and imply nothing about the space between them, so the questions in the right-hand column get answered by whoever is implementing at the time. That is how a coherent design becomes an inconsistent product, and the inconsistency shows up on exactly the widths nobody reviewed.

Tables are the specific case worth pre-agreeing, because there are three legitimate strategies and they have different consequences. Horizontal scroll keeps all data and hides it; stacking each row into a card keeps everything visible and destroys column comparison; dropping columns preserves scanning and loses data, so it needs a stated priority order and a way to see the rest.

The cheapest fix is not more mocks. It is a written rule per region — this column stack collapses below the medium breakpoint, this sidebar becomes a drawer, this table drops columns in this order — and one review of the built screen at a width nobody designed, which is where every unstated assumption becomes visible at once.

Not by overlaying a screenshot, which finds a one-pixel discrepancy and misses the important failures. Review the things the design could not show: tab through it with the keyboard and watch the focus indicator, resize it slowly through the whole range rather than jumping between breakpoints, paste an absurdly long string into every text field, throttle the network to see the loading state that normally flashes past, force each error, and view it in both themes. Then check that the values came from tokens rather than being matched by eye, because a screen that looks right with hard-coded values will drift at the next retheme.

Someone must, and the default of "whoever typed it" is what produces four words for the same concept on one screen. In organisations with content design the answer is that role; where there is not one, it usually lands with the designer, with legal and support having veto on specific classes of message. The reason to settle it explicitly is that interface copy carries more of the usability than the visual design does — labels, button verbs, empty states, and above all error messages — and it is the part most often filled in as placeholder text during implementation and never revisited before release.

Cut scope along the axis that preserves the intent rather than degrading everything uniformly. That means asking what the design is actually for and shipping the part that delivers it: the simplified interaction with correct copy and states beats the elaborate interaction with placeholder error handling. It also means the conversation happens when the constraint is discovered rather than at the end, because an engineer silently substituting a simpler pattern is how a design becomes something nobody chose. The version of this that goes badly is negotiating in the abstract; the version that works trades named items with their consequences stated in the other person's currency.

The path is worth being able to draw, because the interesting question is which step is missing in the organisation you are joining.

flowchart TD
    A["Design change agreed"] --> B{"Covered by the system?"}
    B -- yes --> C["Product code, existing components"]
    B -- no --> D["Design system change"]
    D --> E["Token or component release"]
    E --> F["Consumers upgrade"]
    C --> G["Review on real data"]
    F --> G
    G --> H["Ship"]

The branch to look at is the one through the design system, because it is the slow path and its length is a property of the organisation rather than of the change. A tweak that lives in product code ships this week; the same tweak expressed as a token change ships when the last consumer upgrades, which may be next quarter.

That asymmetry is why teams under pressure push changes into product code that belong in the system, and it is the mechanism by which a design system falls out of step with the product it is meant to describe. The counter-pressure is to make the system path fast rather than to police the product path.

The step most often missing entirely is the review on real data. A screen reviewed with the designer's sample content is a screen reviewed under the most favourable conditions it will ever see, and production content is longer, emptier, in more languages and occasionally absurd.

Decision-making, not craft. The work on the screen establishes a floor, and then every question is about why: why this structure rather than the obvious alternative, what you learned that changed the design, what you cut and on what basis, what you would do differently now. The failure mode is a narrated tour of screens with the outcome attributed to the team in the passive voice, so the reviewer cannot tell what you personally decided. Being specific about your own contribution, including the parts you got wrong and corrected, reads as more senior than a flawless account of a project that apparently had no disagreements in it.

Structure it before you rehearse it, because most case studies run out of time at exactly the point they were about to get interesting.

2 min   context: the business, the users, your role, the constraint
3 min   the problem, and the evidence it was the right problem
2 min   what you considered and rejected, with the reason
6 min   the design, walked through one core flow rather than every screen
3 min   what testing or launch showed, including what was wrong
2 min   what you would change now
2 min   buffer, because the interruptions are the good part

The allocation is the argument. Six minutes on the design is less than most candidates expect and more than enough, because a single flow shown end to end demonstrates more judgement than twelve screens shown for ten seconds each.

The two segments that get dropped under time pressure are the rejected alternatives and the honest outcome, and they are the two an interviewer is listening hardest for. An alternative you rejected with a stated reason proves there was a decision; a project with no negative finding reads either as unmeasured or as unexamined.

Plan to be interrupted. A twenty-minute slot that runs uninterrupted usually means the interviewer is not engaged, so build in the buffer and treat questions as the point rather than as a derailment. Knowing which screens you can skip mid-flight without losing the thread is the preparation that actually pays.

Whether you can look at an interface and produce specific, prioritised, defensible observations rather than preferences. A strong critique names who the user is and what they are trying to do first, because "the button should be blue" is unanswerable while "a first-time user cannot tell which of these three actions is primary, and here is why that matters at this step" is a finding. It also separates severity from ease of fix, and resists redesigning in the first minute. The common failure is aesthetic commentary, which tells the interviewer you evaluate interfaces by taste.

By having used it properly and being specific without being contemptuous. Pick two or three things, at least one of them structural rather than cosmetic, describe the user and the situation in which it costs them something, and say what you would need to know before committing to a change — because a candidate who redesigns a flow confidently without asking about the constraints behind it is displaying exactly the behaviour that makes designers hard to work with. Naming something you think is good and explaining why is worth doing too; it shows you can read intent rather than only find fault.

Process visible under pressure. The interviewer is watching whether you clarify the problem before drawing, whether you ask who the user is and what constraint applies, whether you generate more than one direction before committing, whether you say what you are trading away, and whether you can be interrupted and incorporate it. Arriving at a polished screen is not the objective and rushing to one is the usual mistake. Silence is the specific failure: a candidate thinking quietly for four minutes has given the interviewer nothing to grade, and narrating a half-formed idea scores better than presenting a finished one.

Directly, with the mechanism rather than the atmosphere. Say what you believed, what you shipped, what actually happened, when you knew, and what you changed as a result. The two things being assessed are whether you can see your own contribution to the failure, and whether the lesson you drew was specific enough to be transferable — "we should have validated demand before building" is a slogan, while "we tested usability and never tested whether anyone had the data the form asked for" is a lesson someone can apply. Attributing everything to a reorganisation or a stakeholder reads as unexamined.

The answer that lands has a before and an after in it, and the fastest way to rehearse one is to write the four columns out for a project you actually shipped.

belief held             evidence that broke it        change made              cost of changing late
----------------------  ----------------------------  ----------------------  ---------------------
users will read the     4 of 5 read "archive" as      renamed to "hide from   copy in 3 locales
inline explanation      "delete" and stopped          list", removed the      redone, release
                                                      explanation             slipped a week
the two-step confirm    instrumentation: 38% of       confirm removed for     undo path built,
prevents mistakes       abandons sat on step 2        low-risk case, undo     one extra endpoint
                                                      added instead
admins want the bulk    admins already export to      bulk editor deferred,   two weeks of design
editor most             a spreadsheet and re-import   import hardened         discarded

Read the fourth column, because that is the one candidates leave out and the one an interviewer uses to test whether the change really happened. A change with no cost attached usually means the design was still on a whiteboard, which is cheap and therefore proves little about your willingness to be wrong once something is built.

The second row is the most useful shape of answer, because the evidence and the change disagree with the original intent rather than refining it. Removing a safeguard because the data said it was costing more than it prevented, and replacing it with a different safeguard, is a decision. Reordering two fields is not.

Three substitutes get offered instead, and each is recognisable. Validation, where the test confirmed the design and nothing changed, which means either the session was a demonstration or the design was already frozen. Cosmetics, where the change was contrast or copy polish — real work, but it does not show that evidence can move a decision. And the passive voice, where "we iterated based on feedback" names a process and not one thing that is different because of it.

The third row is worth having ready too, because a finding that cancels work is harder to talk about and shows more. Naming what you had believed before, out loud, is what makes the rest of the account credible.