Design tokens are easier to explain when people can change the example and see what breaks. A static code snippet can show the naming convention, but a working demo helps the team feel the difference between palette values and semantic decisions.
A token playground in MDX
The example below shows a card built with semantic tokens. Every color, border, and text style comes from a token — not a raw hex value. Change the theme from light to dark using the toggle in the header and watch the card keep its intent.
Semantic Card
This card uses bg.surface for its background, text.secondary for this paragraph, and border.subtle for the edge. No raw hex anywhere.
Recessed Variant
Same component, different token: bg.subtle instead of bg.surface. The card recedes visually but the structure stays intact.
Accent Variant
Call-to-action treatment using accent.soft background and accent.default border.
What changes when you swap tokens
Try changing the card's surface token from bg.surface to bg.subtle and watch the card recede. Then try swapping text.secondary for text.primary and notice how the hierarchy flattens. These are the same decisions your design system makes across every component.
Run it yourself
The TokenCard component above uses Panda CSS semantic tokens — it needs the full Panda CSS build pipeline (design tokens, styled-system generation) to actually compile. The code is meant to illustrate the token-first approach, not to be copy-pasted into a blank sandbox.
If you want to experiment with token-based components, downloadable kits are coming soon — sign up for the newsletter to get notified when the Design System Starter Kit and other resources go live.