Building Blocks
Menu
SystemFoundationComponentsPatternsThemesIncluded
CatalogsLive catalogsHow catalogs work
GuidesDocs
Themes

Change product character without changing component meaning.

Exercise a theme as a system: switch product character, inspect semantic changes, compare identical UI, and keep product decisions explicit.

Demo — not a configuration API

One semantic contract. Multiple product characters.

Use the workbench to change product expression while keeping the component jobs, interaction states, and semantic meaning stable. The controls below are documentation tooling; they do not claim a package API or production theme generator.

Product characterBase

Make the system visible.

Structure and behavior stay stable while semantic theme values change.

Project nameNorthstar
Search projects
StatusReady for review
Review changes
Density
Radius
Preview surface

Compare character without comparing semantics.

Side-by-side comparison is useful only when the same jobs and content appear in both panels. This makes product expression visible without suggesting that themes can alter component meaning.

BaseSame shell, same states, same content
BASE

Publish changes

Review the current draft before it goes live.

Release note
EDITORIAL

Publish changes

Review the current draft before it goes live.

Release note

Theme contract

Building Blocks can provide a complete baseline theme model, but each consuming product still specifies its own product values. Theme switching should happen through semantic references rather than component-by-component overrides.

Stable across themes
  • Semantic job names
  • Component behavior
  • Required states
  • Accessibility expectations
  • Responsive meaning
Product expression
  • Semantic color mappings
  • Typography
  • Radius / border / elevation
  • Density
  • Motion character
  • Icon grammar

Theme through the three token tiers.

01PrimitiveRaw values are the vocabulary. Components never consume them directly.
02SemanticIntent-bearing roles such as text, surface, interactive, feedback, spacing, and motion. Theme switching happens here by changing semantic references.
03ComponentUse only where a component genuinely needs a scoped value the semantic layer cannot express. It still references semantics.
Do not theme by scattered component override.

If every button, dialog, and card carries its own theme logic, the product no longer has a coherent theme layer.

Scope and inheritance

Theme scope is appropriate for

  • Whole-product expression
  • Documented product variants
  • Light/dark mappings
  • Purposeful scoped surfaces required by the product spec

It is not an escape hatch for

  • One-off component fixes
  • Raw value overrides
  • Catalog-only dark rectangles
  • Changing semantics to force a preferred visual treatment

Create a product theme

  1. Finish the relevant Foundation decisions.Do not use the theme workbench to avoid product decisions.
  2. Name semantic roles first.Establish intent-bearing roles before assigning brand values.
  3. Map product values to those roles.Keep raw values behind semantics.
  4. Exercise the hardest contexts.Check interactive states, overlays, dense views, long content, responsive layouts, and dark appearance where required.
  5. Verify the product Catalog in that theme.The Catalog wears the product theme; it does not invent documentation-only visual language.
Implementation maturity

This workbench demonstrates the contract and interaction model. It does not claim a centralized theme registry, published token package, generator CLI, or production configuration API.