Title: Design Systems — LearnCoachAssist

Q: What is a design system?
A: A design system is a shared set of principles, components, patterns, and rules that help teams build consistent products faster.

Q: Why do design systems matter?
A: They improve consistency, speed up delivery, and reduce repeated design and engineering decisions.

Q: What is the difference between a style guide and a design system?
A: A style guide documents visual rules, while a design system also includes reusable components, interaction guidance, and implementation details.

Q: What are design tokens?
A: Design tokens are named values for color, spacing, typography, and other primitives that can be reused across tools and code.

Q: Why are reusable components valuable?
A: Reusable components reduce duplication and make it easier to maintain consistency at scale.

Q: What is component documentation?
A: Component documentation explains when to use a component, how it behaves, and what variants or constraints apply.

Q: What is a pattern in a design system?
A: A pattern is a higher-level solution made of multiple components working together for a common use case.

Q: Why should accessibility be built into a design system?
A: Accessible defaults let every team inherit better behavior instead of fixing the same issues repeatedly.

Q: What is governance in a design system?
A: Governance is the process for proposing, reviewing, approving, and maintaining system changes.

Q: Why is contribution guidance useful?
A: Clear contribution rules make it easier for teams to improve the system without creating chaos.

Q: What is a source of truth in a design system?
A: The source of truth is the authoritative place where the current component definitions and guidance live.

Q: What is component API design?
A: It is the practice of defining props, states, and variants so components are flexible without becoming confusing.

Q: Why should variants be limited intentionally?
A: Too many variants make the system harder to learn, maintain, and use consistently.

Q: What is visual consistency?
A: Visual consistency means products feel related because spacing, typography, color, and interaction patterns align.

Q: What is interaction consistency?
A: Interaction consistency means controls behave in predictable ways across the product.

Q: Why should teams document anti-patterns?
A: Anti-patterns help people see what not to do and why certain shortcuts create UX or maintenance problems.

Q: What is system adoption?
A: System adoption is the degree to which product teams actually use the design system in day-to-day work.

Q: Why does adoption fail sometimes?
A: Adoption often fails when the system is hard to use, poorly documented, or disconnected from product reality.

Q: What is a component inventory?
A: A component inventory is a review of existing UI to identify duplication, inconsistency, and opportunities for standardization.

Q: Why should engineers and designers co-own the system?
A: Shared ownership helps ensure the system is both visually coherent and technically practical.

Q: What is versioning in a design system?
A: Versioning tracks changes so teams can adopt updates intentionally and manage breaking changes safely.

Q: What is deprecation?
A: Deprecation is the process of marking older patterns or components as outdated and guiding teams toward replacements.

Q: Why are examples important in design system docs?
A: Examples show teams how to apply abstract guidance correctly in real interfaces.

Q: What is the relationship between a design system and brand?
A: A design system operationalizes brand through consistent visual and interaction decisions in the product.

Q: What is a good design system principle?
A: Make the right choice the easiest choice for product teams.

Q: Why should a design system evolve?
A: Products, platforms, and user needs change over time, so the system must adapt without losing coherence.

Q: What is a practical design system metric?
A: Useful metrics include adoption rate, component reuse, defect reduction, and speed of delivery.

Q: What is system debt?
A: System debt is the inconsistency and duplication that accumulate when teams bypass or fragment the shared patterns.

Q: Why is naming important in design systems?
A: Clear naming improves discoverability, reduces misuse, and helps teams talk about UI consistently.

Q: What is a durable design system habit?
A: Continuously refine the system based on real product use, not just abstract theory.

Q: Why should design systems include content guidance?
A: Words shape usability too, so components often need guidance for labels, helper text, and error states.

Q: What is a strong component quality bar?
A: A component is high quality when it is accessible, documented, reusable, testable, and aligned with real product needs.

Q: What is the difference between a component library and a design system?
A: A component library is reusable UI code; a design system also includes principles, tokens, patterns, docs, governance, and contribution model.

Q: What is the atomic design methodology?
A: Brad Frost's hierarchy: atoms (tokens, buttons), molecules (form fields), organisms (header), templates, pages — bottom-up composition.

Q: What is an "atom" in atomic design?
A: The smallest UI building block — a button, input, icon, or single token — not useful alone but combined into molecules.

Q: What is a "molecule" in atomic design?
A: A small group of atoms working together as a single unit — e.g., a labeled input with a helper text and error.

Q: What is an "organism" in atomic design?
A: A complex UI section composed of molecules and atoms — e.g., a navigation bar, a card grid, a checkout form.

Q: What is a "template" in atomic design?
A: A page-level layout that arranges organisms but with placeholder content.

Q: What is a "page" in atomic design?
A: A concrete template populated with real content — what users actually see.

Q: What is a primitive token?
A: A raw value (e.g., #0066CC, 8px) with no semantic meaning — building block for higher-level tokens.

Q: What is a semantic token?
A: A token named for its role (color.text.primary, spacing.section) — abstracts the primitive so themes can swap underneath.

Q: What is an alias token?
A: A token pointing to another token — used to share values while preserving semantic naming for swap-ability.

Q: What is a component-level token?
A: A token scoped to a specific component (button.color.bg.primary) — most flexible, hardest to govern.

Q: What is a tier-1 token?
A: The deepest layer — raw primitives. Renamed only with major version bump.

Q: What is a tier-2 token?
A: The semantic layer — what teams use most. Stable naming, swappable values per theme.

Q: What is a tier-3 token?
A: The component-specific layer — bound to a single component's needs.

Q: What is the W3C Design Tokens spec?
A: A community-driven specification for a portable JSON format describing tokens — allows interchange between tools.

Q: What is Style Dictionary?
A: An Amazon-built tool that transforms a single token source into platform-specific outputs (CSS, iOS, Android, etc.).

Q: What is Tokens Studio?
A: A Figma plugin for managing design tokens directly inside Figma and syncing to a code repository.

Q: What is the "single source of truth" debate?
A: Whether design tools or code holds the canonical tokens — increasingly answered by a JSON file Git-managed and consumed by both.

Q: What is a "token transform"?
A: A pipeline step that rewrites tokens (e.g., px→rem, color format conversion) for a specific platform.

Q: What is "platform parity" in a design system?
A: Same component behavior and look across web, iOS, Android — requires per-platform implementation aligned to one design source.

Q: What is "theming"?
A: Swapping token values to produce alternative looks (dark mode, brand variations) without changing component code.

Q: What is "multi-brand theming"?
A: A design system supporting multiple brands by swapping token sets at runtime or build time.

Q: What is "context-aware theming"?
A: Theming that adapts to user preference, system setting, or page area (e.g., inverted hero section).

Q: What is "dark mode" implementation?
A: Defining dark-mode token values, ensuring contrast ratios, and providing component behavior changes (e.g., elevation via tint, not shadow).

Q: What is "elevation token"?
A: A token representing perceived layering — typically encoded as a shadow stack or a tint plus blur amount.

Q: What is a "shadow token"?
A: A composite token (offset, blur, color) representing one elevation level in a system.

Q: What is a "z-index token"?
A: Named stacking levels (modal, dropdown, toast) so layering stays consistent without arbitrary integers scattered through code.

Q: What is the "spacing scale"?
A: A geometric or linear progression (4, 8, 12, 16, 24, 32, 48, 64) used everywhere to enforce visual rhythm.

Q: What is the "type scale"?
A: A modular progression of font sizes (e.g., based on 1.25 or 1.333 ratio) for visual hierarchy.

Q: What is a "fluid type scale"?
A: Type sizes that scale smoothly with viewport using CSS clamp() — avoids fixed breakpoints.

Q: What is the "baseline grid"?
A: A horizontal line system aligning type to a common vertical rhythm — increases polish in dense layouts.

Q: What is the "8-point grid"?
A: A spacing system where all values are multiples of 8 — easy mental math and aligns with most platforms' default densities.

Q: What is the "4-point grid"?
A: A finer grid using multiples of 4 — common when smaller increments are needed (icons, dense data UI).

Q: What is a "density mode"?
A: Compact/comfortable/spacious variants of components for different data densities — set via a token swap.

Q: What is "responsive component design"?
A: Components that adapt internally to their container width — usually via container queries, not just viewport.

Q: What is a "container query"?
A: A CSS feature letting a component respond to its parent's size, not the viewport — enables real component-level responsiveness.

Q: What is "intrinsic web design"?
A: Jen Simmons' framing: layouts that respond naturally to content and context, not just to breakpoints.

Q: What is a "breakpoint" in a design system?
A: A defined viewport width at which layout shifts — should be tokenized, named (sm/md/lg/xl), and used consistently.

Q: What is "fluid grid"?
A: A grid using percentages and flexible columns that resize smoothly — foundational to modern responsive design.

Q: What is "design system documentation site"?
A: The canonical reference site (often built with Storybook, Docusaurus, ZeroHeight) — single landing place for everything.

Q: What is Storybook?
A: A workshop tool for building UI components in isolation and documenting their variants, states, and controls.

Q: What is "Storybook play function"?
A: A scripted interaction (clicks, typing) inside a story — enables visual testing of behavior.

Q: What is "Chromatic"?
A: A visual regression testing service for Storybook — captures pixel diffs to catch unintended UI changes.

Q: What is ZeroHeight?
A: A design system documentation platform integrating Figma and code references with editorial content.

Q: What is "Backlight"?
A: A design-system platform that hosts components, docs, tokens, and previews in one place.

Q: What is "Knapsack"?
A: An enterprise design system platform that integrates design and code workflows.

Q: What is the "Spectrum" design system?
A: Adobe's open-source design system, multi-platform, with detailed accessibility guidance.

Q: What is "Material Design"?
A: Google's design system — widely adopted, defines components, motion, and elevation across platforms.

Q: What is "Carbon"?
A: IBM's open-source design system focused on enterprise productivity software.

Q: What is "Polaris"?
A: Shopify's design system for merchant-facing tools.

Q: What is "Lightning"?
A: Salesforce's design system for their platform and apps.

Q: What is "Fluent"?
A: Microsoft's design system, used across Office, Windows, and web products.

Q: What is "Primer"?
A: GitHub's design system, deeply integrated with their product surfaces.

Q: What is "Atlassian Design System"?
A: Atlassian's system supporting Jira, Confluence, and Trello with shared tokens and components.

Q: What is "the Design Systems Coalition"?
A: Cross-company community of design system practitioners sharing patterns, tools, and best practices.

Q: What is a "design system team"?
A: The group that maintains the system — often a small core team plus a broader federation model.

Q: What is the "federated" governance model?
A: Distributed contributors propose changes; a core team reviews and merges — scales beyond what one team can build.

Q: What is the "centralized" governance model?
A: A single team owns and ships the system — fastest decisions, lowest scale.

Q: What is the "hub-and-spoke" governance model?
A: A central core team plus embedded specialists in product teams — balances consistency and product fit.

Q: What is "open source" governance for an internal system?
A: Treating the system like an OSS project (PRs, issues, releases) — encourages contribution while preserving review.

Q: What is a "design system roadmap"?
A: A public plan for what the system will deliver next — sets expectations and invites coordination.

Q: What is a "design system OKR"?
A: Outcome-based goals (adoption rate, accessibility coverage, contribution volume) — moves the team beyond shipping components.

Q: What is an "adoption metric"?
A: Percentage of UI built with system components vs. ad-hoc UI — direct measure of system value capture.

Q: What is a "coverage metric"?
A: Percentage of product needs the system can serve out of the box — surface gaps to prioritize.

Q: What is "drift" in a design system?
A: Product UI diverging from the system over time — usually because the system was insufficient for real needs.

Q: What is "the parity gap"?
A: The difference between what Figma and code can produce — closing it reduces design-engineering friction.

Q: What is "design-to-code parity"?
A: Ensuring component variants, states, and tokens match exactly between Figma library and code library.

Q: What is "code-first design"?
A: Building components in code first and reflecting them in Figma — favored when engineering velocity dominates.

Q: What is "design-first design"?
A: Designing components in Figma first and implementing in code — favored when design exploration dominates.

Q: What is "Code Connect"?
A: A Figma feature mapping Figma components to code snippets — closes the design-code parity gap.

Q: What is "production-only components"?
A: Components that exist in code only because Figma doesn't need to represent them — e.g., infrastructure wrappers.

Q: What is "design-only components"?
A: Components that exist for design exploration but not yet in code — should be labeled "experimental" to prevent premature use.

Q: What is "release-train" for a design system?
A: Predictable release cadence (e.g., minor every 2 weeks, major quarterly) so consumers can plan upgrades.

Q: What is "semantic versioning" for a design system?
A: Major.Minor.Patch — major signals breaking changes, minor adds non-breaking features, patch fixes bugs.

Q: What is a "breaking change" in a design system?
A: Any change requiring consumer code changes — prop rename, prop removal, default change, behavioral shift.

Q: What is a "deprecation policy"?
A: The published policy for how long deprecated components remain available before removal — e.g., 1 major version with warning.

Q: What is "deprecation warning"?
A: A console message or visual indicator that a component is deprecated — gives consumers time to migrate.

Q: What is a "codemod"?
A: An automated transformation script that updates consumer code through a breaking change — reduces upgrade pain.

Q: What is "Storybook composition"?
A: Combining multiple Storybook projects into one site — letting consumers see system + product extensions together.

Q: What is "visual regression test"?
A: A test comparing rendered screenshots against a known-good baseline to catch unintended UI changes.

Q: What is "snapshot test"?
A: A test comparing serialized component output to a saved snapshot — catches structural changes.

Q: What is "interaction test"?
A: A test simulating user behavior (click, type, focus) — verifies component behavior, not just appearance.

Q: What is "accessibility test"?
A: An automated check for WCAG violations (axe-core) — catches a portion of issues; manual review still required.

Q: What is the "a11y" abbreviation?
A: Shorthand for "accessibility" — the 11 characters between "a" and "y".

Q: What is WCAG?
A: Web Content Accessibility Guidelines — the international standard for accessibility, organized by principles and conformance levels.

Q: What are the WCAG conformance levels?
A: A (must), AA (should), AAA (advanced) — most public systems target AA.

Q: What are the four WCAG principles?
A: Perceivable, Operable, Understandable, Robust (POUR) — every guideline maps to one.

Q: What is "color contrast ratio"?
A: The luminance ratio between text and background — WCAG AA requires 4.5:1 for normal text, 3:1 for large text.

Q: What is "focus visible"?
A: A clear visual indication of which element has keyboard focus — required for keyboard accessibility.

Q: What is "focus trap" in modals?
A: Keyboard focus loops within an open modal until it closes — prevents users from tabbing into hidden background content.

Q: What is "skip navigation link"?
A: A hidden link that appears on focus, letting keyboard users skip past header navigation — required for accessibility.

Q: What is "ARIA"?
A: Accessible Rich Internet Applications — a set of attributes (role, aria-*) that supplement HTML semantics for assistive tech.

Q: What is "the first rule of ARIA"?
A: Don't use ARIA if a native HTML element can do the job — native semantics are more reliable.

Q: What is "aria-label"?
A: An attribute providing an accessible name when visible text isn't available or doesn't describe the element's purpose.

Q: What is "aria-labelledby"?
A: An attribute pointing to another element whose text serves as the accessible name — preferred over aria-label when visible text exists.

Q: What is "aria-describedby"?
A: An attribute pointing to descriptive text that supplements the accessible name (e.g., helper text on a form input).

Q: What is "aria-live"?
A: An attribute marking a region as dynamic so screen readers announce updates (polite, assertive).

Q: What is a "screen reader"?
A: Assistive software that converts UI to speech or braille — major examples include NVDA, JAWS, VoiceOver.

Q: What is "keyboard accessibility"?
A: Ensuring every interactive element is reachable and operable via keyboard alone — basic accessibility requirement.

Q: What is "tab order"?
A: The sequence keyboard focus moves through interactive elements — should match visual order and be logical.

Q: What is a "logical tab order"?
A: Tab order follows the visual reading order; out-of-order tabbing disorients keyboard and screen reader users.

Q: What is "touch target size" guidance?
A: WCAG AA recommends at least 24x24 CSS pixels; mobile platforms recommend 44–48 to reduce mis-taps.

Q: What is "motion reduction"?
A: Respecting prefers-reduced-motion to disable or simplify animations for users who need it.

Q: What is "color contrast for non-text"?
A: WCAG AA requires 3:1 contrast for UI components (icons, focus indicators, form borders).

Q: What is "color-only conveyance" anti-pattern?
A: Using color alone to convey state (e.g., red dot for error) — must add an icon, text, or pattern for color-blind users.

Q: What is the "icon library" inside a design system?
A: A curated set of icons with consistent stroke, size, and naming — exposed as components.

Q: What is "icon usage guidance"?
A: Documentation on when to use which icon, paired labels, and minimum size — prevents misuse and inconsistency.

Q: What is "system component" vs. "product component"?
A: System components serve many products; product components serve one — usually built on top of system primitives.

Q: What is "composition over configuration"?
A: Designing components so behavior emerges from composing smaller pieces rather than from a giant prop API.

Q: What is a "compound component" pattern?
A: Components that work together via shared context (e.g., Tabs.List, Tabs.Tab) — flexible, intuitive API.

Q: What is a "slot pattern"?
A: Components accepting named children slots so consumers can compose flexibly without exposing every prop.

Q: What is a "render prop"?
A: A function-as-children pattern that lets consumers control rendering while inheriting behavior — powerful but less idiomatic in modern React.

Q: What is "headless component" pattern?
A: Components shipping only behavior (state, ARIA, keyboard) with consumer-supplied markup — used by Radix UI, Headless UI.

Q: What is "Radix UI"?
A: A popular headless component library providing accessible, unstyled primitives for React.

Q: What is "Headless UI"?
A: Tailwind Labs' headless component library with accessible primitives.

Q: What is "Reach UI"?
A: An earlier headless library by Ryan Florence focused on accessibility.

Q: What is "shadcn/ui"?
A: A pattern of copy-paste component recipes built on Radix and Tailwind — explicitly not a library, designed for customization.

Q: What is "Tailwind CSS"?
A: A utility-first CSS framework — composes design via class names; pairs well with headless components.

Q: What is "the utility-first" debate?
A: Whether design systems should expose components or utility classes — modern systems often blend both.

Q: What is "CSS-in-JS"?
A: Styling components via JavaScript (Emotion, styled-components) — flexible but with bundle and runtime cost.

Q: What is "CSS Modules"?
A: Locally scoped CSS classes per component — middle ground between global CSS and CSS-in-JS.

Q: What is "Vanilla Extract"?
A: A zero-runtime CSS-in-TypeScript library — type-safe styling compiled at build time.

Q: What is "Open Props"?
A: A collection of CSS custom properties forming an open-source design token set.

Q: What is a "design token JSON"?
A: The canonical token data structure consumed by Style Dictionary or similar — single source for all platforms.

Q: What is "Figma library"?
A: A shared Figma file containing the system's components, accessible by team members across files.

Q: What is "library publishing" in Figma?
A: Releasing a versioned update of the Figma library — analogous to npm publish for code.

Q: What is "variant" in a Figma component?
A: A configurable instance with named property values (size: sm/md/lg, variant: primary/secondary).

Q: What is "auto layout" in Figma?
A: A constraint system that mimics flexbox; components built with auto layout adapt to content.

Q: What is "constraints" in Figma?
A: Rules for how a layer behaves when its parent resizes — left/right/top/bottom/stretch.

Q: What is "Variable" in Figma?
A: Figma's native token primitive — values used across designs that can be theme-swapped.

Q: What is "Variable Mode"?
A: A swappable set of variable values per file, page, or frame — implements theming inside Figma.

Q: What is "Collection" in Figma Variables?
A: A grouping of variables (e.g., colors, spacing) with shared modes.

Q: What is "scoping" Figma Variables?
A: Restricting which properties a variable can bind to — prevents misuse.

Q: What is "Plugin API" for design systems?
A: Figma and Sketch expose APIs letting teams build custom tooling — checks, sync scripts, codegen.

Q: What is "linting" a design?
A: Automated checks against design conventions (color usage, spacing, naming) — catches drift early.

Q: What is "Tokens Studio sync"?
A: The workflow that syncs tokens between Figma and a Git repository, allowing both sides to stay aligned.

Q: What is "the design-system maturity model"?
A: A typical progression: ad hoc → style guide → component library → full design system → mature multi-platform system.

Q: What is "Stage 0" of design system maturity?
A: No shared system — every team builds their own UI from scratch.

Q: What is "Stage 1" of design system maturity?
A: A static style guide — colors, type, basic guidance; not built into code.

Q: What is "Stage 2" of design system maturity?
A: A coded component library — basic reusable components without strong docs or governance.

Q: What is "Stage 3" of design system maturity?
A: Full design system — tokens, components, patterns, accessibility, governance, contribution model.

Q: What is "Stage 4" of design system maturity?
A: Multi-platform / multi-brand / multi-product system with sophisticated tooling and a sustainable team.

Q: What is "the design system bus factor"?
A: How many people would need to leave before the system collapses — should be > 1.

Q: What is "the no-name component" problem?
A: Components without clear, consistent names confuse consumers and create duplication.

Q: What is a "component naming convention"?
A: Rules for how components are named (singular/plural, prefix, casing) — should be documented and enforced.

Q: What is a "component status"?
A: Lifecycle stage (experimental, beta, stable, deprecated) — sets consumer expectation.

Q: What is "experimental status"?
A: A component in active design or development; API may change without warning.

Q: What is "beta status"?
A: A component implemented but used in limited contexts; API is unlikely but may change.

Q: What is "stable status"?
A: A component that follows semver — breaking changes require a major release.

Q: What is "deprecated status"?
A: A component scheduled for removal — actively guides consumers to a replacement.

Q: What is "the changelog"?
A: A record of every change shipped, organized by version — required for consumer understanding.

Q: What is "the migration guide"?
A: Per-version documentation on how to upgrade through breaking changes — beats codemods alone.

Q: What is "the design system office hours"?
A: A standing time when system maintainers are available for product team questions — high-leverage support channel.

Q: What is "the design system slack/discord channel"?
A: A real-time channel for system support — usage patterns themselves reveal what to improve.

Q: What is "RFC" in a design system?
A: Request for Comments — a public proposal for a significant change inviting discussion before implementation.

Q: What is "design review" for system contributions?
A: A structured review meeting where new components or changes are critiqued against system principles.

Q: What is "code review" for system contributions?
A: Engineering review focused on API design, accessibility, performance, and consistency.

Q: What is "the contribution model"?
A: The documented path for product teams to propose, build, and merge changes into the system.

Q: What is "the inner-source approach"?
A: Treating the design system like an open-source project inside the company — open issues, public RFCs, transparent decisions.

Q: What is "the federation pattern"?
A: Allowing product teams to maintain their own extensions on top of the core system — extensions can later promote upstream.

Q: What is the "single source of truth" risk?
A: Forcing all decisions through one team creates bottlenecks; distributed authority with shared standards scales better.

Q: What is "the discoverability problem"?
A: Consumers can't find what already exists, so they rebuild it — solved by strong docs, search, and naming.

Q: What is "the search-first docs principle"?
A: Docs should be findable via the consumer's actual words, including misspellings and synonyms.

Q: What is "redirect-from-aliases"?
A: Mapping common alternative names (e.g., "modal" → "Dialog") to canonical doc pages — improves discoverability.

Q: What is "the API stability test"?
A: Reviewing a proposed component API against the question: "What changes would force a major version bump?"

Q: What is "the prop count smell"?
A: A component with too many props (often > 10) is usually trying to be many components — refactor with composition.

Q: What is "the boolean prop trap"?
A: Many booleans encode component variants poorly — use a string enum (variant="primary"|"secondary") instead.

Q: What is "the size prop convention"?
A: A consistent named size scale (xs, sm, md, lg, xl) across components — reduces cognitive load.

Q: What is "the as prop"?
A: A prop allowing the rendered HTML element to change (button as anchor) — supports semantic flexibility.

Q: What is "polymorphism" in component APIs?
A: Components that can render as different elements while preserving styling — common in modern React libraries.

Q: What is "the accessibility audit"?
A: A periodic deep review (often quarterly) confirming the system continues to meet accessibility standards.

Q: What is "the content audit"?
A: A periodic review of documentation freshness — outdated docs lose trust quickly.

Q: What is "the success story" practice?
A: Surfacing examples of teams shipping faster or better with the system — drives adoption and funding.

Q: What is the "showcase" practice?
A: Public examples of system components in real product UI — proves the system works at scale.

Q: What is the most important factor in design system success?
A: Real usage in real products — not the breadth of the catalog or the polish of the docs.

Q: What is the principle "make the right thing the easy thing"?
A: The system succeeds when using it is faster and easier than going around it — adoption follows ease.