How I use Claude to ship design system work faster

The headline use case everyone has in mind is component generation. Describe a button, get a React component. I've tried it. It works reasonably for simple things and breaks down fast on anything real. Non-obvious API constraints, specific ARIA attribute combinations, interactions that depend on upstream state. The output looks plausible, but you have to review it carefully before trusting it.

That's not where I get value.

The workflows that have actually changed how fast I ship are almost all about compressing work that's tedious and repeatable. Things that don't require invention but still take significant time when done manually.

Getting documentation written

Writing component documentation is one of the highest-leverage things a design system team can do for adoption. It's also the thing that gets deferred indefinitely when the team is stretched.

The hard part isn't the writing. It's the synthesis: reading the component source, understanding the intended usage, surfacing non-obvious constraints, anticipating what consumers will ask, and writing it clearly. That's where the time goes.

I feed Claude the component code, any existing design annotations, and a prompt asking for documentation structured around what the component does, when to use it versus alternatives, the prop API with honest descriptions of gotchas, and accessible usage notes. The first pass is usually 80% right. The edit takes 15 minutes. The original synthesis used to take an hour.

Don't publish the first pass. The 20% that's wrong is almost always the most important 20%. The constraints not visible in code, the design decisions not encoded in props. You have to know the component to catch what the model got wrong.

ARIA pattern lookups

Accessibility work involves a lot of specific, verifiable information: which ARIA roles apply to which patterns, what keyboard behavior WCAG specifies for tabs versus accordions, what the accessible name calculation is for an icon-only button, whether aria-describedby or aria-details is right for supplemental help text.

This information exists in WAI-ARIA Authoring Practices and WCAG docs. The lookups aren't hard. But when you're making six of these decisions in a day, the overhead adds up.

I use Claude for first-pass research here and verify against primary sources before using it. For well-established patterns like modal dialogs, navigation menus, and form controls, the output is reliably accurate and I mostly just check it. For anything newer or ambiguous, I treat it as a pointer to where in the docs to look.

The accessible usage sections of our documentation used to be the last thing added and first thing cut when we were behind. Now they get drafted alongside everything else.

Testing component APIs before they ship

When I'm deciding on a component's API, I use Claude to find problems before it goes out. Prop names, composition model, which behaviors to expose as props versus slots.

"Is this good?" gets generic agreement. The prompt that works: here's the proposed API, here are the use cases it needs to support. Where will this handle things poorly? What friction will consumers hit? What have I missed?

Some of what comes back I've already considered. Some I haven't. I still make all the calls, but I get to the edge cases faster. It's caught things I would have found at contribution review, which is more expensive to fix.

Where I don't get value

Code generation beyond simple, self-contained components. Too much review required to be faster than writing it.

Naming. The model gives you reasonable names that won't reflect your conventions, product vocabulary, or existing patterns. Naming requires context it doesn't have.

Organizational judgment. What to prioritize, which contributions to accept, how to handle conflicting stakeholder input on component behavior. These look like information tasks. They're people tasks.

The work where I actually get speed: synthesis, lookups, coverage checking. Tedious things that don't require judgment but still eat time. Worth knowing about. Just don't mistake it for the whole job.