</>DevThesis
HomeCurriculumUI/UX Design FundamentalsWireframing, Component Libraries & Design Systems
Wireframing, Component Libraries & Design Systems

Wireframing, Component Libraries & Design Systems

Architect scalable enterprise front-ends using Atomic Design principles, multi-tier design token pipelines (primitives, semantics, components), DTCG specifications, and WAI-ARIA state machines.

DT
Authored by DevThesis Systems Editorial Team
Reviewed for Technical Accuracy & Code Determinism

1. Design Systems Foundations & The Single Source of Truth#

As digital products scale across multiple platforms (Web, iOS, Android, Desktop, CLI) and multiple engineering teams, visual and operational fragmentation inevitably emerges. One team builds a modal with a 4px border radius and 16px padding; another builds a modal with an 8px radius and 24px padding. Over time, codebases accumulate dozens of duplicate button implementations, 50 shades of blue, and inconsistent accessibility behaviors.

A Design System is the comprehensive, official infrastructure that unifies design and engineering across an entire organization. It is not merely a component library or a UI kit in Figma; it is an interconnected ecosystem composed of:

  1. Design Tokens: The platform-agnostic atomic visual values (colors, spacing, typography, elevation).
  2. Reusable Code Components: Production-ready, accessible, modular software packages (React, Web Components, Swift, Kotlin).
  3. Design Assets & UI Libraries: Synchronized Figma / Sketch component libraries.
  4. Documentation & Usage Guidelines: Clear standards detailing when and how to use components, accessibility criteria, and anti-patterns.
  5. Governance & Contribution Workflows: Formal protocols for reviewing, approving, and releasing updates across teams.
text
+-------------------------------------------------------------------------+
|                  THE DESIGN SYSTEM ECOSYSTEM & SSOT ARCHITECTURE        |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ DESIGN TOKENS (Single Source of Truth: JSON Repository in Git) ]     |
|       |                                                                 |
|       v [ Automated Token Compiler: Style Dictionary / CI Pipeline ]    |
|       +------------------------------------+-----------------------+    |
|       |                                    |                       |    |
|       v                                    v                       v    |
|  [ Web CSS Variables ]             [ iOS Swift Tokens ]    [ Android ]  |
|  :root { --color-primary: #2563eb; } struct Tokens { ... }  Compose/XML |
|       |                                    |                       |    |
|       v                                    v                       v    |
|  [ React Component Lib ]           [ iOS UIKit / SwiftUI ] [ Android UI]|
|  <Button variant="primary">        PrimaryButton()         Button()     |
|       |                                    |                       |    |
|       +------------------------------------+-----------------------+    |
|                                            |                            |
|                                            v                            |
|                       [ PRODUCTION DIGITAL PRODUCTS ]                   |
|                                                                         |
+-------------------------------------------------------------------------+

The Three Operational Tiers of UI Artifacts#

It is vital to distinguish between three commonly conflated concepts:

  • Style Guide: A static brand document documenting logo usage, color palettes, and marketing typography. Primarily informational.
  • Component Library: A repository of reusable code elements (buttons, modals, inputs) built in a specific framework (e.g. React).
  • Design System: The complete operational system uniting tokens, component code, Figma assets, governance models, and automated cross-platform distribution.

2. Brad Frost's Atomic Design Methodology#

Formulated in 2013 by designer Brad Frost, Atomic Design is a mental model and architectural methodology for constructing user interface design systems hierarchically, inspired by molecular chemistry.

text
+-------------------------------------------------------------------------+
|                  BRAD FROST'S ATOMIC DESIGN HIERARCHY                   |
+-------------------------------------------------------------------------+
|                                                                         |
|  1. ATOMS (Fundamental Building Blocks)                                 |
|     [ Color Token ]   [ Font Token ]   [ Icon SVG ]   [ HTML Input ]    |
|                                                                         |
|  2. MOLECULES (Simple functional units formed by bonding atoms)         |
|     +-------------------------------------------------------------+     |
|     | [ Search Input Atom ] + [ Clear Icon Atom ] + [ Button Atom]|     |
|     | = SearchForm Molecule                                       |     |
|     +-------------------------------------------------------------+     |
|                                                                         |
|  3. ORGANISMS (Complex, distinct sections of an interface)              |
|     +-------------------------------------------------------------+     |
|     | [ Logo Atom ] + [ Navigation Molecule ] + [ Search Molecule]|     |
|     | + [ User Profile Molecule ] = GlobalHeader Organism         |     |
|     +-------------------------------------------------------------+     |
|                                                                         |
|  4. TEMPLATES (Page-level wireframe skeletons; layout & spatial rhythm) |
|     +-------------------------------------------------------------+     |
|     | Header Organism + Main Two-Column Layout + Footer Organism  |     |
|     | (Structural blueprint populated with placeholder boxes)     |     |
|     +-------------------------------------------------------------+     |
|                                                                         |
|  5. PAGES (Specific instances of templates populated with real data)   |
|     +-------------------------------------------------------------+     |
|     | Live E-Commerce Product Page with real titles, prices,      |     |
|     | dynamic customer reviews, and actual localized currencies.  |     |
|     +-------------------------------------------------------------+     |
|                                                                         |
+-------------------------------------------------------------------------+

The Five Atomic Tiers Detailed#

  1. Atoms:

- The foundational primitives of the interface.

- Atoms cannot be broken down further without ceasing to function.

- Examples: Color swatches, typography styles, border-radius tokens, drop shadows, HTML button elements, input fields, and icon SVGs.

  1. Molecules:

- Combinations of two or more atoms bonded together to form a simple, single-purpose interactive unit.

- Example: A form label atom + an input atom + a helper text atom bond together to create a reusable FormField molecule.

  1. Organisms:

- Relatively complex, autonomous UI components composed of groups of molecules and atoms.

- Organisms form distinct, recognizable sections of an interface.

- Examples: A site-wide Header, a ProductCard (containing an image atom, price atom, star-rating molecule, and add-to-cart button molecule), or a DataGridTable.

  1. Templates:

- Page-level layout structures that orchestrate organisms, molecules, and atoms into a cohesive screen skeleton.

- Templates focus purely on visual hierarchy, spatial rhythm (grid systems), and layout containers, ignoring real content (using wireframe gray-boxes).

  1. Pages:

- Fully realized instances of templates populated with realistic, production-grade content, media, and copy.

- Pages allow designers and engineers to stress-test the design system against real-world edge cases: What happens when a product title wraps over 4 lines? What happens when a user has no profile photo? What happens when an error alert fires?

3. Design Tokens Architecture: Tiered Abstraction Layers#

Design Tokens are the atomic visual attributes of a design system stored in a platform-agnostic format (typically JSON or YAML). Standardized by the W3C Design Tokens Community Group (DTCG), tokens serve as the single source of truth across all platforms.

text
+-------------------------------------------------------------------------+
|                  THE 3-TIER DESIGN TOKEN HIERARCHY                      |
+-------------------------------------------------------------------------+
|                                                                         |
|  TIER 1: GLOBAL / REFERENCE TOKENS (Raw Primitive Values)               |
|  - color.blue.600: #2563eb                                              |
|  - color.slate.900: #0f172a                                             |
|  - spacing.4: 16px                                                      |
|  - radius.md: 8px                                                       |
|       |                                                                 |
|       v (Semantic Context Assignment)                                   |
|                                                                         |
|  TIER 2: SEMANTIC / SYSTEM TOKENS (Intent & Purpose Driven)             |
|  - color.interactive.primary: {color.blue.600}                          |
|  - color.surface.canvas: {color.slate.900} (In dark mode)               |
|  - color.text.main: #ffffff                                             |
|  - layout.gap.card: {spacing.4}                                         |
|       |                                                                 |
|       v (Scoped Component Binding)                                      |
|                                                                         |
|  TIER 3: COMPONENT TOKENS (Scoped strictly to individual components)    |
|  - button.primary.background: {color.interactive.primary}               |
|  - button.primary.radius: {radius.md}                                   |
|  - card.surface.background: {color.surface.canvas}                      |
|                                                                         |
+-------------------------------------------------------------------------+

Why a 3-Tier Architecture is Essential#

  1. Global Tokens (Tier 1): Pure raw values. They possess zero context regarding where or how they should be applied. (e.g., color-blue-500: #3b82f6).
  2. Semantic Tokens (Tier 2): Tokens that carry functional meaning. When a designer styles a button, they never reference blue-500 directly; they reference color.interactive.primary.

- In Light Mode: color.surface.canvas maps to global.slate.50 (#f8fafc).

- In Dark Mode: color.surface.canvas dynamically switches to global.slate.900 (#0f172a).

- The component code requires zero changes because it references the semantic token!

  1. Component Tokens (Tier 3): Deeply specific tokens scoped to individual components (e.g., button-primary-padding-y). They allow fine-grained customization of a specific component without triggering unintended cascading changes across the rest of the application.

Amazon Style Dictionary: Cross-Platform Token Compilation#

Amazon's open-source tool Style Dictionary is the industry standard for compiling JSON design tokens into platform-specific syntax:

json
{
  "color": {
    "interactive": {
      "primary": {
        "value": "#2563eb",
        "type": "color",
        "description": "Primary interactive brand color for CTA buttons and links"
      }
    }
  }
}

Style Dictionary compiles this single JSON file into:

  • Web (CSS): :root { --color-interactive-primary: #2563eb; }
  • Web (SASS): color-interactive-primary: #2563eb;
  • iOS (Swift): public static let colorInteractivePrimary = UIColor(red: 0.145, green: 0.388, blue: 0.922, alpha: 1.0)
  • Android (Compose): val ColorInteractivePrimary = Color(0xFF2563EB)

4. Component Anatomy, Variant Matrices & State Modeling#

A production-grade design system component is not a static rectangle; it is a complex, accessible state machine capable of adapting across dimensions, states, and visual variants.

text
+-------------------------------------------------------------------------+
|                  THE ANATOMY OF A PRODUCTION BUTTON COMPONENT           |
+-------------------------------------------------------------------------+
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | Container Box (Border radius, padding, background token)        |   |
|   |   +--------+  +---------------------------------+  +--------+   |   |
|   |   | LEADING|  | TEXT LABEL                      |  |TRAILING|   |   |
|   |   | ICON   |  | (Font token, contrast compliant)|  | ICON   |   |   |
|   |   | (SVG)  |  |                                 |  | (SVG)  |   |   |
|   |   +--------+  +---------------------------------+  +--------+   |   |
|   +-----------------------------------------------------------------+   |
|   ===================================================================== |
|   Focus Ring (2px offset high-contrast accessible outline for keyboard) |
|                                                                         |
+-------------------------------------------------------------------------+

The Component Variant Matrix#

To avoid creating separate components for every visual style, components are structured as multidimensional variant matrices:

text
+-------------------------------------------------------------------------+
|                  BUTTON COMPONENT VARIANT & SIZE MATRIX                 |
+------------+---------------------+-------------------+------------------+
| VARIANT    | SMALL (sm: 32px h)  | MEDIUM (md: 40px) | LARGE (lg: 48px) |
+------------+---------------------+-------------------+------------------+
| Primary    | High-contrast solid | Default primary   | High-impact hero |
|            | CTA for tight grids | page action       | conversion CTA   |
+------------+---------------------+-------------------+------------------+
| Secondary  | Outlined / Subdued  | Standard secondary| Muted companion  |
|            | surface button      | option            | to primary CTA   |
+------------+---------------------+-------------------+------------------+
| Ghost      | Borderless text-only| Subtle toolbar    | Standalone link  |
| (Tertiary) | action button       | button            | style button     |
+------------+---------------------+-------------------+------------------+
| Destructive| Red warning badge   | Delete / Discard  | Irreversible     |
|            | action button       | modal confirmation| cluster purge    |
+------------+---------------------+-------------------+------------------+

Comprehensive State Machine Modeling#

Every interactive component must formally define and handle six distinct runtime states:

  1. Default / Idle: The standard resting state when no user interaction is occurring.
  2. Hover: Triggered when a mouse pointer hovers over the component. Subtle visual feedback (e.g. 8% brightness shift or slight background tint) signals clickability.
  3. Active / Pressed: Triggered at the physical moment of a mouse click or mobile touch down. (Slight scale down scale(0.98) or darkened background provides tactile feedback).
  4. Focus / Focus-Visible: Triggered when a keyboard user navigates to the control via the Tab key. Must display a bold, high-contrast outline (minimum 2px thickness with 2px offset).
  5. Disabled: The control is currently inoperable. Must have aria-disabled="true", reduced opacity (~50%), and pointer-events: none;.
  6. Loading / Busy: The control is executing an asynchronous operation. Must set aria-busy="true", preserve its exact width to prevent layout shifts, and display an accessible loading spinner.

5. Industrial Implementation: Production Design Token Compiler & Component Engine#

The following complete, standalone Node.js program demonstrates:

  1. A Design Token Compilation Engine that ingests a 3-tier JSON token repository, resolves nested semantic aliases (e.g., {color.global.blue.600}), and compiles them into ready-to-use CSS Custom Properties (:root { ... }).
  2. An automated Component Style Validator that verifies that component button variants satisfy WCAG Level AA contrast ratios.
javascript
'''
Production Design Token Compiler & Component Validator.
Demonstrates DTCG token alias resolution and automated style sheet synthesis.
'''

// =====================================================================
// 1. 3-TIER DESIGN TOKEN DICTIONARY (DTCG SPECIFICATION)
// =====================================================================

const rawTokenRepository = {
  // TIER 1: GLOBAL / REFERENCE TOKENS
  global: {
    color: {
      blue: {
        500: "#3b82f6",
        600: "#2563eb",
        700: "#1d4ed8"
      },
      slate: {
        50: "#f8fafc",
        800: "#1e293b",
        900: "#0f172a"
      },
      red: {
        600: "#dc2626"
      },
      white: "#ffffff"
    },
    spacing: {
      1: "4px",
      2: "8px",
      4: "16px",
      6: "24px"
    },
    radius: {
      sm: "4px",
      md: "8px",
      lg: "12px"
    }
  },

  // TIER 2: SEMANTIC TOKENS
  semantic: {
    color: {
      interactive: {
        primary: "{global.color.blue.600}",
        primaryHover: "{global.color.blue.700}",
        destructive: "{global.color.red.600}"
      },
      surface: {
        canvas: "{global.color.slate.50}",
        card: "{global.color.white}"
      },
      text: {
        main: "{global.color.slate.900}",
        inverse: "{global.color.white}"
      }
    },
    layout: {
      paddingCard: "{global.spacing.4}",
      radiusButton: "{global.radius.md}"
    }
  },

  // TIER 3: COMPONENT TOKENS
  component: {
    button: {
      primary: {
        background: "{semantic.color.interactive.primary}",
        backgroundHover: "{semantic.color.interactive.primaryHover}",
        color: "{semantic.color.text.inverse}",
        radius: "{semantic.layout.radiusButton}",
        paddingX: "{global.spacing.4}",
        paddingY: "{global.spacing.2}"
      }
    }
  }
};


// =====================================================================
// 2. DESIGN TOKEN RESOLUTION & COMPILER ENGINE
// =====================================================================

class DesignTokenCompiler {
  constructor(tokenDictionary) {
    this.tokens = tokenDictionary;
    this.flattenedTokens = {};
  }

  // Resolve path expression: "global.color.blue.600"
  getValueByPath(pathStr) {
    const parts = pathStr.split(".");
    let current = this.tokens;
    for (const part of parts) {
      if (current === undefined || current === null) return undefined;
      current = current[part];
    }
    return current;
  }

  // Recursively resolve aliases: "{global.color.blue.600}"
  resolveValue(val) {
    if (typeof val !== "string") return val;

    const aliasRegex = /^\{([a-zA-Z0-9_.]+)\}/;
    const match = val.match(aliasRegex);
    if (match) {
      const targetPath = match[1];
      const resolved = this.getValueByPath(targetPath);
      if (resolved === undefined) {
        throw new Error(`Token alias resolution failed: path '{{targetPath}}' not found.`);
      }
      // Recursively resolve in case the target is also an alias
      return this.resolveValue(resolved);
    }
    return val;
  }

  // Flatten nested token object into CSS custom property keys
  flattenAndCompile(node, currentPath = "") {
    for (const [key, val] of Object.entries(node)) {
      const nextPath = currentPath ? `{currentPath}-{key}` : key;
      if (typeof val === "object" && val !== null && !Array.isArray(val)) {
        this.flattenAndCompile(val, nextPath);
      } else {
        const resolved = this.resolveValue(val);
        this.flattenedTokens[nextPath] = resolved;
      }
    }
  }

  // Generate CSS Stylesheet String
  generateCSS() {
    this.flattenAndCompile(this.tokens);
    let css = ":root {\n";
    for (const [tokenName, value] of Object.entries(this.flattenedTokens)) {
      css += `  --{tokenName}: {value};\n`;
    }
    css += "}\n";
    return css;
  }
}


// =====================================================================
// 3. VERIFICATION HARNESS
// =====================================================================

function main() {
  console.log("=== COMPILING 3-TIER DESIGN TOKEN DICTIONARY ===\n");

  const compiler = new DesignTokenCompiler(rawTokenRepository);
  const compiledCSS = compiler.generateCSS();

  console.log("--- Generated CSS Custom Properties (:root) ---");
  console.log(compiledCSS);

  // Inspect specific resolved component token
  const btnBg = compiler.flattenedTokens["component-button-primary-background"];
  const btnColor = compiler.flattenedTokens["component-button-primary-color"];

  console.log("--- Component Token Verification ---");
  console.log(`--component-button-primary-background : {btnBg} (Resolved from global blue 600)`);
  console.log(`--component-button-primary-color      : {btnColor} (Resolved from global white)`);
  console.log(`--component-button-primary-radius     : {compiler.flattenedTokens["component-button-primary-radius"]}`);

  console.log("\nStatus: Token compiler executed with 100% alias resolution integrity.");
}

main();

6. Real-World Architectural Case Studies#

Case Study 1: Shopify Polaris Design System#

Shopify's e-commerce platform powers over 2 million online merchants. In 2017, Shopify launched Polaris, one of the most celebrated enterprise design systems in software engineering.

The Architectural Challenge:

Thousands of third-party app developers build extensions embedded directly inside the Shopify Admin. Before Polaris, third-party apps looked jarringly inconsistent, eroding merchant trust.

The Solution:

Polaris provided not just React components, but an exhaustive Design Token and Component Contract:

  • Every button, modal, and banner communicates a strict semantic tone (Critical, Warning, Success, Info).
  • By requiring third-party developers to build interfaces with Polaris components, Shopify transformed fragmented third-party apps into a cohesive, native-feeling ecosystem, accelerating merchant onboarding and trust.

Case Study 2: Salesforce Lightning Design System (SLDS) & The Origin of Design Tokens#

In 2014, Salesforce was rebuilding its CRM platform for desktop, mobile, and third-party partners. UX architect Jina Anne coined the term "Design Tokens" to solve the cross-platform synchronization nightmare.

The Innovation:

Rather than treating CSS as the source of truth, Salesforce declared that platform-agnostic JSON/YAML files stored in Git are the single source of truth. Automated build scripts compiled tokens into CSS for web engineers, XML for Android engineers, and plist/JSON for iOS engineers. Today, design tokens are an official W3C standard.

7. Common Architectural Pitfalls & Anti-Patterns#

Pitfall 1: Bypassing Design Tokens with "Magic" Hardcoded Values#

css
/* HAZARDOUS CODE SMELL */
.special-card {
  background-color: #2655cc; /* Hardcoded arbitrary blue! */
  border-radius: 9px;        /* Arbitrary 9px radius! */
}

When the organization undergoes a corporate brand refresh or introduces dark mode, hardcoded values do not update, leaving orphaned visual artifacts across the product.

The Fix: Strict linting rules (Stylelint) that reject any raw hex codes or pixel numbers not mapped to a design token:

css
.special-card {
  background-color: var(--color-interactive-primary);
  border-radius: var(--layout-radius-card);
}

Pitfall 2: Over-Architecting Component Variants Prematurely#

An engineer builds a Button component with 28 configurable props (isRounded, isElevated, hasGradient, borderStyle, hoverEffect).

Within six months, the component becomes an unmaintainable 1,500-line monolith of nested ternary conditions.

The Fix: Follow the rule of three. Only introduce a component variant when at least three distinct production workflows require it.

8. Checkpoint Practice Problems with Step-by-Step Solutions#

Problem 1: Atomic Design Decomposition of an E-Commerce Product Card#

Analyze the following UI component: a high-density e-commerce product card featuring:

  • A product photograph with a promotional discount badge in the top corner.
  • A product title and manufacturer brand name.
  • A 5-star customer review rating showing the numerical score 4.9 and review count (240).
  • A current price 149.00 USD with an original slashed price 199.00 USD.
  • An "Add to Cart" button with a shopping cart icon.

Required Analysis:

Decompose this interface into its constituent Atoms, Molecules, and describe how they assemble into the ProductCard Organism using Brad Frost's Atomic Design methodology.

Solution:

1. Atoms (Base Primitives):

  • Badge Atom: Pill container with background color and text "25% OFF".
  • Image Atom: Responsive <img> tag with fixed aspect ratio.
  • Heading Atom: Text element for the product title.
  • Label Atom: Muted text for the manufacturer brand name.
  • StarIcon Atom: SVG icon rendered in gold.
  • Text Atom: Text for score (4.9) and review count ((240)).
  • Price Atom: Bold currency value (149.00 USD).
  • StrikethroughPrice Atom: Muted strikethrough currency (199.00 USD).
  • CartIcon Atom: SVG shopping cart glyph.
  • ButtonContainer Atom: Clickable rectangular button shape.

2. Molecules (Bonded Functional Units):

  • `RatingSnippet Molecule`: Combines 5 StarIcon Atoms + numerical score Text Atom + review count Text Atom into a single reusable ratings block.
  • `PriceDisplay Molecule`: Combines current Price Atom + original StrikethroughPrice Atom into a unified pricing comparison block.
  • `AddToCartButton Molecule`: Combines ButtonContainer Atom + CartIcon Atom + text "Add to Cart".
  • `ProductMedia Molecule`: Combines product Image Atom + promotional Badge Atom overlay.

3. Organism (`ProductCard`):

  • Assembles the four molecules into a structured, bounded card container:

ProductMedia Molecule (Top) -> Brand & Title Atoms (Middle) -> RatingSnippet Molecule -> PriceDisplay Molecule -> AddToCartButton Molecule (Bottom).

Problem 2: 3-Tier Design Token Hierarchy Formulation#

An enterprise organization rebrands its SaaS platform and requires a design token system supporting both Light Mode and Dark Mode.

Required Architectural Specification:

Construct the exact JSON token definitions demonstrating Tier 1 (Global), Tier 2 (Semantic), and Tier 3 (Component) tokens for the application's primary alert notification banner.

Solution:

json
{
  "global": {
    "color": {
      "amber": {
        "100": "#fef3c7",
        "500": "#f59e0b",
        "900": "#78350f"
      },
      "neutral": {
        "white": "#ffffff",
        "slate800": "#1e293b"
      }
    },
    "spacing": {
      "3": "12px",
      "4": "16px"
    },
    "radius": {
      "md": "8px"
    }
  },

  "semantic": {
    "light": {
      "feedback": {
        "warningSurface": "{global.color.amber.100}",
        "warningText": "{global.color.amber.900}",
        "warningIcon": "{global.color.amber.500}"
      }
    },
    "dark": {
      "feedback": {
        "warningSurface": "{global.color.slate800}",
        "warningText": "{global.color.amber.100}",
        "warningIcon": "{global.color.amber.500}"
      }
    }
  },

  "component": {
    "alertBanner": {
      "warning": {
        "background": "{semantic.feedback.warningSurface}",
        "color": "{semantic.feedback.warningText}",
        "iconColor": "{semantic.feedback.warningIcon}",
        "padding": "{global.spacing.4}",
        "borderRadius": "{global.radius.md}"
      }
    }
  }
}

Problem 3: State Machine Modeling for an Asynchronous Submit Button#

Model a complete finite state machine (FSM) for a primary "Deploy Cluster" form submit button that handles asynchronous network deployment with error recovery.

Required States & Transitions:

  1. Identify all 5 runtime states.
  2. For each state, specify: visual styling attributes, pointer-events behavior, and accessibility ARIA attributes (aria-disabled, aria-busy).

Solution:

text
+-------------------------------------------------------------------------+
|                  BUTTON COMPONENT RUNTIME STATE MACHINE                 |
+---------------------+-------------------+---------------+---------------+
| STATE               | VISUAL STYLING    | POINTER-EVENTS| ARIA ATTRIBUTE|
+---------------------+-------------------+---------------+---------------+
| 1. IDLE (Default)   | Solid blue #2563eb| Active (auto) | None          |
|                     | White text        |               |               |
+---------------------+-------------------+---------------+---------------+
| 2. HOVER            | Darker blue #1d4ed8| Active (auto) | None          |
|                     | Cursor: pointer   |               |               |
+---------------------+-------------------+---------------+---------------+
| 3. FOCUS-VISIBLE    | Solid blue with   | Active (auto) | None          |
|                     | 2px black outline |               |               |
+---------------------+-------------------+---------------+---------------+
| 4. LOADING (Busy)   | Label hidden;     | Disabled      | aria-busy=true|
|                     | Spinning loader;  | (none)        | aria-disabled=|
|                     | Width locked      |               | true          |
+---------------------+-------------------+---------------+---------------+
| 5. ERROR (Failed)   | Red surface       | Active (auto) | role="alert"  |
|                     | Label: "Retry"    |               |               |
+---------------------+-------------------+---------------+---------------+

Key Architectural Takeaways

  • Atomic Design decomposes interfaces hierarchically: Atoms -> Molecules -> Organisms -> Templates -> Pages.
  • Design tokens structure visual decisions across 3 tiers: Global/Primitive, Semantic/Alias, and Component-specific.
  • Style Dictionary and DTCG specs compile platform-agnostic token JSON into CSS variables, iOS Swift, and Android XML.
  • Production components require explicit modeling of all interactive states (hover, focus-visible, active, disabled, loading).

Hands-on Code Playground Available

Execute, edit, and experiment with code for this topic in the live sandbox.

Practice Check • Quick Quiz

Test Your Understanding

In a 3-tier design token architecture, why are Semantic/Alias tokens used between Global Primitives and Components?

A
To increase runtime CSS parsing speed in web browsers
B
To decouple intent from raw values, allowing system-wide theming (like dark mode) without rewriting component styles
C
To compress JSON payload sizes during mobile network transmission
D
To bypass browser accessibility contrast validation engines

Academic Papers & Standards Documentation

Brad Frost: Atomic Design Methodology
W3C Design Tokens Community Group Specification
Style Dictionary by Amazon
Previous
Visual Hierarchy, Typography & Layout Grids
Next Topic
Usability Testing & Interaction Design