How to Use Claude With a Design System

Claude does not know your design system unless you tell it. Give it your approved tokens, component patterns and review constraints, and it generates system-consistent code and copy. Skip that context and it makes reasonable-sounding choices that conflict with your system and create rework.

The workflow is straightforward: supply the relevant design system material before asking Claude to produce anything, specify what is approved, and record implementation decisions in a shared place so a future session — or a teammate — knows why a choice was made. Tools like fenbs are useful for that record: design decisions and rules stay outside the chat, so a new session starts with the same constraints the last one had.

Give Claude the design tokens it needs

Design tokens are the named values — colors, spacing, typography, radii, shadows — that define the look of your system. When Claude generates code without them, it invents plausible-looking values that do not match your system. When you supply them, it uses the right names.

The simplest approach: paste the relevant subset of your token file into the conversation. For a button component, that is your color tokens (primary, secondary, disabled, hover states), your spacing scale, your border-radius values and your typography tokens for button labels. You do not need to paste the entire token file; paste what the component uses.

If your design system uses a CSS custom property convention like --color-primary or a JavaScript object like theme.colors.primary, tell Claude. Consistency with your naming convention is as important as the values themselves, because a value with the wrong name does not get the benefit of future token changes.

Supply approved component examples

The fastest way to align Claude's output with your system is to show it an existing component that is correct. Paste the approved code for a button, an input or a card, and ask Claude to produce a new component "following the same patterns and conventions as this example."

This works because Claude is good at pattern matching. It will pick up on your prop naming conventions, your styled component structure, your accessibility attributes and your test file shape from one well-chosen example. It is not perfect — review the output carefully — but it gets much closer than a generic request.

For text content, show Claude an approved example of the kind of copy you need: a button label, an error message, a tooltip. Ask it to write new versions "in the same voice and at the same length as these examples." This constraint produces consistent microcopy without a full style guide recitation.

State the review constraints explicitly

Your design system almost certainly has rules beyond visual appearance: accessibility requirements, browser support targets, performance budgets, patterns that are explicitly deprecated. Claude will not know these unless you state them.

At the start of a component generation request, add a constraint block: "Requirements: WCAG 2.1 AA. Do not use inline styles. Use the existing spacing scale — do not introduce new values. Do not use deprecated components from the v1 library." Each constraint removes a category of rework.

Ask Claude to check its own output against the constraints before presenting it: "After generating the component, review it against the requirements above and fix anything that does not meet them." That catch happens in the generation step rather than your review step.

Handle the gap between design assets and implementation

Design system assets — Figma components, Storybook pages, tokens files — live in their own tools. Claude cannot read a Figma file directly. What you can do is copy the relevant values, export tokens as JSON or CSS, or paste a component's property table into the conversation.

The gap between a Figma design and a code implementation creates decisions: which Figma token maps to which CSS variable, how to handle states that exist in code but not in the Figma component, what to do when a Figma value does not match the nearest token. Record those decisions where someone can find them. Without that record, the next person who builds a component makes different decisions and the system diverges.

Tracking design system implementation tasks

Building or migrating to a design system involves a lot of small, trackable tasks: update the button component, replace the old color values in the navigation, document the spacing scale. These are exactly the kind of tasks a shared board handles well.

Claude can help generate a task list from a specification or a Figma handoff. Ask it to read the spec and produce a task breakdown: which components to build, which existing implementations to update, which documentation to write. Each task then lives on the board with its status, so nobody duplicates work or misses a component.

How to do this with fenbs

1. Create a free account at fenbs.ai and add your design system project. Write the goal — migration, new system, component library — and the current state.
2. Record the key design decisions as Decisions and rules: the token naming convention, deprecated patterns, accessibility requirements, and any decisions made during design-to-code mapping.
3. Add tasks for each component or documentation piece. Include the relevant tokens and an example component in the task notes.
4. Connect Claude at /integrations and ask it to read the project rules before generating any component. It will have your constraints before it writes a line.
5. When a new decision is made — a pattern is deprecated, a mapping is resolved — record it immediately. Ask Claude to generate a short summary to add as a decision note.

The design assets themselves stay in Figma, Storybook or your token file. fenbs keeps the decisions about how to use them consistently. For a broader view of how Claude handles design work, see Claude for design.