Building a Design System for an AI Hiring Copilot

The system grew out of a trust problem.

Ranked candidates arrived fast. Recruiters still could not explain why. Principle: AI does the work; the recruiter owns the call.

I systemized what survived real use.

I started from recruiter flows, not a button inventory. A pattern entered the library only after it survived testing, the API, and a real workflow.

Meaning first, then style.

Blue is action. Purple is AI reasoning. Neutrals carry evidence and status. One icon language keeps dense recruiting screens scannable.

Visual rules became component contracts.

Figma was not a second set of screens. Repeated decisions became foundations, components, and patterns — one path from a visual rule to a typed React prop.

Explore the Figma fileClick a stage

01 · Page groups 02 · Component library 03 · Design system 04 · Applied to product

Click a stage: file structure → components → product.

Next: orchestration on the project we already share.

Product, Design, and Frontend already work in one Git project. What’s missing is an agent that can read context, move between Figma and Web, and sync back.

Every semantic token traces back to a product decision.

Shared names were not enough. Blue is a human action; purple is the AI’s voice. Those roles went from research → Figma variables → --oc-* CSS used by React.

01 · EVIDENCERecruiter + API findingsConfidence, explainability, and ownership constraints.

02 · PRINCIPLEVisible and ownedAI reasoning stays distinct; people retain the final action.

03 · SEMANTIC TOKENRole, not raw valueattention, primary, and confidence tiers.

04 · CONSUMERComponent + patternAIBlock, Button, Feedback, and Candidate Review.

--oc-color-primaryHuman actions and deliberate approval moments.

--oc-color-attentionAI-generated reasoning that requires review.

success / warning / dangerConfidence-dependent outcomes and feedback.

Figma records the architecture. The CSS token file is the source of truth for shipped names.

:root, [data-oc-theme='light'] {
  --oc-color-primary: #1a6ee8;    /* interaction */
  --oc-color-attention: #9170ff;  /* AI reasoning */
  --oc-radius-card: 10px;
  --oc-focus-ring: 0 0 0 2px var(--oc-color-surface-raised),
                   0 0 0 4px var(--oc-color-primary);
}

[data-oc-theme='dark'] {
  --oc-color-primary: #85b7ff;    /* the name holds, only the value moves */
  --oc-color-attention: #bca9ff;
}

Visual decisions became typed behavior.

Figma can show a loading button. It cannot stop a double submit or tie an error to a field. In React, each visual decision became a prop, a behavior, and a test.

Figma stateReact APIStorybookQA evidence

Selected candidateselectedSelectedVisual baseline

Candidate contentcandidateLongContentContent stress test

Decision controlsactionsWithPipelineContextKeyboard + axe

AI evidenceconfidence + sourceRendered metadataAccessible output

interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: 'primary' | 'secondary' | 'utility' | 'danger';
  loading?: boolean;
}

<Button loading={isSubmitting} disabled={!canApprove}>
  Approve candidate
</Button>

// Native disabled behavior + aria-busy + one tested visual state

Storybook made the handoff executable.

Each doc pairs the real component with props, named states, and source — design and engineering review the same object. Button covers primary, secondary, danger, loading, disabled; the story is the fixture for a11y and visual tests.

A library becomes infrastructure when change has a path.

Every push: component tests, Playwright diffs, a11y audits. Automation flags a snapshot or a missing name. A person still decides if the product principle held. Goal: coherent change, not perfect consistency.