Developer hubOperate the system, do not browse it blindly

Developers should feel like a delivery control room: clear next steps, clear ownership, and a fast route from first render to shared product capability.

This section now frames adoption around tenant-aware runtime proof: get one route healthy, classify shared work correctly, then compare engines and themes before code spreads.

Primitives93

Leaf components and local interaction building blocks.

Patterns48

Reusable task modules with durable behavior.

Structures25

Page chrome, toolbars, headers, and framing.

Surfaces36

Full route contracts configured by apps.

Ship your first screenFastest path

Why open thisUse this when the team needs a credible baseline before debating taxonomy or architecture.

OutcomeA healthy DS render in one app route with the provider mounted correctly.

Success signals

Provider mountedEngine chosenOne screen rendered

Classify shared work correctlyOwnership model

Why open thisUse this before adding abstractions, wrappers, or screen-level APIs to the shared library.

OutcomeNew capability lands in the right tier instead of becoming route-specific glue.

Success signals

4-tier mental modelOwnership guardrailsDecision matrix

Compare real rendering behaviorLive inspection

Why open thisUse this when feel, density, or brand voice are still undecided and screenshots are not enough.

OutcomeProduct posture is validated with engine and tenant comparisons before code spreads.

Success signals

Live scenesEngine deltasTheme deltas

What this hub should unblock today

Start from the job to be done, not the folder tree.

Mount

Install the package, mount the provider, and get one route to render with confidence.

Classify

Use the 4-tier model before you add shared APIs, wrappers, or route contracts.

Compare

Validate engine, theme, and density with playground scenes before polishing product screens.

Scale

Move from primitives to surfaces once the ownership model and visual posture are already stable.

If the team only does one thing firstRender one convincing DS panel in the real app shell before inventing wrappers. That single success state unlocks more than any abstract architecture discussion.

Developer routing

4 common developer questions

Start from the question you need answered

Each card points to the shortest path through the showroom instead of asking teams to navigate the taxonomy cold.

01Open getting started

How do I prove the DS is alive inside my app today?

AnswerInstall once, mount the provider high enough, then render a small but convincing panel using DS primitives.

ArtifactA healthy first render with no custom wrapper debt.

02Review architecture

Where should a new shared feature actually live?

AnswerStart with the smallest tier that fits the capability: primitive, pattern, structure, or surface.

ArtifactCleaner ownership and fewer extension mistakes.

How do I compare tone without building product code first?

First-day implementation board

This is the smallest useful slice: install the package, mount the provider, and render a credible panel through DS primitives.

Healthy first renderToken-aware snippet from the active showroom runtime.

tsx

17 lines

Consumption

Runtime-aware snippet

Validation checklist

Provider mounted at the correct app boundary.

Engine and tenant are chosen intentionally, not left as defaults by accident.

First screen uses DS layout primitives instead of ad hoc wrappers.

New shared work is classified before APIs or folders are created.

Ownership model

Choose the smallest tier that fits

Learn the 4-tier system map

The best developer docs make classification obvious before shared code is written.

Primitives

Leaf components with stable APIs and engine-switched rendering.

Decision ruleUse when the work is still a single component, not a workflow.

Patterns

Reusable task modules like tables, builders, stats, and flows.

Decision ruleUse when behavior repeats across products and deserves reuse.

Structures

Page chrome around content, patterns, and operational context.

Decision ruleUse when the problem is page framing, not the whole route contract.

Reference map

Intent-led navigation

Reference shelves

Route people by intent instead of by taxonomy so first render, ownership, and visual comparison stay reachable in one pass.

Build screens quicklyConcrete entry points when the team needs production UI, not theory.

Primitives Patterns Surfaces

Understand the systemUse these when the problem is ownership, structure, or consistency.

Foundations Architecture Structures

Compare rendering toneUse live routes before making aesthetic decisions in product code.

Playground Theme Builder Engines

Developers should feel like a delivery control room: clear next steps, clear ownership, and a fast route from first render to shared product capability.

Start from the job to be done, not the folder tree.

Start from the question you need answered

How do I prove the DS is alive inside my app today?

Where should a new shared feature actually live?

How do I compare tone without building product code first?

First-day implementation board

Validation checklist

Learn the 4-tier system map

Primitives

Patterns

Structures

Reference shelves

Design System Showroom

Developers

Developers should feel like a delivery control room: clear next steps, clear ownership, and a fast route from first render to shared product capability.

Start from the job to be done, not the folder tree.

Start from the question you need answered

How do I prove the DS is alive inside my app today?

Where should a new shared feature actually live?

How do I compare tone without building product code first?

What should I inspect when the UI feels inconsistent?

First-day implementation board

Validation checklist

Learn the 4-tier system map

Primitives

Patterns

Structures

Surfaces

Reference shelves

Developers

What should I inspect when the UI feels inconsistent?

Surfaces