Design Systems Fundamentals Flashcards

Question 1

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

Accepted Answer

A design system is a shared set of design standards, reusable components, patterns, and guidelines that teams use to build consistent digital products. It acts as a single source of truth, so designers and engineers make decisions from the same reference rather than inventing new solutions for every screen.

Question 2

Why do teams adopt a design system instead of designing each screen separately?

Accepted Answer

Teams adopt a design system to improve consistency, speed, and quality across products. Reusing approved components means designers do not redraw the same buttons or forms repeatedly, and engineers do not rebuild them for each project. Shared standards also make accessibility fixes and brand updates easier to apply everywhere at once.

Question 3

What is the difference between a design system and a style guide?

Accepted Answer

A style guide describes visual rules such as logo usage, color palettes, typography, and tone of voice. A design system includes those rules but also provides working, reusable components, design tokens, code implementations, and usage guidance for building products. Many systems began as style guides and grew into working toolkits.

Question 4

What are the core building blocks found in most design systems?

Accepted Answer

Most design systems are built from a few layers. Foundations define basic values such as color, typography, spacing, and iconography. Components are reusable interface elements like buttons and inputs, and patterns combine components to solve common tasks such as login or checkout. Documentation explains when and how to use each piece.

Question 5

What is a single source of truth in the context of design systems?

Accepted Answer

A single source of truth is one authoritative location where the approved version of each design decision lives. Every team member references the same values and components there. When a color or button style changes in that central place, consuming products can be updated. This prevents conflicting versions from spreading across teams and files.

Question 6

Who typically uses a design system within an organization?

Accepted Answer

Designers, front-end engineers, product managers, content writers, and quality assurance testers all rely on a design system, though in different ways. Designers use it for mockups and prototypes, engineers implement its components in code, and writers follow its voice and content guidance. Shared use keeps everyone working from the same definitions, which reduces miscommunication between roles.

Question 7

Why does visual and behavioral consistency matter to people using a digital product?

Accepted Answer

Consistency helps users predict how an interface will behave, so they spend less effort learning each new screen. When buttons look alike, links behave the same way, and form errors appear in familiar places, people can focus on their tasks instead of the interface. It also builds trust in the product.

Question 8

What is the difference between a design system and a component library?

Accepted Answer

The main difference is scope. A component library holds reusable UI elements, often with matching code, while a design system also includes foundations like tokens, patterns, principles, documentation, and governance. Most design systems contain a component library, but a library alone is not a complete design system.

Question 9

What are design tokens and what do they store?

Accepted Answer

Design tokens are named values that store design decisions, such as a color, font size, spacing unit, or corner radius. Instead of writing a hex code directly into a button style, a team references a token like color action primary. Because the name stays the same, its value can update everywhere at once.

Question 10

What is the purpose of naming tokens by role rather than by raw value?

Accepted Answer

Naming tokens by role, such as color text muted, describes what a value is for rather than how it looks. A raw name like gray 500 becomes misleading if the brand changes that shade. Role-based names keep intent clear, so a theme such as dark mode can remap values without renaming anything.

Question 11

How do primitive and semantic token layers work together in a token system?

Accepted Answer

Token layers work in two tiers: primitive tokens hold raw values, such as a blue hex code or a 16 pixel spacing step, with no assigned meaning. Semantic tokens point to primitives and describe purpose, such as color feedback error. Components reference semantic tokens, so a brand refresh changes only primitive values.

Question 12

What information should a well-formed design token include beyond its value?

Accepted Answer

A well-formed token usually includes a name, a value, and a type, such as color, dimension, or font family. Many teams also record a description explaining intended use and a category or group, which helps people find the right token. Metadata like this makes tokens easier to search, document, and validate automatically.

Question 13

Why do design token values often need to work across platforms like web, iOS, and Android?

Accepted Answer

Products on several platforms use different languages and units, so token values need a neutral format. A build tool converts those tokens into CSS variables for the web, Swift constants for iOS, or Kotlin resources for Android. This means a single decision about a color or spacing value can reach every platform consistently.

Question 14

What is token theming and why do teams use it?

Accepted Answer

Theming means defining alternative sets of token values that change the look of a product without altering components. For example, a light theme and a dark theme can both map the same semantic names, such as color surface default, to different primitive colors. Teams use theming for dark mode or high-contrast modes.

Question 15

How can a team decide which values deserve to become tokens?

Accepted Answer

Good candidates are values that repeat across many components and represent a deliberate decision, such as brand colors, type scales, and standard spacing steps. A one-off measurement used in a single component usually does not need a token. Reviewing repeated values in existing designs and code is a practical way to find them.

Question 16

What is a common mistake when creating a token set?

Accepted Answer

A common mistake is creating too many tokens too early, so the set becomes large, confusing, and hard to maintain. Another is naming tokens after current visual values, such as blue 600, which breaks when the brand changes. Start with a small, well-named set, then expand it as real needs appear in products.

Question 17

What is a component in a design system?

Accepted Answer

A component is a reusable interface element, such as a button, checkbox, card, or navigation bar, with defined appearance, behavior, and states. Each component is designed once and then reused across screens, so teams make consistent choices without rebuilding the element. In code, a component accepts properties that control its variant, size, or label.

Question 18

What are component states and why should a design system document them?

Accepted Answer

Component states are the different conditions a component can be in, such as default, hover, focused, pressed, disabled, loading, and error. Documenting every state prevents designers and engineers from guessing how an element should look or behave in each situation. Missing states often cause inconsistent interfaces and accessibility gaps.

Question 19

What is the difference between a variant and a state?

Accepted Answer

A variant is a deliberate version of a component with a different design purpose, such as a primary, secondary, or destructive button. A state is a temporary condition the component moves through during use, such as hover, disabled, or loading. Variants are set when a component is placed, while states change during use.

Question 20

What is a design pattern in this context, and how does it differ from a component?

Accepted Answer

A pattern is a reusable solution to a common design problem that combines several components into a larger arrangement, such as a search form with filters or a sign-in flow. A component is a single building block, while a pattern shows how blocks work together, including layout, content order, and interaction rules. Patterns guide decisions that components alone cannot settle.

Question 21

What makes a component API easy to use?

Accepted Answer

A clear component interface uses descriptive property names, sensible defaults, and a small number of well-chosen options. Required properties should be obvious, optional ones should have safe default values, and related choices should be grouped rather than scattered. Consistent naming across components helps developers guess how a new element works before reading its documentation.

Question 22

Why do designers and engineers need to agree on component behavior, not just appearance?

Accepted Answer

A component that looks correct in a mockup can still fail if keyboard navigation, animation timing, or error handling differs from the design. Design files usually show static screens, so teams need written interaction specifications and shared test cases to capture how the component should respond to input.

Question 23

How should accessibility be built into component design?

Accepted Answer

Accessibility should be considered from the start, not added after a component ships. Components should support keyboard operation, provide visible focus indicators, expose meaningful labels to assistive technology, and maintain sufficient color contrast. Documenting these requirements in the system means every team inherits them automatically, rather than rediscovering them in each product.

Question 24

Why do teams prefer composing small components over building large custom ones?

Accepted Answer

Composition means assembling small, focused components into larger structures, such as a card built from an image, a heading, and a button. Small components are easier to test, document, and reuse, and fixes made to one piece improve every place it appears. Large custom components tend to duplicate logic and drift apart over time.

Question 25

Why is documentation considered part of a design system rather than an extra?

Accepted Answer

Documentation is part of the system because a component without usage guidance is hard to use correctly. Good documentation explains when to use an element, when to choose something else, and how it behaves in different states. Without it, people guess, and the system becomes a library of parts that no one applies consistently.

Question 26

What should a typical component documentation page include?

Accepted Answer

A useful component page usually describes the purpose, anatomy with labeled parts, variants, states, spacing, and do and don't examples. It should also list accessibility requirements, keyboard behavior, content guidelines for labels. Including code usage and a clear status, such as stable or deprecated, helps teams know what to rely on.

Question 27

What does design system governance mean and why does it matter?

Accepted Answer

Governance is the set of processes that decide how a design system is proposed to change, reviewed, approved, released, and retired. It matters because a system without clear ownership quickly accumulates duplicate components, conflicting rules, and abandoned patterns. Good governance balances stability for product teams with a path for contributions and improvements.

Question 28

Who usually owns a design system, and what does that role involve?

Accepted Answer

A design system is usually owned by a small cross-functional team that includes designers and engineers. This team maintains the core components, reviews contribution requests, answers questions from product teams, and publishes releases. Ownership is a real job with ongoing work, not a project that ends after launch.

Question 29

What is a contribution model and why do teams define one?

Accepted Answer

A contribution model describes how people outside the core team can propose new components, changes, or fixes, and how those proposals are reviewed. Models range from fully central ownership to federated teams that build locally and share back. Defining one sets expectations, prevents bottlenecks, and keeps quality consistent as the system grows.

Question 30

How should a design system handle deprecating a component?

Accepted Answer

The system should mark the old component as deprecated while keeping it available long enough for products to migrate. The team announces the change, documents the replacement, and provides clear migration steps. Only after a reasonable transition period should the old component be removed, so product teams are not broken without warning.

Question 31

What is semantic versioning in a design system and why use it?

Accepted Answer

Semantic versioning labels releases with three numbers: major, minor, and patch. A major change signals breaking updates, a minor change adds features without breaking existing use, and a patch fixes bugs. Clear version numbers help product teams judge the risk of upgrading and plan migration work.

Question 32

What should a design system changelog record for each release?

Accepted Answer

A changelog should list each release's new components, changed or removed properties, bug fixes, and deprecations, along with its version number. Entries should be written for product teams, describing what changed and what action, if any, they need to take. Keeping a clear record turns upgrades from guesswork into planned, low-risk work.

Question 33

How do teams measure whether a design system is succeeding?

Accepted Answer

Teams often look at adoption, such as how many product screens use system components, and at reduced duplication or custom one-off elements. Feedback from designers and engineers also indicates whether the system is useful. No single number tells the full story, so teams combine usage data with qualitative input.

Question 34

How should a team introduce a design system to an existing product?

Accepted Answer

Start by auditing current screens to find the most repeated elements, then build a small set of foundations and components that solve real problems. Work with one product team as a pilot, so the system is shaped by actual use. Expand gradually, and avoid requiring every existing screen to migrate at once.

Question 35

What are common reasons product teams resist adopting a design system?

Accepted Answer

Common reasons include a belief that the system will slow them down, concern that it does not fit their unique needs, and lack of time to migrate existing work. Addressing these concerns with responsive support, flexible options, and realistic migration plans builds trust over time.

Question 36

How can teams handle a product need that the design system does not yet cover?

Accepted Answer

Teams can build a local solution within the product first, using system tokens and foundations so it still looks consistent. If the need recurs across products, the team should propose it as a new component or pattern through the contribution process. Promoting proven solutions into the system keeps it grounded in real use.

Question 37

Why should design system releases be tested before they reach product teams?

Accepted Answer

Because many products depend on shared components, a single defect can spread to every screen that uses it. Testing catches visual regressions, broken interactions, and accessibility issues before they affect real users. Automated visual comparisons and code tests, combined with manual review, give teams confidence that a release is safe to adopt.

Question 38

What is a visual regression and how do teams catch one?

Accepted Answer

A visual regression is an unintended change in how an existing component looks. Teams catch them by capturing screenshots of components in many states and comparing new captures against approved baselines. Differences are then reviewed by a person to decide whether the change is intended or needs a fix.

Question 39

How can teams keep a design system from becoming outdated?

Accepted Answer

Assign clear ownership, schedule regular reviews of components against current product needs, and track feedback from teams that use the system. Retire components that no longer serve a purpose, and keep platform guidance aligned with current interface conventions. Staying current is ongoing maintenance, which requires budgeted time, not just an initial launch effort.

Question 40

What is a common sign that a design system is being ignored?

Accepted Answer

A common sign is the appearance of many one-off components that look similar to system components but use slightly different colors, spacing, or fonts. Teams may also copy old component code instead of using the current version, or create local colors that duplicate existing tokens. Regular audits of products reveal these gaps early.

Design Systems Fundamentals Flashcards

1Foundations of Design Systems

2Design Tokens and Theming

3Components and Patterns

4Documentation and Governance

5Adoption and Maintenance

Learning Resources