Cedar Design System

The Challenge

Most design system case studies end at Figma. The components look polished in the file, the token structure is sound, the variants are organized — and none of it has ever touched code. There’s no proof the system actually works when a real product is built on top of it.

I wanted to close that gap. Not with a theoretical exercise, but by designing a complete token-based design system, implementing it in React, documenting it with a custom-built site, and then building real applications on it — proving the system survived contact with production constraints.

The project had a secondary motivation: demonstrating fluency with AI-assisted development tools. I’d been using Claude Code, Lovable, and Figma’s AI features extensively, and I wanted a portfolio artifact that showed what that workflow actually produces — not as a novelty, but as a legitimate way to ship real work faster.

What I set out to build:

• A complete design token foundation with semantic color, responsive typography, spacing, radius, border, and layout systems
• A component library with full variant coverage, accessibility built in, and real token bindings — not just styled rectangles
• A custom documentation site that uses the system’s own components and tokens, proving the system by being built with it
• Multiple live applications demonstrating the system’s range across different product types

System Design

Token Architecture

Cedar’s foundation is a two-layer token system: raw primitives that define the full value palette, and semantic tokens that assign meaning.

Color follows this split precisely. The primitive layer provides brand color ramps (primary, secondary, accent — each with 11 shades from 100 to 950), status palettes (error, warning, success, information), and a 12-shade neutral scale. The semantic layer maps these to purpose: bg/base, text/subtle, action/primary-hover, status/error-bg. This separation means the entire visual identity can shift by repointing the semantic layer without touching any component.

Typography uses four variable collections working together: 8 size steps (xs through 4xl), 6 line-height steps, 2 font families (Inter for body, Fira Code for mono), and 9 semantic roles (body, heading, and title at small, medium, and large). The size and layout collections include responsive modes — Mobile and Desktop — so typography scales automatically without component-level breakpoint logic.

Spacing is a two-tier system: a raw numeric scale (25 through 1800, based on a 4px unit) plus 10 named semantic tokens (space/0 through space/10) that map to the most commonly used values. Components reference semantic tokens; the raw scale exists for edge cases.

Radius, border, and grid/layout round out the foundation. Radius provides 6 values from none to full. Border defines 3 weight tokens. Grid includes column count, gutter, margin, and max-width — all with responsive Desktop, Tablet, and Mobile modes.

The entire foundation: 208 variables across 6 collections, all published and verified in Figma.

Component Library

23 component sets, approximately 460 total variants, organized into six categories:

Inputs: Button (72 variants spanning style, color, size, and state), Icon Button, Input Field, Form Field, Checkbox, Radio, Toggle, and the full Select system (Control, Option, Menu, and Field as composable pieces).

Data Display: Badge, Chip, Avatar, Divider, Card, and Data Grid — including two Data Grid architectures (row-oriented and column-oriented) to support different data density needs.

Feedback: Alert, Toast, Modal, and Tooltip — each built with semantic color token bindings so status variants (error, warning, success, info) are driven by the token layer, not per-component color overrides.

Navigation: Tabs, Breadcrumb, and Pagination — all built as composable item + container pairs.

Overlays: Menu with 6 item variants.

Status: Progress Bar and Spinner at three sizes each.

Every component uses real token bindings, not hardcoded values. Every component includes instance-swap slots where applicable. Every component was built with accessibility requirements defined upfront — ARIA patterns, focus management, and contrast ratios are specified in the component structure, not added after visual design.

Design Decisions Worth Noting

Composable over monolithic. Components like Checkbox, Radio, and Toggle ship as three layers: a raw Control, a Control + Label pair, and a Full field wrapper with description text. This lets products use the right level of abstraction — a compact settings panel uses Controls directly; a form uses the Full wrapper with validation.

Color palette revision mid-project. Partway through implementation, I revised the full brand palette — primary shifted to teal, secondary to blue, accent to green, and the success ramp was rebuilt for better contrast. Every semantic token was repointed and WCAG-verified. Because the token architecture separated primitives from semantics, this affected zero component logic — exactly the resilience the system was designed for.

No dark mode in v1 — by design. Figma’s variable modes support it, and the semantic token layer is structured to enable it, but shipping a complete, verified light mode was more valuable than shipping two half-finished modes. Dark mode is documented on the roadmap as a v2 priority.

Implementation

AI-Assisted Workflow

This project was built with AI tools as primary collaborators, not occasional assistants. The workflow:

Figma for all design work — token definition, component construction, variant management, and the visual source of truth for every implementation decision.

Claude Code for React implementation, the documentation site, and production refinement. Claude Code read the Figma files directly through MCP integration, auditing the token structure and component inventory before any code was written. Throughout the project, Claude Code maintained a standing instruction: enforce the v1 scope boundary and redirect any scope creep to v2.

Lovable for rapid prototyping of Cedar Ops. The dashboard’s layout, page structure, and mock data were built in Lovable in a single session, then handed off to Claude Code for the Cedar component integration. This split — Lovable for structure, Claude Code for system fidelity — turned out to be an effective division of labor.

The result: two parallel Claude Code sessions running simultaneously — one working in Figma for design refinements, the other building React components and documentation pages — with handoff specs passing between them. This isn’t a theoretical AI workflow; it’s how the project actually shipped.

Documentation Site

The documentation site is the bridge between the design system and its proof. Built with Astro and React islands, deployed on Vercel.

The key decision: the site itself is a Cedar artifact. Every color, spacing value, radius, and typographic choice on the doc site comes from Cedar’s own CSS custom properties, with 1:1 naming from the Figma variables. The site doesn’t just document the system — it demonstrates the system by being built with it.

Scope: 5 token reference pages (color, spacing, radius, typography, border), 20 component pages with live rendered examples using the actual Cedar React implementations, a “Built with Cedar” section linking to live applications, and a roadmap documenting what’s shipped versus what’s planned.

The component pages aren’t screenshots or static mockups. Each one renders the real Cedar React component with its actual variants and states. The Button page shows the full style × color × size × state matrix. The Select page demonstrates all four composable sub-components. The Modal page opens a real modal.

Live: cedar-ds-documentation.vercel.app

DayLog — A Health Tracking PWA

DayLog is a quick-tap health logger designed for iPhone, built as a Progressive Web App. It was the first product built on Cedar, and it exercises the system’s input components in a mobile-first context: Button, Input Field, Form Field, Checkbox, Chip, and Spinner.

The app has its own design identity (indigo brand color, health-focused UI) while sharing Cedar’s spacing, radius, and typographic scale — proving the tokens are flexible enough to support product-level customization without breaking system consistency.

Features: workout and supplement logging with custom dropdowns, a preset system that auto-saves frequently logged items, day-by-day history navigation with swipe, full PWA support (offline, add-to-homescreen, iOS safe area handling), light and dark mode, and accessibility throughout.

Live: daylog-mu.vercel.app

Cedar Ops — A Design System Adoption Dashboard

Cedar Ops is where the system’s full range becomes visible. It’s a multi-page design ops dashboard tracking component adoption across products — and it’s built entirely with Cedar’s own React components and tokens. A design system tracker that proves the system it tracks.

Why it exists: DayLog uses 6 of Cedar’s 23 components. Cedar Ops exercises 22 of 23 — covering Data Display, Feedback, Navigation, Overlays, and Status categories that a health logger never needs. Together, the two apps prove virtually the entire system.

Four pages, each exercising different component categories:

Overview — Card, Badge, Progress Bar, Chip, Avatar, Divider, Spinner, and Tabs displaying adoption metrics, trend charts, and an activity feed.

Components table — a token-styled data table (Data Grid’s React implementation is a v3 item, so the table uses Cedar tokens directly) with Badge for status, Chip for categories, Pagination, Select for filtering, Input Field for search, and Checkbox for selection.

Component detail — Tabs for section navigation, Breadcrumb for wayfinding, Modal for confirmations, Tooltip for contextual data, Alert for breaking-change notices, Toggle, and Button.

Settings — Form Field, Input Field, Radio, Toggle, Select, Toast (with a custom Cedar ToastProvider/useToast context system replacing the prototype’s third-party toast library), Button, Menu, Modal, and Checkbox.

Build process: Prototyped in Lovable for rapid layout and mock data, then every Lovable/shadcn component was replaced with Cedar’s actual React implementations in Claude Code. The final codebase imports exclusively from the Cedar component directory — zero third-party UI dependencies remain.

Live: cedar-ops-rust.vercel.app

Results

System scope:

• 208 design tokens across 6 Figma variable collections
• 23 component sets with approximately 460 total variants
• Full responsive support (typography and grid adapt across Mobile, Tablet, and Desktop)
• WCAG-verified color contrast across all semantic token pairings

Shipped artifacts:

• Cedar design system in Figma (Foundations + Components)
• Custom documentation site — 25 pages, built with Cedar’s own tokens and components
• DayLog — a functional PWA using 6 Cedar components
• Cedar Ops — a multi-page dashboard using 22 of 23 Cedar components
• 3 public GitHub repositories

Component coverage across products:

• DayLog alone: 6 of 23 components (26%)
• Cedar Ops alone: 22 of 23 components (96%)
• Combined: 22 of 23 components (96%) — only Data Grid absent, deferred to v3

AI-assisted development:

• Dual Claude Code sessions running simultaneously (Figma + React)
• Lovable for rapid dashboard prototyping, Claude Code for system integration
• Figma MCP integration for direct file reading during implementation
• Scope enforcement via standing instructions in Claude Code sessions

Reflection

What worked well:

Building the documentation site as a Cedar artifact — not just a reference, but a product that uses the system — was the single most effective decision of the project. It collapsed the gap between “here’s what the system looks like” and “here’s proof it works” into one URL.

The dual-session Claude Code workflow was surprisingly effective. Having one session focused on Figma design refinements while another built React components created a parallel pipeline that wouldn’t have been possible solo. The standing instruction pattern — telling Claude Code to enforce scope boundaries and redirect feature creep — was essential for staying on schedule.

The Lovable-to-Claude Code handoff for Cedar Ops worked better than expected. Lovable’s strength is speed: getting a credible layout with realistic mock data fast. Claude Code’s strength is precision: replacing every default component with the real thing. Using each tool for what it does best, rather than trying to make one tool do everything, was the right call.

The token architecture proved itself during the mid-project color palette revision. Repointing the brand primary, secondary, and accent colors across the entire system required changing semantic token assignments and nothing else. Zero component logic was affected. That’s the promise of token-based design; this project generated the evidence.

What I’d do differently:

Plan for the Data Grid’s implementation complexity earlier. It’s the one component that exists in Figma but hasn’t shipped as a React implementation, and its absence is visible in Cedar Ops (which uses a styled HTML table as a workaround). Starting the React implementation sooner, even as a simplified v1, would have closed the one remaining gap.

Establish custom domains from the start rather than relying on Vercel’s auto-generated URLs. The deployment names are functional but not portfolio-ready — a small detail that’s easy to overlook during a build sprint and mildly annoying to fix afterward.

Invest more time in the DayLog refinement. As the first product built on Cedar, DayLog proved the system works in a mobile PWA context, but its narrow component usage (6 of 23) means it tells a limited story compared to Cedar Ops. Given more time, expanding DayLog’s feature set to exercise more of the system — or building it after Cedar Ops rather than before — would have made both artifacts stronger.