skip to content

Design systems & UX foundations

8 roadmaps423 questionsupdated

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 pageshow

guide

overview

~2 min

Design 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.

  1. 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.

  2. Design Language →

    Type, color, spacing and motion are the decisions everything else encodes, so learn what they are before learning how to store them.

  3. Design Tokens →

    The token tiers and naming rules explain theming, handoff and most component styling questions that follow.

  4. Accessibility →

    Names, roles, keyboard operation and contrast are the rules behind most component-family requirements; learn them before the families.

  5. Standard UI Components →

    Applies the foundations and accessibility rules to concrete families: when to use each control and what states it must handle.

  6. 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

report an issue with this guide →

questions

423 · 7 sections

How does a design system differ from a component library, a style guide, a pattern library and a UI kit?

level: juniorimportance: must knowfreq 55%
basics
~20 s

A 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.

open as a page

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?

level: juniorimportance: must knowfreq 55%
basics
~20 s

A 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.

open as a page

In a design system, why is a component deprecated first and removed later instead of being deleted in a single release?

level: juniorimportance: must knowfreq 38%
basics
~20 s

Deprecation 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.

open as a page

What should a design system's release notes contain so a consuming product team knows what changed and whether it must act?

level: juniorimportance: must knowfreq 38%
basics
~20 s

Changes 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.

open as a page

In a design system, why should dark mode remap semantic token values instead of adding dark-specific styles to every component?

level: juniorimportance: must knowfreq 60%
basics
~20 s

Components 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.

open as a page

In a data-visualization palette system, when do you use a categorical, a sequential or a diverging palette?

level: juniorimportance: must knowfreq 52%
basics
~20 s

Categorical 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.

open as a page

In a design system, what are functional color roles like success, warning, error and info, and why define them centrally rather than per team?

level: juniorimportance: must knowfreq 55%
basics
~20 s

Functional 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.

open as a page

In a design system, what do elevation levels communicate, and why define a few named levels rather than per-component shadows?

level: juniorimportance: must knowfreq 46%
basics
~20 s

Elevation 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.

open as a page

When is an icon on a car-rental vehicle card decorative rather than meaningful, and what does each kind need?

level: juniorimportance: must knowfreq 55%
basics
~20 s

An 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.

open as a page

What accessible name should a car-rental results page give an icon-only heart button that saves a car, and why?

level: juniorimportance: must knowfreq 62%
basics
~20 s

Name 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.

open as a page

In atomic design, what makes a UI element an atom, and how do you apply the indivisibility test?

level: juniorimportance: must knowfreq 48%
basics
~20 s

An 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.

open as a page

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?

level: juniorimportance: must knowfreq 50%
basics
~20 s

Bottom-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.

open as a page

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?

level: juniorimportance: must knowfreq 48%
basics
~20 s

A 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.

open as a page

In atomic design, what is an organism, and why is an airline booking site's flight-results list a good example of one?

level: juniorimportance: must knowfreq 45%
basics
~20 s

An 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.

open as a page

In atomic design, what is the difference between a template and a page, and why does the method keep pages as a separate level?

level: juniorimportance: must knowfreq 45%
basics
~20 s

A 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.

open as a page

In a design system's avatar component, what should the avatar show when a person's photo is missing or fails to load?

level: juniorimportance: must knowfreq 55%
basics
~20 s

An 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.

open as a page

In a design system, what distinguishes a modal dialog from a non-modal dialog, and when is each the right choice?

level: juniorimportance: must knowfreq 60%
basics
~20 s

A 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.

open as a page

In a design system's feedback components, when should a message be a toast, a banner or an inline alert?

level: juniorimportance: must knowfreq 60%
basics
~20 s

A 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.

open as a page

In a design system's loading guidance, when should a screen use a spinner, a skeleton screen, or a progress bar?

level: juniorimportance: must knowfreq 60%
basics
~20 s

Choose 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.

open as a page

In a shared component library, how should an icon-only button component ensure every instance has an accessible name?

level: juniorimportance: must knowfreq 58%
basics
~20 s

Make 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.

open as a page

In a component library, why should an element's visible text arrive as translatable inputs instead of being hardcoded inside the element?

level: juniorimportance: must knowfreq 45%
basics
~20 s

A 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.

open as a page

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?

level: juniorimportance: must knowfreq 62%
basics
~20 s

A 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.

open as a page

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?

level: juniorimportance: must knowfreq 55%
basics
~10 s

A 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.

open as a page

In a shared component library, why do teams give a component one enum variant property instead of several boolean style flags?

level: middleimportance: must knowfreq 58%
basics
~20 s

Several 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.

open as a page

What is an accessible name, and what breaks for a voice-control user when it disagrees with the visible label?

level: juniorimportance: must knowfreq 76%
basics
~20 s

An 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.

open as a page

What does a color contrast ratio measure, and which text gets 4.5:1 versus 3:1?

level: juniorimportance: must knowfreq 78%
basics
~10 s

A 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.

open as a page

What determines focus order on a screen, and why is a focus order that contradicts the visual layout a defect?

level: juniorimportance: must knowfreq 70%
basics
~20 s

Focus order follows the order controls appear in a screen's underlying structure, not where they are painted. When the two disagree, keyboard users jump unpredictably, and WCAG treats that as a Focus Order failure, not a cosmetic flaw.

open as a page

How does a screen reader user move through an unfamiliar screen, and what must the screen provide for each way of moving?

level: juniorimportance: must knowfreq 74%
basics
~20 s

Screen reader users rarely read top to bottom. They jump between structural elements, step from one control to the next, or read linearly through everything. Each way of moving needs real structure behind the visuals, not just visual formatting.

open as a page

How do you run a keyboard-only pass and an assistive-technology pass over a task, and why in that order?

level: juniorimportance: must knowfreq 66%
basics
~20 s

Two 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.

open as a page

In information architecture, why should category labels match users' mental models rather than the organization's internal structure?

level: juniorimportance: must knowfreq 44%
basics
~20 s

People 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.

open as a page

In interaction design, what is the difference between an affordance and a signifier, and why do flat interfaces need signifiers?

level: juniorimportance: must knowfreq 55%
basics
~20 s

An 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.

open as a page

In UX design, what is a persona for, and what makes one evidence-based rather than decorative fiction?

level: juniorimportance: must knowfreq 52%
basics
~20 s

A 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.

open as a page

In usability testing, what is the difference between moderated and unmoderated sessions, and how do you choose between them?

level: juniorimportance: must knowfreq 52%
basics
~20 s

A 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.

open as a page

In user research, when do you choose a qualitative method over a quantitative one, and what can each kind of evidence tell you?

level: juniorimportance: must knowfreq 55%
basics
~20 s

Qualitative 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.

open as a page
Design systems & UX foundations interview questions & primer · KataJob