From design system to deployed code: a weekend with Claude Design

Last weekend, I finally redesigned my blog.

Not by opening Figma.
Not by sketching half‑formed ideas in isolation.
And not by writing CSS until I knew what I was building.

Instead, I treated the redesign as a small experiment: could I take an existing, real website, allow an AI tool to infer its design system, explore a new direction within those constraints, and then move straight into implementation without a traditional design handoff?

The result surprised me - not because the tools worked, but because many of the usual friction points between design and implementation simply didn't appear.

Claude Design was released on 17 April, and rather than treat it as something to react to publicly or experiment with on client work, I wanted to understand it quietly first, in the smallest possible real context.

My blog was ideal. It’s production code, real content, and a design system that's evolved organically over time. If anything was going to expose weaknesses quickly, it would be this.

This wasn't about speed or novelty. It was about seeing whether anything genuinely changed in the shape of the workflow.

My blog is small, but it's a real project.

It has:

• Blog posts spanning multiple years
• Existing layout and component decisions
• A design that evolved organically rather than being deliberately designed

That made it ideal for an experiment, I wasn't starting from a blank canvas, and I wasn't trying to invent a new brand.

The most fascinating part of Claude Design is that the output isn't the clever part - the onboarding is.

Instead of beginning with an endless list of prompts about mood, style, or colours, I pointed the tool at my existing site. It analysed the patterns, colours, typography, and spacing decisions.

A working design system was born directly from what already existed. I wasn't inventing something new, the generated system already felt recognisable.

This mattered because the system was concrete, matched the existing site, and formed a strong basis for future work.

Once the system was in place, the redesign itself became much more straightforward.

Rather than trying to design things in isolation, I worked with Claude Design to redesign the site end-to-end, while referring back to the underlying system the whole time.

This kept changes coherent across the site, even when adjusting layout, structure, and hierarchy. Nothing felt disconnected.

I still had to make decisions, choosing what to prioritise, shaping direction, and override suggestions when Claude went too far down a rabbit hole.

One significant benefit of working inside a fully understood design system was that accessibility issues surfaced much earlier.

Because Claude Design had a complete view of the system, it examined combinations of colours and typography up front to identify potential issues.

Contrast issues were flagged immediately. All colours worked well together apart from one dimmer colour variable. Claude Design suggested appropriate fixes that stayed within the existing system and still required final human approval.

Having these issues surfaced and addressed early in the process made a noticeable difference.

Once I was happy with the redesign, I could immediately move across to Claude Code to start building.

All I needed to do was provide the Claude Code handoff zip package and use a single prompt to get started. The package contained machine readable content, including markdown, sample HTML, images, and prototyped JavaScript.

The usual handoff process - discussions, clarification, and reinterpretation - was dramatically simpler.

The result of that handoff is the site you're currently looking at.

One practical observation worth mentioning is that this kind of work is not cheap in terms of token usage.

Claude Design consumed its weekly allowance very quickly, which makes sense given how much system‑level context it keeps in play.

That helped clarify where this fits best. It feels suited to specific parts in the delivery process, rather than as a default, always-on tool.

This was a small, constrained experiment on a personal blog - not a test of how this would operate on a large, multi‑channel enterprise build. At that scale, experienced designers would still need to be deeply involved, shaping systems and exercising judgement alongside the tooling.

Would I recommend this to teams? Yes - but deliberately. Not as a wholesale replacement for existing processes, but as something worth testing where design systems, prototyping, and handoff currently introduce the most friction.

The real value wasn’t that Claude Design produced outputs quickly. It was that fewer decisions needed translating later.