Design Systems and Tokens 2025 — Complete Guide: Radix, shadcn/ui, Chakra, Tamagui, Park UI, Ark UI, DaisyUI Compared, the W3C Design Tokens Standard, Figma Variables and Tokens Studio Integration, Component API Design, Accessibility, and Korean Enterprise Case Studies — Season 6 Ep 2

Prologue — A Design System Is Not CSS

Starting around 2020, every organization launched a "design system initiative." By 2025, the line between successful systems and failed systems is sharply drawn.

• Failed systems: just a CSS or component library that nobody uses.
• Successful systems: a shared language for the org — designers, engineers, and PMs use the same words.

Three common misconceptions:

1. "Design system = component library" (wrong)
2. "Design system = the design team's job" (wrong)
3. "Design system = a Figma file" (wrong)

The truth:

Design system = tokens + components + patterns + docs + governance. And a system that expresses all of this identically across Figma, code, and Storybook.

2024–2025 was the year Figma Variables and the W3C Design Tokens Community Group standard settled in, and Design-to-Code integration finally became practical. This post is the map of that terrain.

Chapter 1 — The Five Layers of a Design System

A mature design system has five layers.

Layer 1: Primitive Tokens

• Raw values for color, typography, spacing, radius, and shadow.
• Examples: color-slate-500 = #64748b, space-2 = 8px.

Layer 2: Semantic Tokens

• Assign intent to primitives.
• Examples: color-surface-primary, color-text-muted, color-border-critical.
• Essential for theme switching (light/dark).

Layer 3: Component Tokens

• Tokens scoped to specific components.
• Examples: button-primary-bg, card-shadow-hover.

Layer 4: Components

• Actual UI pieces: Button, Input, Card, Dialog, etc.
• Accessibility and keyboard navigation built in.

Layer 5: Patterns

• Rules for composing components and laying out pages.
• Examples: "error state pattern", "empty state pattern".

Why Three Token Tiers?

If you only use Primitives

• Adding dark mode requires editing every component.
• Rebranding means sweeping changes.

With Semantics in between

• Swap only color-surface-primary for its dark-mode value and every consumer updates automatically.
• Essential as the organization grows.

Chapter 2 — The 2025 Landscape of Component Libraries

(1) Radix UI (Primitives)

• Headless (unstyled) with excellent accessibility.
• Ships complex patterns: Dialog, Popover, Select, Tooltip.
• The foundation of shadcn/ui.
• Near-perfect WAI-ARIA implementation.

(2) shadcn/ui

• "Don't install it — copy it."
• Radix under the hood, Tailwind for styling.
• You own each component (copy into your own repo).
• Most popular choice in 2024–2025.
• Unlimited freedom to extend and customize.
• CLI (npx shadcn add button) for convenience.
• Has become something like the default for Korean startups.

(3) Chakra UI

• Polished and complete, Styled + accessible.
• sx prop for inline styles.
• Favored by enterprises for rapid development.

(4) Tamagui

• React Native + Web simultaneously.
• Compile-time optimization for strong performance.
• Ideal for cross-platform apps.

(5) Park UI (CVA-based)

• Ark UI + Panda CSS + Class Variance Authority.
• Oriented toward design-system builders.

(6) Ark UI

• Headless, built on Zag.js (state machines).
• Supports React, Solid, and Vue.
• A multi-framework alternative to Radix.

(7) DaisyUI

• A Tailwind-based Styled library.
• Powerful theme system.
• CSS-first with minimal JS dependency.

(8) Mantine

• Similar in scope to Chakra.
• Rich add-ons: forms, data tables, notifications.

(9) HeroUI (formerly NextUI)

• Modern design on React + Tailwind.
• Animations built in.

(10) Enterprise: Ant Design, Material UI (MUI), Fluent UI

• For large orgs or inherited legacy.
• For new projects in 2024–2025, the shadcn family tends to win.

Head-to-head Comparison

Chapter 3 — Headless vs Styled: Which Should You Pick?

Headless (Radix, Ark, React Aria)

• Behavior and accessibility only; zero styles.
• Pros: total design freedom; full brand expression.
• Cons: 100% of the styling burden is yours.
• Fits: teams building their own design system.

Styled (Chakra, MUI, Ant, Mantine)

• Pre-designed components.
• Pros: fast shipping; baseline quality guaranteed.
• Cons: limited brand individuality; override fatigue.
• Fits: B2B SaaS and internal tools.

Hybrid (shadcn/ui, DaisyUI)

• Headless engine with starter styles.
• Transfers ownership to you (shadcn).
• Pros: fast start + full customization.
• The mainstream choice in 2024–2025.

How to Decide

Pick Headless when

• Brand is core to visual identity (luxury, creative brands).
• You obsess over accessibility and animation.
• Your engineers and designers can build a design system themselves.

Pick Styled when

• You're building a B2B admin dashboard.
• Time-to-market is the top priority.
• Function matters more than brand.

Pick Hybrid (shadcn) when

• You're a typical startup or product team.
• You want to start fast and customize as you grow.

Chapter 4 — The W3C Design Tokens Standard

In 2024–2025 the W3C Design Tokens Community Group (DTCG) standard format has taken hold.

Standard Format (DTCG 2024)

{
  "color": {
    "brand": {
      "primary": {
        "$value": "#0066ff",
        "$type": "color",
        "$description": "Main brand color"
      }
    }
  }
}

Key Characteristics

• $value, $type, $description fields.
• Alias support: "$value": "{color.brand.primary}".
• Nested groups.
• Bi-directional Figma ↔ code compatibility.

Major Types

• color, dimension, fontFamily, fontWeight, duration, cubicBezier, typography, shadow, gradient, transition, border.

Figma Variables (2023–2024)

• GA at the end of 2023, DTCG-compatible.
• Mode support: Light/Dark, Mobile/Desktop.
• Tokens defined and used directly in Figma.

Integration Tools

(1) Tokens Studio for Figma

• Define tokens in Figma, push to GitHub.
• Supports Style Dictionary format and DTCG.
• The most mature Figma ↔ code bridge.

(2) Specify

• Auto-syncs design sources (Figma, Sketch) to a code repo.
• CI integration.

(3) Style Dictionary (Amazon)

• Open-source standard; v4.0 (2024) added DTCG support.
• Converts token JSON into CSS / iOS / Android / Web.

(4) Supernova

• End-to-end design system platform.
• Unified tokens, docs, and code generation.

A Real-World Workflow

Figma Variables / Tokens Studio
         ↓ push
    GitHub (tokens/*.json)
         ↓ CI
    Style Dictionary
         ↓ build
[web.css, ios.swift, android.xml]
         ↓ publish
    NPM · CocoaPods · Maven

Chapter 5 — Principles of Component API Design

The real determinant of a library's value is its API design. Pleasant to use means it sticks; painful means it gets abandoned.

Five Principles

(1) Composition over Props

• Hundreds of props vs. composition.
• Bad: <Button leftIcon={...} rightIcon={...} loading iconOnly ... />.
• Good: something like <Button><Button.Icon><Plus/></Button.Icon>Add</Button> — compose via children.

(2) Both Controlled and Uncontrolled

• Uncontrolled by default (internal state).
• Enter controlled mode when needed (value / onChange).
• Standard in React libraries.

(3) The asChild Pattern (Radix)

• Delegate the parent's capabilities to a child.
• Example: <Button asChild><Link href="/home">Home</Link></Button> — the Link inherits Button's styling and accessibility.

(4) Polymorphic as prop (but typing gets hairy)

• Tag swap like <Box as="section">.
• asChild is the more modern alternative.

(5) Variant Pattern

• Class Variance Authority (CVA), Tailwind Variants.

const button = cva('base-classes', {
  variants: {
    size: { sm: '...', md: '...', lg: '...' },
    variant: { primary: '...', ghost: '...' },
  },
});

Warning Signs

• Frequent API changes — breaking changes every quarter.
• Docs full of "normally you do this, but the exceptions are...".
• Bugs triggered by prop combinations.
• Too many custom hooks (locks you into the library).

Chapter 6 — Theming and Dark Mode

The 2025 Standard Approach

1. Semantic tokens abstract colors (surface, text, border).
2. CSS Variables drive runtime theme switching.
3. prefers-color-scheme plus a persisted user choice.
4. No SSR flash: read localStorage on the server, or inject a class on the initial HTML.

Implementation (shadcn/ui default)

'use client';
import { ThemeProvider } from 'next-themes';

export default function Root({ children }) {
  return (
    <ThemeProvider attribute="class" defaultTheme="system">
      {children}
    </ThemeProvider>
  );
}

:root { --background: 0 0% 100%; --foreground: 222.2 84% 4.9%; }
.dark { --background: 222.2 84% 4.9%; --foreground: 210 40% 98%; }

Finer Color Modeling (2024–2025)

• Three-state mode: system / light / dark.
• 4–5 themes: per brand or per role (e.g. admin vs. customer).
• HDR conversation: new CSS color() function, the P3 color space.

Chapter 7 — Accessibility: A Defaults Philosophy

"Accessibility isn't an add-on — it's the default."

WCAG 2.2 (2023) Key Changes

• Mandatory drag-less alternatives for drag interactions.
• Target Size: minimum 24×24 px.
• Consistent Help (help placed consistently).
• Clear Focus Indicator.

Design System Defaults

• Keyboard support on every interactive element.
• Visible focus ring (:focus-visible).
• Screen-reader labels (aria-label / aria-labelledby).
• Color contrast of 4.5:1 or better (text).
• Respect prefers-reduced-motion.

Key Tools

• axe-core, axe DevTools: automated browser checks.
• Lighthouse Accessibility.
• Storybook a11y addon: per component.
• NVDA, VoiceOver: real screen-reader testing.

Legal Requirements

• EU Accessibility Act (EAA) went into effect June 2025.
• Korea's Web Accessibility Certification Mark, Anti-Discrimination Act.
• US ADA, Section 508.
• Mandatory for any global SaaS.

Chapter 8 — Mobile and Cross-Platform Design Systems

Strategies for Web and Mobile Together

(1) Run Them Separately

• React for web, native Swift/Kotlin for mobile.
• Share tokens only; each platform owns its components.

(2) Share via React Native

• Web and Native both in React.
• Tamagui, Solito, Expo Router.
• Significant token and component reuse.

(3) Flutter

• A completely different stack — build your own DS.

2024–2025 Trends

• Expo + React Native Web: common choice for startups.
• Respect the differences between Apple HIG and Material You.
• Responsive and adaptive combined: breakpoint plus platform.

Chapter 9 — Korean Enterprise Case Studies

Toss (TDS / Toss Design System)

• Headless + shadcn-style influence.
• Extreme attention to motion detail.
• Public blog and conferences (SLASH) have given it a strong reputation.
• Proprietary icon system and Toss Font.

Naver (Naver Design System, NaverNow)

• Shared across Whale browser and Naver surfaces.
• Accessibility leader (first in Korea to align with WCAG).
• Massive exposure (hundreds of millions of users).

Kakao (Kakao Design Language)

• KakaoTalk, Pay, Mobility, Games.
• Balances unified vs. per-service divergence.
• Strong brand anchors in Ryan and Apeach.

Coupang (Coupang Design System)

• Tuned for large-scale e-commerce.
• Components coupled to A/B experimentation.
• Multi-country support (US, Taiwan, Japan).

LINE (LINE Design System, LDS)

• Global team collaboration.
• Deep investment in accessibility and i18n.
• Accounts for Japanese and Thai UX.

Baemin / Woowa (Woowa Design System)

• Mix of customized Toss-style and shadcn.
• Active dev and design conference presence.

Shared Patterns

• Figma library synced with Storybook.
• Primitive / Semantic token split.
• Brand-level variants (per-service colors).
• Internal design-system teams of 10–30 people.

Chapter 10 — Adoption Strategy by Team Size

1–3 People (solo / early startup)

• shadcn/ui + Radix + Tailwind.
• Put tokens directly in Tailwind config.
• Light use of Figma Variables.

10–30 People (Series A–B)

• Split your own component library off shadcn (monorepo package).
• Manage DTCG token JSON separately.
• Adopt Storybook; write usage guides.
• 0.5–1 person on design-system duties.

50–200 People (Series C+)

• Automated token-sync pipeline (Tokens Studio → GitHub).
• Dedicated design-system team of 2–5 (designer + engineer).
• Cross-team governance and versioning.
• Dedicated accessibility review.

200–1,500 People (enterprise)

• Platform team of 5–20.
• Multi-platform (Web + iOS + Android).
• Multi-country support, legal compliance (WCAG, ADA, EAA).
• Internal design-system conferences and training.

Common Failure Modes

• Components without tokens — can't switch to dark mode.
• Designer-engineer disconnect — implementation diverges from design.
• No documentation — never gets used.
• No governance — each team forks and the variety explodes.
• No migration plan — legacy UI just sits there.

Chapter 11 — 90-Day Playbook: Starting an Internal DS with shadcn

Day 1–14: Define Tokens

• Primitive and semantic tokens via Figma Variables.
• Export DTCG JSON.
• Project into web via CSS Variables.

Day 15–30: Foundation Components

• Button, Input, Select, Dialog, Toast, Card.
• Install via shadcn CLI, then adjust to your brand.
• Stand up Storybook.

Day 31–45: Patterns

• Form, Table, EmptyState, ErrorState.
• Rebuild 1–2 real product pages on top of them.

Day 46–60: Governance

• Contribution guide and PR review criteria.
• Changelog and SemVer.

Day 61–75: Accessibility

• Integrate axe and Storybook a11y.
• Keyboard and screen-reader testing.

Day 76–90: Rollout and Enablement

• Internal talks; designate champions.
• Support each team's adoption.

Chapter 12 — Next Up: Season 6 Ep 3 — "AI-Native UI and Generative UX"

Once you have a design system, the next frontier is the era when AI builds the UI. Ep 3 is about AI-native UI patterns.

• Generative UI: the LLM picks and generates the UI directly.
• Streaming UI: token-by-token progressive rendering.
• Tool Use and UI (Tool Call → Dynamic Card).
• AI SDK (Vercel), LangChain UI, LlamaIndex.TS UI.
• Designing conversational interfaces.
• Feedback and correction UX.
• Visualizing uncertainty and hallucination.
• Human-in-the-loop UI for agents.
• Progressive disclosure meets AI.
• Benchmarks for AI product UX in 2025.

"While the AI generates its response, what is the user looking at?"

See you in the next post.

Epilogue — A 12-Point Checklist

1. Does your design system cover all five layers: tokens, components, patterns, docs, governance?
2. Are primitive and semantic tokens cleanly separated?
3. Is there a Figma ↔ code sync pipeline?
4. Do components consistently apply the composition, controlled, and variant patterns?
5. Does dark mode switch automatically just by swapping theme tokens?
6. Are WCAG 2.2 defaults baked in?
7. Are your Storybook and docs site up to date?
8. Are tokens stored in DTCG format?
9. Are contribution and review guidelines documented?
10. Is there a migration plan from legacy UI to the new DS?
11. Is the design system actually used in 80%+ of real product surfaces?
12. Is maintenance ownership clear?

"A good design system is invisible. When the product just feels 'as it should,' the system is working."

— Season 6 Ep 2, Fin.