UI/UX Design Design Systems & Accessibility Syllabus

Design Systems & Accessibility syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Design Systems & Accessibility in UI/UX Design, not a summary of it.

1. 1

   Design Systems Fundamentals

   4 topics

   • What Is a Design System
   • Atomic Design Methodology
   • Design Tokens
   • Component Libraries
2. 2

   Building & Maintaining Systems

   4 topics

   • Governance and Contribution Models
   • Documentation and Guidelines
   • Versioning and Adoption
   • Pattern Libraries and Style Guides
3. 3

   Accessibility (a11y)

   4 topics

   • WCAG Principles
   • Color Contrast and Visual Accessibility
   • Keyboard Navigation and Focus
   • Screen Readers and ARIA
4. 4

   Responsive & Multi-Platform Design

   4 topics

   • Mobile-First Design
   • Breakpoints and Adaptive Layouts
   • Platform Guidelines
   • Cross-Platform Consistency

Design Systems & Accessibility flashcards for UI/UX Design

21 of 50 cards from the Design Systems & Accessibility deck — real questions with worked answers.

1. What is a design system?

   A complete set of standards, reusable components, design tokens, patterns, and documentation that teams use to design and build products consistently at scale. It is a living product (not a one-off deliverable) combining a component library, style guide, usage guidelines, and governance processes.

2. How does a design system differ from a style guide and a component library?

   A style guide documents visual rules (color, type, tone); a component library is the coded set of reusable UI components; a design system encompasses both plus design tokens, patterns, principles, documentation, and governance — it is the entire ecosystem, not just one artifact.

3. List three key benefits a design system provides to a product organization.

   1) Consistency — unified UI/UX across products and teams; 2) Efficiency — reusable components reduce design and development time (build once, use everywhere); 3) Scalability and quality — easier onboarding, fewer bugs, and accessibility/brand standards baked in by default.

4. Who created the Atomic Design methodology, and what is its core idea?

   Brad Frost. Its core idea is that interfaces can be built compositionally from small, chemistry-inspired building blocks: atoms combine into molecules, molecules into organisms, which populate templates and finally pages.

5. Name the five levels of Atomic Design in order, from smallest to largest.

   1) Atoms — basic HTML elements (buttons, inputs, labels); 2) Molecules — simple groups of atoms functioning together (a search form); 3) Organisms — complex sections composed of molecules/atoms (a header); 4) Templates — page-level layouts with placeholder content; 5) Pages — templates filled with real content.

6. In Atomic Design, what distinguishes a template from a page?

   A template defines the page's underlying content structure and layout using placeholder content, while a page is a specific instance of a template filled with real, representative content — used to test whether the design holds up with actual data.

7. What are design tokens?

   Named, platform-agnostic variables that store atomic design decisions — colors, typography, spacing, sizing, shadows, motion durations — as the single source of truth. They are transformed into platform-specific formats (CSS variables, iOS, Android) so values stay consistent everywhere.

8. Describe the three common tiers of design tokens.

   1) Global/primitive tokens — raw values (e.g., blue-500 = #0055FF); 2) Alias/semantic tokens — reference primitives with meaning (e.g., color-action-primary = blue-500); 3) Component-specific tokens — scoped to a component (e.g., button-background = color-action-primary). Each tier references the one below it.

9. Why are semantic (alias) design tokens preferred over hard-coded values in components?

   Because they encode intent rather than appearance: changing a brand color or supporting theming (e.g., dark mode) requires updating only the token mapping, and every component that references the semantic token updates automatically — enabling consistency and easy re-theming.

10. What is a component library in a design system?

    A collection of reusable, pre-built and pre-tested UI components (buttons, inputs, modals, cards) with defined props, variants, and states, implemented in code (and mirrored in design tools) so teams can assemble interfaces without rebuilding common elements.

11. What component states should a well-specified design system component define?

    At minimum: default, hover, active/pressed, focus, disabled, and where relevant loading, error, and selected states — each with defined visual treatment so behavior is consistent and accessible across the product.

12. What is the difference between a component and a pattern in a design system?

    A component is a single reusable UI element (e.g., a button or date picker); a pattern is a reusable solution to a recurring design problem that combines multiple components and behaviors (e.g., form validation, onboarding flow, empty states).

13. Compare the three main governance/contribution models for design systems.

    1) Centralized — one dedicated team owns and builds the system (high consistency, potential bottleneck); 2) Federated/distributed — contributors from multiple product teams share ownership (broad buy-in, harder coordination); 3) Hybrid — a small core team maintains standards while accepting contributions from product teams (most common at scale).

14. What does a typical contribution process to a design system look like?

    Propose (submit need/idea with use cases) → review (core team evaluates fit, reuse potential, duplication) → design and build to system standards (tokens, accessibility, documentation) → review/QA → merge, version, document, and announce the release.

15. What criteria are commonly used to decide whether a new component belongs in a design system?

    Reusability (needed by multiple teams/products, typically 2–3+ use cases), alignment with existing patterns and principles, no duplication of an existing component, and feasibility of maintaining it — one-off, product-specific elements stay local.

16. What should the documentation for a single design-system component include?

    Purpose and description, anatomy, variants and states, do/don't usage guidelines, content/writing guidance, accessibility requirements (keyboard, ARIA, contrast), code examples and API/props, and design specs (spacing, tokens used).

17. Why are 'do and don't' examples considered a documentation best practice in design systems?

    They show correct and incorrect usage side by side with visual examples, making guidelines scannable and unambiguous, reducing misuse and support questions far more effectively than prose rules alone.

18. Name common tools used to document and showcase design-system components.

    Storybook (interactive coded component explorer), zeroheight and Supernova (documentation sites synced with design tools), Figma libraries for design assets, and custom documentation sites (e.g., Material.io, Polaris, Carbon).

19. How does semantic versioning (SemVer) work for a design system release numbered MAJOR.MINOR.PATCH?

    MAJOR increments for breaking changes (consumers must update their code), MINOR for backwards-compatible new features (new components/variants), PATCH for backwards-compatible bug fixes. Example: going from 2.3.1 to 3.0.0 signals a breaking change.

20. What strategies help drive adoption of a design system across teams?

    Executive sponsorship, clear migration guides and codemods, deprecation warnings with transition periods, measuring adoption metrics (component coverage, detachment rates), office hours/support channels, showcasing wins, and making the system easier to use than building custom.

21. What is a deprecation policy in design-system versioning, and why does it matter?

    A defined process for phasing out components/tokens: mark as deprecated, warn consumers, provide a replacement and migration path, and remove only in a later major release. It matters because it lets teams upgrade predictably without sudden breakage, preserving trust in the system.

See more Design Systems & Accessibility flashcards →

Planning Design Systems & Accessibility for UI/UX Design

Design Systems & Accessibility (UI/UX Design) FAQ