Skip to content
AJ Barnett, home

Design system

Scalable products
are systems.

A product scales when the next engineer can move fast without asking permission. That means shape before surface: data model, API contracts, boundaries, DX, and tokens, decided on purpose, not inherited by accident.
How I build for scaleArchitectureAPI surfaceDXTokens
The ajbarnett.tech token playground with coral-red color tokens, typography, and component states.
ajbarnett.tech · Tokens · Components · CodeSystems

Live Component Explorer

One primitive of many: Storybook.

Components are the visible edge of the system. Underneath sit tokens, API contracts, and DX conventions, the parts a team inherits without noticing.

Open Storybook →

Tokens

Design tokens as a language.

Color

  • --backgroundsurface
  • --foregroundcontent
  • --surfaceelevated 1
  • --surface-elevatedelevated 2
  • --primaryactions
  • --accentactions · emphasis
  • --muted-foregroundsubtle text
  • --borderhairlines

Spacing

0
1
2
3
4
6
8
12
16
24
32

Radius

sm
md
lg
xl
2xl

Typography

  • Display / Hero

    Systems that scale.

  • Display / L

    Composable primitives

  • Body / L

    Composition over configuration.

  • Body / S

    Documentation is a product.

  • Mono / XS

    TOKENS · TYPE · MOTION

TOKENS · COLOR · SPACE · RADIUS
Playground

Change a token · see it ripple

Tokens live

Change a token. Watch the component change. That's the contract.

color.accent.hue33°
radius.base8px
space.pad24px
density.scaleComfortable
--color-accent: oklch(0.63 0.22 33);
--radius-base: 8px;
--space-pad: 24px;
--density-scale: 1.05;

Component

Live token demo

Every visual decision flows through a token. Change one, everything downstream inherits it. No coordination meeting required.

Principles

How I build for scale.

01

Shape before surface

Data model and API contracts first. UI last. The shape decides everything downstream.

02

Boundaries are the product

Auth, ownership, and trust lines are named on purpose. Every ambiguity is a future bug.

03

Composition over configuration

Small primitives that combine. Fewer props, sharper APIs, less to memorize.

04

Tokens over hardcodes

Every visual decision goes through a token. One change ripples through every surface.

05

DX is UX for the next engineer

The paved road is the product. If it's easier to do it right, right is what ships.

06

Docs travel with the code

A component without an example is a component without a contract.

Public API

Component APIs shaped by intent.

The API is the product. It teaches, constrains, and rewards good composition.

Configuration (avoid)

<Card
  title="…" subtitle="…" icon={<X />}
  actionLabel="…" actionVariant="outline"
  showDivider hasFooter footerAlign="end"
  densityCompact
/>

Composition (preferred)

<Card>
  <Card.Header>
    <Card.Title>…</Card.Title>
  </Card.Header>
  <Card.Body>…</Card.Body>
  <Card.Footer align="end">
    <Button variant="outline">…</Button>
  </Card.Footer>
</Card>
Anatomy

Scroll to assemble

Fig. 02 · This Site in ProductionTokens · Type · Components
The live ajbarnett.tech token playground demonstrating how site tokens change a real component.

The ajbarnett.tech system proves its contract in production: one set of tokens controls typography, spacing, surfaces, component states, interaction feedback, and responsive behavior.

01
Tokens, shared visual decisions
02
Type, consistent editorial hierarchy
03
Components, reusable behavior and states

Motion

Motion as a system, not decoration.

01

Purpose

Motion earns its place by clarifying causality, what caused what, where the user is, what to look at next.

02

Duration

180–420ms for UI. 700–900ms for reveals. Never long enough to feel like waiting.

03

Easing

cubic-bezier(0.22, 1, 0.36, 1), a single expressive out-curve for everything.

04

Reduced motion

Motion is a feature, not a mandate. Honor prefers-reduced-motion, always.

05

Choreography

Sequenced stagger for lists. Solo reveals for hero moments. Never both at once.

06

Restraint

If it doesn't clarify, it distracts. When in doubt, remove.

Design to code

Figma-to-code principles.

ARCHITECTURE · DESIGN FOR CHANGE

These are workflow principles, not evidence of published Figma artifacts. When tokens are the source of truth, Figma variables and code variables both point at the same intent. The handoff stops being a translation and becomes a lookup.

  • Figma variables mirror Style Dictionary output.
  • Component names in Figma match component names in code.
  • State variants in design match slot APIs in code.
  • Accessibility annotations travel with the component, not the ticket.

Inventory

A source-level starting point.

These components have existing Storybook examples. They live in src/components; no public packages/ui package is published. Accessibility and keyboard coverage have not yet been comprehensively verified.

ButtonBadgeCardSectionPageHeroTokenPlayground

Scale

Why systems multiply teams.

01

One decision, many surfaces

A token, a contract, a boundary, decided once, inherited everywhere. No coordination meeting required.

02

Onboarding as a byproduct

New engineers learn the system, not the codebase. The system is the codebase.

03

Quality compounds

Accessibility, performance, and consistency are inherited by every new surface, not re-litigated per feature.

Ask A.J.