Design Systems Development Flashcards

Question 1

What is a design token in a design system?

Accepted Answer

A design token is a named value that stores one design decision, such as a color or spacing step. Tokens replace hard-coded values, so a change made once reaches every product that uses that token. Many teams write tokens in a platform-neutral format so they can generate web, iOS, and Android outputs.

Question 2

Why do design systems use semantic tokens alongside raw color values?

Accepted Answer

Semantic tokens describe purpose rather than appearance, such as color-background-danger instead of red-600. Because the purpose stays fixed, the underlying raw value can change, for example for a dark theme, without editing every component. This separation makes theming and accessibility adjustments much easier to manage.

Question 3

What is the difference between a primitive token and a component token?

Accepted Answer

A primitive token holds a raw value with no context, such as a hue, a pixel size, or a font family. A component token maps a primitive or semantic token to a specific part of a component, such as the padding of a button. Layering them keeps raw values centralized while components stay adjustable.

Question 4

What role do design principles play when a team creates a new system?

Accepted Answer

Design principles are a short set of guiding statements that explain what the system values, such as clarity, consistency, or accessibility. They help a team resolve debates about new components or exceptions by pointing to shared priorities rather than personal taste. Good principles are specific enough to reject options, not just generic goals.

Question 5

What is the purpose of a naming convention for tokens?

Accepted Answer

A naming convention gives every token a predictable, readable name so that people and tools can find and use it consistently. A common pattern moves from general to specific, such as category, property, and variant. Clear names reduce duplicate tokens and make it easier to see which decisions a value is meant to support.

Question 6

How do design tokens support theming across multiple brands?

Accepted Answer

Tokens support theming by letting each brand supply its own values for the same token names. The component code refers only to the token, so swapping one set of values for another changes the look without rewriting components. This approach allows one system to serve several products while keeping their visual identities distinct.

Question 7

Why should a design system define a scale for spacing and type?

Accepted Answer

A defined scale limits the number of values a team can choose, which keeps layouts visually rhythmic and easier to maintain. Spacing scales often use a base unit with multiples, and type scales use consistent ratios or steps between sizes. Limiting choices also makes handoff between designers and developers more predictable.

Question 8

How should a team decide which visual decisions become tokens?

Accepted Answer

A visual decision should become a token when it is repeated across components, needs to change as a unit, or carries meaning that others must share. One-off values that appear only once rarely justify a token. Reviewing usage in the existing product often reveals the candidates worth standardizing first.

Question 9

What is a component in the context of a design system?

Accepted Answer

A component is a reusable interface element, such as a button, input field, or card, that is built once and used in many places. Each component has defined properties, states, and variants that control how it appears and behaves. Packaging these elements lets teams assemble screens quickly and keeps common behavior identical across products.

Question 10

What are component states, and why do they need to be documented?

Accepted Answer

Component states are the conditions a component can be in, such as default, hover, focus, disabled, loading, or error. Documenting each state tells developers exactly what to build and tells designers what to design. Missing states, especially focus and disabled, are a common cause of inconsistent behavior and accessibility gaps.

Question 11

What is the difference between a component variant and a component instance?

Accepted Answer

A variant is a defined version of a component with a fixed set of differences, such as a primary or secondary button. An instance is a single use of a component placed inside a screen, which inherits its properties from the main definition. Changing the main component updates instances unless they were overridden.

Question 12

Why do composite components rely on smaller building blocks?

Accepted Answer

Composite components are assembled from simpler parts, such as a form field built from a label, input, and message. Building from smaller blocks means a fix to the label or input improves every composite that uses it. This layering keeps the system consistent and reduces repeated work.

Question 13

What does it mean for a component API to be composable?

Accepted Answer

A composable API lets developers combine small pieces, such as a container, header, and body, rather than passing every option through one large set of props. Consumers can rearrange or omit parts without the component needing a new option for each layout. Composition keeps the interface flexible while the component still enforces core rules.

Question 14

Why is accessibility built into a component's definition rather than added later?

Accepted Answer

Accessibility is cheaper to build in than to retrofit, because semantics, keyboard behavior, and focus order are set once in the component. Retrofitting often means changing markup and styles across many products. Writing these requirements into the component spec gives every release a clear test.

Question 15

How do design systems handle component versioning when a breaking change is needed?

Accepted Answer

Teams usually treat a breaking change as a new major version so consumers can migrate on their own schedule. Older versions stay available for a stated period, and a migration guide explains what changed and how to update. Semantic versioning is a common convention for signaling which releases are safe to adopt without changes.

Question 16

What is the role of a component's props or inputs in its contract?

Accepted Answer

Props, or inputs, are the values a parent passes into a component to control its content and behavior. They define the public contract, meaning the set of options consumers can rely on. Keeping props small, named clearly, and well documented prevents misuse and makes future changes safer.

Question 17

Why does a design system need documentation for each component?

Accepted Answer

Documentation tells people what a component is for, how to use it, and when another component would be a better choice. Without it, teams guess at usage, build duplicates, and drift away from the intended design. Good documentation is a key way a system scales beyond the people who created it.

Question 18

What sections should a typical component page include?

Accepted Answer

A typical component page includes a summary, usage guidance, anatomy, variants, states, accessibility notes, content guidelines, and code examples. Each section answers a specific question a designer or developer will ask. Teams often add do and don't examples to make boundaries clearer than prose alone.

Question 19

What is the purpose of a contribution guide for a design system?

Accepted Answer

A contribution guide explains how people outside the core team can propose changes, report issues, and submit new components. It sets expectations for review, testing, and documentation so that every addition meets the same standard. Clear guidance also reduces the back-and-forth that slows down both contributors and maintainers.

Question 20

How do teams decide whether a new component belongs in the system?

Accepted Answer

Teams usually check whether the pattern appears across several products, whether an existing component could be extended instead, and whether the design principles support it. A proposal that solves a single product's problem often belongs in that product rather than the shared library. Reviewing these questions keeps the library focused and maintainable.

Question 21

What is a changelog, and why should a design system keep one?

Accepted Answer

A changelog is a versioned record of what changed in each release, such as added components, fixed bugs, and removed props. Consumers use it to decide when and how to upgrade. Maintainers use it to communicate intent and to trace unexpected behavior back to a specific change.

Question 22

What does a design review checklist check before a component is released?

Accepted Answer

A review checklist usually confirms that the component matches its design tokens, covers all documented states, meets accessibility requirements, and has tested code and examples. It also checks that naming, props, and documentation follow the system's conventions. Using a shared checklist makes reviews consistent regardless of which reviewer is assigned.

Question 23

What is the difference between a design file and a code component as sources of truth?

Accepted Answer

A design file shows how a component should look and how its states should behave in a prototype, while a code component is the implemented version that ships to products. Teams must agree on which one governs each detail. Many teams link the two with shared tokens and automated checks.

Question 24

How should contributors handle an open question about a component's behavior?

Accepted Answer

Contributors should record the question in the issue tracker, link it to the relevant component page, and tag the people who own that area. Leaving the decision undocumented leads to conflicting implementations later. Once a decision is made, the outcome should be written into the documentation so the answer is available to everyone.

Question 25

What is design system governance and why does it matter?

Accepted Answer

Design system governance is the set of roles, decision processes, and rules that determine how the system is changed and maintained. It matters because a shared library without clear ownership quickly accumulates conflicting patterns. Good governance balances speed for product teams with consistency across the whole organization.

Question 26

What roles are commonly found on a design system team?

Accepted Answer

A design system team commonly includes a system lead who sets priorities, designers who create and document patterns, engineers who build and maintain components, and a content or documentation specialist. Some teams also name product champions, who represent consumer teams and feed back their needs.

Question 27

What is the difference between a centralized and a federated model?

Accepted Answer

A centralized model keeps all component ownership and approval in one core team, which favors consistency but can slow product teams. A federated model spreads contribution and ownership across several teams under shared standards, which favors speed but needs stronger coordination. Many organizations choose a hybrid that centralizes foundations and federates specialized components.

Question 28

How does a team decide who can approve changes to shared tokens?

Accepted Answer

Approval rights usually follow the impact of a change, so token changes that affect many products need review from the system owners and affected teams. Teams often write this down in a decision matrix that lists change types and required approvers. Clear rules prevent both bottlenecks and surprise changes that break consumers.

Question 29

Why is adoption a separate concern from building the system?

Accepted Answer

Adoption is the work of getting product teams to use the system, and a well-built library can still fail if nobody uses it. Adoption depends on trust, convenience, and support, not only on technical quality. Teams that plan for onboarding, migration help, and feedback loops usually see the system spread more successfully.

Question 30

How can a team measure whether product teams are actually using the system?

Accepted Answer

Teams commonly track adoption by scanning codebases for imports of library components, looking for detached or locally copied components, and asking product teams directly. Usage numbers show breadth, but interviews reveal why teams avoid or work around parts of the system. Combining both sources gives a more accurate picture than either one alone.

Question 31

Why do teams sometimes fork a component, and what risk does that create?

Accepted Answer

Teams fork a component when the shared version does not meet a specific need and waiting for a change feels too slow. A fork gives short-term freedom, but it stops receiving fixes and updates from the system. Over time, forks create inconsistent experiences and multiply the work needed to keep products aligned.

Question 32

What is an escape hatch, and when should a system allow one?

Accepted Answer

An escape hatch is a documented way for a team to step outside the system's normal rules, such as overriding a token for a legitimate edge case. Allowing one prevents teams from silently forking, because the exception is visible and can be tracked. Escape hatches should be rare and reviewed.

Question 33

How can automated tests protect a design system from regressions?

Accepted Answer

Automated tests compare a component's rendered output or behavior against expected results, so unintended changes are flagged before release. Visual regression tests capture screenshots and report pixel differences, while unit and interaction tests check props, events, and keyboard support. Running these checks on every change keeps the system stable with many contributors.

Question 34

What metrics help show whether a design system is succeeding?

Accepted Answer

Useful metrics include adoption across product teams, the share of interface built from system components, and how often contributors submit or request changes. Teams may also track time saved on common tasks, accessibility defects, and the number of open requests. No single number tells the full story, so metrics work best alongside qualitative feedback.

Question 35

Why do teams track the deprecation status of components?

Accepted Answer

Tracking deprecation status shows consumers which components are being phased out and which replacements they should adopt. Marking a component as deprecated, rather than removing it immediately, gives products time to migrate. Clear status labels in documentation and code warnings help teams plan their work without surprises.

Question 36

What is the purpose of an accessibility audit for a design system?

Accepted Answer

An accessibility audit checks components against recognized standards, such as contrast ratios, keyboard operation, focus visibility, and screen reader semantics. Auditing the system once is not enough, because each new component or token change can introduce a new barrier. Regular audits paired with automated checks keep it a continuing responsibility.

Question 37

How should a team handle a breaking change in a token value?

Accepted Answer

A team should announce the change early, document the old and new values, and provide a transition period when possible. Where feasible, the old token can remain as an alias that points to the new value, so products keep working while they update. Usage reports make migration measurable.

Question 38

What is the purpose of a release process for a design system?

Accepted Answer

A release process defines how changes are tested, reviewed, packaged, versioned, and published so consumers receive reliable updates. A predictable cadence helps product teams plan upgrades instead of reacting to surprise changes. Each release should include notes that explain what changed and what action, if any, consumers must take.

Question 39

How does a team know when a component is no longer worth maintaining?

Accepted Answer

Signals include low adoption, repeated bugs, a design pattern that no longer matches the principles, and a replacement that covers the same need better. Teams usually review these signals on a regular schedule and then decide whether to improve, merge, or deprecate the component.

Question 40

What is the main lesson for keeping a design system healthy over time?

Accepted Answer

A design system stays healthy when someone is clearly responsible for it, when changes are documented and tested, and when feedback from product teams shapes priorities. Systems decay when maintenance is treated as optional or when the library grows without review. Ongoing care, not the initial launch, determines whether a system remains useful.

Design Systems Development Flashcards

1Design tokens and foundations

2Component architecture and patterns

3Documentation and contribution workflows

4Governance and team adoption

5Measurement, testing and maintenance

Learning Resources