Using Claude for component design systems

Why a design system is a harder prompting target than a single component

Generating one polished component is a well-worn task Claude handles well with a reasonably specific prompt. A design system is a different order of problem: every component has to share tokens, spacing logic, and interaction patterns with every other component, and a model working component by component, without that shared context actively maintained across requests, tends to produce components that are each individually reasonable but collectively inconsistent — a button with one border-radius convention, a card with a subtly different one, neither obviously wrong in isolation.

Establish the system's rules before asking for components

The single highest-leverage thing you can do is write down the system's actual rules — spacing scale, colour tokens, typography scale, naming conventions — before asking for the first component, and then feed that same rule set into every subsequent component request rather than letting each one be generated against an implicit, re-inferred sense of "what this system probably looks like." A model asked to build a component with an explicit token reference produces something that actually uses the system; a model asked to build a component that "matches the existing style," with the existing style described only vaguely, tends to invent its own close-but-not-quite values instead.

Reviewing for consistency, not just for correctness

A single component review checks whether that component works. A design-system review needs an additional, distinct check: does this component's use of spacing, colour, and type match the established system, not just look reasonable on its own. This is easy to skip because a inconsistent-but-individually-fine component doesn't look broken in isolation — the inconsistency only becomes visible once it's sitting next to its siblings in the actual system, which is exactly where a quick, isolated review won't catch it.

Naming conventions compound faster than visual inconsistency

A visual inconsistency is annoying but usually fixable with a targeted pass later. An inconsistent naming convention across component props, tokens, or file structure is more expensive to fix retroactively, because by the time it's noticed, other code has usually already been written against the inconsistent names. Establishing and enforcing naming conventions explicitly from the first component, rather than letting them emerge organically, avoids a category of cleanup that gets progressively more expensive the longer it's deferred.

Feeding real examples back in, not just describing them

Once you have a handful of components that correctly reflect the system, feeding those actual components back in as concrete reference examples for the next request tends to produce more consistent results than a purely textual description of the system's rules on its own — a real example is unambiguous about spacing and structure in a way a written description, however careful, can still leave room to interpret differently. Build up a small, curated set of reference components early and reuse them across requests rather than relying on the written rules alone each time.

Versioning the system's rules as they change

A design system's rules are not static — a spacing scale gets refined, a colour token gets deprecated in favour of a new one, and every component generated against the old rules needs to be reconciled against the new ones eventually. Treat a rule-set change the same way you'd treat any other breaking change to shared infrastructure: identify what's affected before assuming everything generated earlier still complies, rather than discovering the drift piecemeal as individual components happen to get revisited for unrelated reasons.

Where this connects to accessibility and responsiveness

A design system's components need to be individually accessible and responsive, and those concerns don't automatically propagate just because the system's visual rules are consistent — a component that correctly uses the system's spacing tokens can still fail a contrast check or break at a narrow viewport if those specific concerns weren't part of what you asked for. Treat accessibility and responsiveness as their own explicit checks per component, layered on top of the consistency check rather than assumed to come along with it for free. See prompting Claude for accessible HTML and prompting Claude for responsive layouts for each of those specifically.