Design systems & UX foundations
Design systems and tokens, visual design language, coded component libraries, accessibility and UX research practice. Interviewers probe it when a role owns interface quality, not just markup.
on this pageshowhide
guide
overview
~2 minDesign systems and UX foundations is the subject interviewers reach for when a role owns how an interface looks, behaves and holds together, not only the markup behind it. The questions rarely stop at taste. They test whether you can turn a visual decision into something named and shared, whether a component you publish will survive dozens of teams using it in ways you did not plan, whether someone on a keyboard or a screen reader can operate what you built, and whether your design choices rest on evidence about users rather than on the loudest opinion in the room. The hub splits into seven sections. [Design systems](/topics/found-design-systems) treats shared UI as a product: tokens, theming, component standards, documentation, governance and keeping design files and code in step. [Design language](/topics/found-design-language) covers the visual foundations every component draws on: type, color, spacing, icons, motion, elevation and brand voice. [Atomic design](/topics/found-atomic-design) is a vocabulary for deciding where one component ends and the next begins. The [component library](/topics/found-component-library) is the coded side: public API, composition, theme hooks, testing, versioning and packaging. [Accessibility](/topics/found-accessibility) covers conformance, names and roles, keyboard use, contrast and auditing. [UX design](/topics/found-ux-design) covers research, journeys, information architecture, prototyping and usability testing. [Standard UI components](/topics/found-core-components) walks the families nearly every system ships first, from buttons and text fields to dialogs, toasts and loading indicators. Start with what a design system is and what it is made of, then the design language and the token model that encodes it, because every later section refers to both. Learn accessibility before the component families, since each family's rules are largely accessibility rules. The component library and governance material comes next, once you know what is being packaged and versioned. Questions run from a junior asked to tell a button from a link to a principal asked how a system stays adopted as products and teams diverge; the same idea tends to reappear at several levels, so return to a section as your level rises.
primer
A few ideas run under every section. Once they are clear, most questions below read as applications of them rather than separate facts. - **Name the decision, not the value.** A token, a text style or a color role is useful because its name says what the value is *for*. A name that restates the value stops being true the day the value changes, and it ties together things that only happened to look alike. Interviewers use naming questions to see whether you think of a style as a decision someone made or as a number someone typed. - **Indirection is where change becomes cheap.** Layers of aliases between raw values and the components that use them let a rebrand, a dark mode, a density setting or a second brand happen by re-pointing names instead of editing every component. Each layer also costs something: another hop to trace when a color looks wrong, and more names to learn. Expect to defend how many layers you would have and why. - **A shared component is a public contract.** Once other teams consume it, everything they can observe is part of its interface: property names, defaults, the variants on offer, focus behaviour, the accessible name it produces, when it emits events. Changing any of these can break a consumer who never touched a renamed property. Senior questions here are about versioning, deprecation and how you would know who depends on what. - **Semantics follow behaviour.** Whether a control navigates or acts, whether a dialog blocks the page or sits beside it, whether a message is transient or persistent: these choices decide what users and assistive technology expect to happen. Picking by appearance is a common junior mistake. - **Accessibility is a property of structure.** What a screen reader announces, the order keyboard focus travels, and what an automated checker can see all come from the structure underneath the pixels. Designing it in (required labels, sensible source order, sufficient contrast, cues that do not rely on color alone) is usually far cheaper than retrofitting it after an audit. - **Boundaries need a test you can say out loud.** Atomic levels, headless versus styled components, what a composite exposes and what it fixes: each is a judgement about where one piece ends. Interviewers care less about the right label than about whether you can state the rule you applied and apply it consistently. - **Evidence about users outranks opinion.** Research methods are chosen by the question being asked (why people do something, or how many do it), and a study can be ruined by how it is worded. Engineers are asked about this to see whether they reason about users, not only tickets. - **A design system is a product with users.** Its users are product teams. It succeeds when they adopt it, which depends on documentation, a predictable release process, a way to contribute and a quality bar they can trust.
- Design system
- A shared set of design language, tokens, coded components, patterns, guidance and governance, maintained as a product so that separately built screens behave and read as one.
- Design token
- A named design decision, such as a color, size or duration, stored in a platform-neutral form so design tools and every codebase read the same value.
- Primitive token
- A token holding a raw option from the palette or scale, with no meaning attached; the bottom layer that semantic tokens point at.
- Semantic token
- A token named for the role a value plays, such as a surface or an error signal, which themes and modes can re-point without components changing.
- Theme
- A complete mapping from semantic names to concrete values. Brands, light and dark modes and density settings are usually expressed as alternative mappings.
- Variant
- A named, mutually exclusive visual or behavioural option a component offers, such as its emphasis level, chosen from a fixed list rather than composed from flags.
- Headless component
- A component that provides state, keyboard handling, focus management and accessibility semantics but no styling, leaving the look to the consumer.
- Atomic design
- A method that describes interfaces as five nested levels (atoms, molecules, organisms, templates and pages) to reason about how parts compose into screens.
- Assistive technology
- Software or hardware that mediates between a person and an interface, such as screen readers, screen magnifiers, switch devices and voice control.
- Accessibility tree
- The structure a platform derives from an interface and exposes to assistive technology, describing each element by role, name, value and state.
- Accessible name
- The text assistive technology uses to identify a control. It can come from visible content, an associated label or an explicit attribute.
- Focus order
- The sequence in which keyboard focus moves through interactive elements, determined by the underlying structure rather than by the visual layout.
- Contrast ratio
- A measure of the luminance difference between two colors, from 1:1 to 21:1, used by WCAG to set minimum legibility thresholds for text and interface parts.
- Conformance level
- One of WCAG's three grades, A, AA and AAA; each criterion carries one, and a claim at a level includes every level below it.
- Signifier
- A perceivable cue, such as an underline, border or icon, that tells a person an action exists and where to perform it.
- Breaking change
- Any change to a shared component that can make existing consumer code fail or behave differently, which under semantic versioning requires a major release.
The sections form a stack: foundations at the bottom, packaged parts in the middle, the practices that judge the result around the outside. **Design language is the source; tokens are how it travels.** Typography, color, spacing and motion begin as decisions made by designers. [Design tokens](/topics/found-design-systems-tokens) encode those decisions with names that design tools and every codebase can share, and [theming](/topics/found-design-systems-theming) swaps whole sets of values behind the same names. A question about dark mode, density or a second brand is usually a question about this layer, even when it is phrased as one about a component. **Components consume tokens and expose a contract.** The [component library](/topics/found-component-library) is where tokens become buttons, fields and dialogs with a public API. Its questions about variants, composition, packaging and versioning only make sense once you see a component as something many teams depend on. [Atomic design](/topics/found-atomic-design) supplies the vocabulary for how small parts compose into larger ones, and the [standard UI components](/topics/found-core-components) section gives each common family its anatomy, states and behaviour rules. **Accessibility cuts across every layer.** Contrast is a token and design-language concern; accessible names, roles and keyboard behaviour are component concerns; focus order and landmark structure are page concerns. The [accessibility](/topics/found-accessibility) section states the requirements, and the component sections show where each one is enforced so product teams inherit it rather than reimplementing it. **UX design decides what should be built at all.** [User research](/topics/found-ux-design-user-research), journey mapping and information architecture come before any component is chosen, and [usability testing](/topics/found-ux-design-usability-testing) checks the result. The interaction principles in that section, such as feedback and signifiers, reappear as rules in the component families. **The design system wraps all of it as a product.** [Governance](/topics/found-design-systems-governance), [documentation](/topics/found-design-systems-documentation) and [handoff between design and code](/topics/found-design-systems-design-to-code) are what keep the layers above consistent as more teams adopt them. Senior questions tend to live here, because the hard problems are adoption, versioning and keeping design files and shipped code from drifting apart.
- Purpose & Parts →
Fixes the vocabulary first: what a design system contains, how it differs from a library or a style guide, and why it is run as a product.
- Design Language →
Type, color, spacing and motion are the decisions everything else encodes, so learn what they are before learning how to store them.
- Design Tokens →
The token tiers and naming rules explain theming, handoff and most component styling questions that follow.
- Accessibility →
Names, roles, keyboard operation and contrast are the rules behind most component-family requirements; learn them before the families.
- Standard UI Components →
Applies the foundations and accessibility rules to concrete families: when to use each control and what states it must handle.
- Component Library →
Turns components into a shared codebase: API design, composition, testing and versioning, where engineering interviews probe hardest.
Naming a token or text style after its value, so the name lies after the first rebrand or forces a rename in every consumer.
Hardcoding a raw color or size inside a shared component, which quietly opts that component out of every theme and mode.
Choosing a button or a link by how it should look rather than by whether it acts or navigates.
Treating an automated accessibility scan that passes as proof of conformance; many criteria turn on meaning and order and need a person to judge them.
Using placeholder text as a field's only label, or color as the only signal of an error or a status.
Calling a release non-breaking because no property was renamed, when a default, a focus behaviour or an accessible name changed.
Adding one more boolean style flag per request until a component accepts combinations nobody designed.
Arguing over whether something is an atom or a molecule instead of stating the boundary rule and applying it consistently.
Writing usability tasks that use the interface's own labels, so participants match words instead of finding the path.
Presenting a persona or journey map that no research finding supports, then using it to settle a design argument.
Measuring a design system's success by components shipped rather than by adoption, parity with design files and consumer trust.
The same handful of choices comes up across nearly every section. Naming the one in front of you, and what would change your answer, is most of a strong response. - **Consistency versus local fit.** A shared component or rule makes screens agree and saves repeated work; a product with unusual needs pays for it in workarounds. The usual resolution is an escape hatch that is documented and tracked, not forbidden and not free. - **Flexibility versus a narrow API.** Every extra property, slot or override lets more teams use a component and makes its behaviour harder to guarantee and harder to change later. Headless building blocks sit at the flexible end; opinionated styled components sit at the constrained end. - **More token layers versus traceability.** Each alias layer makes a class of change cheaper and makes one wrong color slower to trace. Size the layers to the changes you actually expect: modes, brands, density. - **Moving fast versus not breaking consumers.** Fixing a flawed API immediately helps new users and breaks existing ones. Deprecation periods, migration notes and automated upgrade tooling trade release speed for consumer trust. - **Research depth versus speed.** Moderated sessions and interviews explain why something fails; unmoderated tests and analytics are faster and larger but say less about cause. The question you need answered decides the method. - **Motion and density versus accessibility.** Animation and tighter layouts can aid comprehension or fit more on screen, but both have limits set by reduced-motion preferences, target sizes and legibility that a system should enforce centrally.
Several shapes recur under different names across the sections; spotting them places an unfamiliar question quickly. - **Separate the role from the value.** Semantic tokens, named text styles, functional color roles and theme mappings all put a stable name between a consumer and a value that is expected to change. - **Encode the rule once, centrally.** Contrast checked at the token level, required accessible names enforced by a component's API, spacing drawn from a fixed scale: the system carries the rule so each product team does not have to remember it. - **Pick the component by intent and lifetime.** Button or link, modal or non-modal, toast, banner or inline alert, spinner, skeleton or progress bar: each family's choice turns on what the user is doing and how long the thing should last. - **Make invalid states unrepresentable.** Enum variants instead of combinable flags, required props for labels, composites that fix the relationships between their parts: design the API so misuse cannot be expressed. - **Treat observable behaviour as the contract.** Versioning, testing layers and deprecation policy all start from the same question: what can a consumer see or rely on? - **Discover first, then measure.** Qualitative research and open card sorts find the problem and the user's vocabulary; quantitative methods and closed sorts check how widespread it is or whether a proposed structure holds.
explore
- Design Systems128 questions
- Purpose & Parts11 questions
- Launch Planning12 questions
- Design Tokens22 questions
- Theming Strategy18 questions
- Component Standards12 questions
- Documentation & Guidance12 questions
- Governance & Operations25 questions
- Handoff & Implementation Sync16 questions
- Design Language120 questions
- Brand & Voice20 questions
- Color Systems20 questions
- Typography20 questions
- Spacing & Layout18 questions
- Elevation & Shape5 questions
- Iconography24 questions
- Motion & Animation13 questions
- Atomic Design24 questions
- Standard UI Components53 questions
- Buttons & Actions5 questions
- Text Fields4 questions
- Checkboxes, Radios & Switches4 questions
- Selects & Comboboxes4 questions
- Form Patterns5 questions
- Dialogs & Modals5 questions
- Tooltips & Popovers4 questions
- Toasts, Banners & Alerts4 questions
- Loading Indicators5 questions
- Tabs & Carousels5 questions
- Cards & Lists4 questions
- Avatars & Badges4 questions
- Component Library43 questions
- Props & Variants API4 questions
- Headless & Compound Patterns4 questions
- Theme Consumption & Overrides4 questions
- Accessibility Integration4 questions
- Workshop & Example Catalog4 questions
- Versioning & Breaking Changes4 questions
- Test Strategy Layers4 questions
- Package Layout & Formats5 questions
- Cross-Framework Delivery5 questions
- Right-to-Left & Locale Hooks5 questions
- Accessibility24 questions
- WCAG Conformance5 questions
- Roles, Names & States3 questions
- Keyboard Operability3 questions
- Screen Reader Compatibility4 questions
- Contrast & Visual Cues4 questions
- Testing & Audits5 questions
- UX Design31 questions
- User Research Methods5 questions
- Personas & Journey Maps5 questions
- Information Architecture5 questions
- Wireframing & Prototyping5 questions
- Usability Testing6 questions
- Interaction Principles5 questions
questions
423 · 7 sectionsHow does a design system differ from a component library, a style guide, a pattern library and a UI kit?
basics
~20 sA design system bundles design language, tokens, coded components, patterns, usage guidance and governance, run as a product. A component library is its coded parts; a style guide documents rules; a pattern library catalogues reusable solutions; a UI kit is design-file assets.
In a design-system handoff, why should the spec name the system components and tokens it uses rather than redline raw measurements and color values?
basics
~20 sA raw redline records what one drawn frame measured, so engineers hardcode it and it drifts when a mode or the system changes. Naming the component, variant and token says what to reuse and keeps every theme and future update working.
In a design system, why is a component deprecated first and removed later instead of being deleted in a single release?
basics
~20 sDeprecation keeps the component working while warning consumers and naming its replacement, giving teams a support window to migrate on their own schedule; removal comes later in a major release, so no product breaks without warning.
What should a design system's release notes contain so a consuming product team knows what changed and whether it must act?
basics
~20 sChanges grouped by impact: first anything requiring consumer action, with the exact steps; then visible visual changes, new features and fixes, each naming the component, platforms and design-library counterpart, with links to docs and migration notes.
In a design system, why should dark mode remap semantic token values instead of adding dark-specific styles to every component?
basics
~20 sComponents reference semantic names such as surface, primary text and border, and a mode supplies different values for those names. One mapping switches every component at once, while per-component dark styles multiply the work and drift apart.
In a data-visualization palette system, when do you use a categorical, a sequential or a diverging palette?
basics
~20 sCategorical palettes give unordered groups distinct hues of similar weight; sequential palettes show ordered magnitude with steadily changing lightness; diverging palettes show deviation from a meaningful midpoint with two hues darkening outward from a neutral center.
In a design system, what are functional color roles like success, warning, error and info, and why define them centrally rather than per team?
basics
~20 sFunctional color roles give colors fixed meanings: success, warning, error, info, interactive states and surfaces. Defining them once means every screen sends the same signal, users learn it, and the system guarantees contrast and a non-color cue centrally.
In a design system, what do elevation levels communicate, and why define a few named levels rather than per-component shadows?
basics
~20 sElevation levels show how far a surface sits above others, signalling hierarchy, temporariness and focus. A few named levels, each mapped to one shadow or tone, keep one consistent light model and let the system retune depth in one place.
When is an icon on a car-rental vehicle card decorative rather than meaningful, and what does each kind need?
basics
~20 sAn icon is decorative when nearby visible text already carries its meaning or it is pure ornament; hide it from assistive technology. It is meaningful when it carries information nothing else states; give it a text alternative naming that information.
What accessible name should a car-rental results page give an icon-only heart button that saves a car, and why?
basics
~20 sName it by its function, not its picture: “Save to favourites”, made unique per card, such as “Save compact hatchback to favourites”. Leave out the role word, and expose the saved status as a pressed state or a changing name.
In atomic design, what makes a UI element an atom, and how do you apply the indivisibility test?
basics
~20 sAn atom is a basic interface element, such as a label, input, button or icon, that cannot be broken down further without ceasing to be functional. The test: split it; if no part still works alone, it is an atom.
In atomic design, what does bottom-up composition mean, and why does Brad Frost call the five levels a mental model rather than a linear process?
basics
~20 sBottom-up composition means larger interface parts are assembled from smaller ones: atoms into molecules, organisms, templates and finally pages. Frost stresses the levels are a lens for working on parts and whole at the same time, not five sequential steps.
In atomic design, what is a molecule, and why does a support tool's ticket-search field of label, input and button qualify as one?
basics
~20 sA molecule is a small group of atoms working as one unit with one focused job. A ticket-search field qualifies because the combination links the parts: the label names the input and the button submits its query.
In atomic design, what is an organism, and why is an airline booking site's flight-results list a good example of one?
basics
~20 sAn organism is a relatively complex component, built from molecules, atoms or other organisms, that forms a distinct section of an interface. A flight-results list qualifies: one flight-option molecule repeated into a self-contained section of the booking screen.
In atomic design, what is the difference between a template and a page, and why does the method keep pages as a separate level?
basics
~20 sA template is the layout skeleton that shows content structure; a page is one instance of it filled with real, representative content. Pages exist to show the final UI and to test whether the system's parts survive real content.
In a design system's avatar component, what should the avatar show when a person's photo is missing or fails to load?
basics
~20 sAn avatar falls through a fixed chain: the photo once it loads, otherwise the person's initials on a stable background color, otherwise a generic placeholder glyph. The frame and size never change, so nothing breaks or shifts.
In a design system, when should an action be a button and when should it be a link, and why does the difference matter?
basics
~20 sA button does something in place: submits, opens a dialog, changes state. A link goes somewhere: another page, screen or resource. Semantics must follow behaviour, because users and assistive technology rely on it to predict what will happen.
In a design system, what distinguishes a modal dialog from a non-modal dialog, and when is each the right choice?
basics
~20 sA modal dialog makes everything behind it unreachable for every user until it closes, so it fits a decision needed before continuing. A non-modal dialog lets the user keep working on the page, so it fits reference or parallel tasks.
In a design system's feedback components, when should a message be a toast, a banner or an inline alert?
basics
~20 sA toast briefly confirms a low-stakes result of the user's own action; a banner states a condition affecting the whole screen or account and stays until resolved; an inline alert sits next to the content it concerns.
In a design system's loading guidance, when should a screen use a spinner, a skeleton screen, or a progress bar?
basics
~20 sChoose by wait length and what is known: a skeleton when the arriving content's layout is known, a spinner for a short wait of unknown shape, and a progress bar when measurable work takes longer.
In a shared component library, how should an icon-only button component ensure every instance has an accessible name?
basics
~20 sMake the label a required input the component cannot be created without, and feed it into the accessible name. It should name the action and its object, such as download invoice 1042, never the icon.
In a component library, why should an element's visible text arrive as translatable inputs instead of being hardcoded inside the element?
basics
~20 sA library cannot know which languages its products ship in, so hardcoded text forces one language on every consumer. Elements should take complete, translatable messages from the app, which owns translation, and let every internal default string be overridden.
In a shared component library, why should a component's styles reference semantic theme tokens instead of literal values such as a raw color code?
basics
~20 sA literal freezes one decision inside the component, so no theme, mode or consumer can change it. A semantic token names the role a value plays, such as selected surface, and lets the active theme supply the value.
In a component library that follows semantic versioning, which version part should change for a new variant, a spacing bug fix, and a renamed property?
basics
~10 sA new variant is MINOR because it adds backward-compatible capability; a spacing fix back to the documented design is PATCH; a renamed property is MAJOR, because code still passing the old name stops working.
In a shared component library, why do teams give a component one enum variant property instead of several boolean style flags?
basics
~20 sSeveral boolean style flags let callers ask for combinations that make no sense, with the winner hidden in the implementation. One enum variant property makes the options mutually exclusive, exhaustively checkable and easy to extend; booleans stay for genuinely independent axes.
What is an accessible name, and what breaks for a voice-control user when it disagrees with the visible label?
basics
~20 sAn accessible name is the string assistive technology announces to identify a control - which one it is. Every operable control needs one, and it must contain the visible text, or voice-control users cannot activate it by saying what they see.
What does a color contrast ratio measure, and which text gets 4.5:1 versus 3:1?
basics
~10 sA contrast ratio measures how far apart two specific colors sit in relative luminance, on a scale from 1:1 to 21:1. WCAG's minimum-contrast criterion asks 4.5:1 for normal-size text and 3:1 for large text.
How do you run a keyboard-only pass and an assistive-technology pass over a task, and why in that order?
basics
~20 sTwo passes over the whole task: complete it using the keyboard alone, then repeat it with an assistive technology, judging what is announced. Run the keyboard pass first — an inoperable screen makes every later finding point at the wrong cause.
In information architecture, why should category labels match users' mental models rather than the organization's internal structure?
basics
~20 sPeople look for things using their own expectations and words, not an organization's departments or jargon. Labels drawn from users' mental models predict what lies behind them; labels drawn from the org chart leave existing features effectively invisible.
In interaction design, what is the difference between an affordance and a signifier, and why do flat interfaces need signifiers?
basics
~20 sAn affordance is what an element lets a person do, such as being tappable; a signifier is the perceivable cue that shows the action exists and where. Flat styling strips cues like underlines, borders and depth, so actions become invisible.
In UX design, what is a persona for, and what makes one evidence-based rather than decorative fiction?
basics
~20 sA persona is an archetype of a user segment that lets a team argue design decisions against real goals and behaviours. It is evidence-based when each attribute traces to patterns seen across research participants and it actually changes decisions.
In usability testing, what is the difference between moderated and unmoderated sessions, and how do you choose between them?
basics
~20 sA moderated usability session has a live facilitator, in person or remote, who gives tasks and probes; an unmoderated session runs alone through software. Choose moderated to learn why people struggle, unmoderated for fast, larger samples on well-defined tasks.
In user research, when do you choose a qualitative method over a quantitative one, and what can each kind of evidence tell you?
basics
~20 sQualitative methods such as interviews, observation and diary studies explain why and how people behave and uncover problems nobody knew to ask about. Quantitative methods such as surveys and product analytics measure how many and how much. Use qualitative to discover, quantitative to size.