◉ Claude.ai/2026-06-02Intermediate

Designing Claude Design's Design System So It Isn't Throwaway

One pretty deck out of Claude Design isn't an asset if you rebuild the design system from scratch every time. Here is how to turn extraction into a repeatable operation, so anyone can spin up the same-quality deck from just a script — designed from the trenches of indie development and art.

claude-design³ design-system⁴ slide-deck² workflow³⁷ anthropic-labs²

✦ Premium Article

When one polished deck comes out of Claude Design, most people stop there. But if you re-derive the design system from zero a few weeks later for the next deck, you're just repeating one-off outputs. After building apps solo since 2014 as an indie developer, the lesson I keep relearning is this: what pays off isn't a single artifact, it's the structure you leave behind that makes the second deck onward faster.

This article isn't about how to use Claude Design — it's about operating the extracted design system as a team asset. I covered the basics in handing Claude Design one old slide; here I deal with what comes after: reproducibility, scaling across people, and dividing the work with humans.

What "not throwaway" actually means

The test is simple: if a different person makes the same deck, does the brand reproduce at the same fidelity? If not, your design system isn't an asset yet. Claude Design builds a design system during onboarding by reading your codebase and design files, then reuses your colors, typography, and components automatically on later projects. The job of operations is to turn that "automatically on later projects" from tribal knowledge into steps anyone can follow.

What matters here is pushing the judgment out of one person's head and into measurements and steps anyone can follow. Writing down even an implicit rule like "titles join at most three words with a middle dot" means a different person produces headings with the same rhythm. Leaving something as a reusable template means verbalizing these small decisions one by one, so you never rediscover the same thing on every output.

What to make the system verbalize

To turn the extracted system into an asset, know what's been verbalized and add what's missing. At minimum, line up six elements:

Color (brand, surface, text, state colors)
Type scale (heading down to body)
Spacing scale (a system based on, say, a 4px unit)
Components (card variations, labels, per-context icons)
Tone of voice (concrete numbers, no emoji)
Usage by context (pitch / recruiting / store image, and how each bends)

Write the just-extracted state into a single "spec core" so you can add diffs later. Something at this granularity:

# design-system.summary (the core a human finalizes after extraction)
brand:
  primary:   "#1E5BBF"   # title bar / emphasis
  surface:   "#F2F6FC"   # tints / callouts
  text:      "#1A2330"
typography:
  base:      "Yu Gothic Bold"
  scale:     [32, 24, 20, 16, 14]   # h1..caption
spacing:
  unit: 4
  scale: [4, 8, 12, 16, 24, 32, 48]
tone:
  numbers: "show concrete values"
  emoji:   "never"
usage:
  recruiting: "wrap shared platform in a pale-blue callout"
  pitch:      "one message per slide; push diagrams toward a single image"

The point is not to treat the extraction as sacred. The values the model reads always contain a few that drift from brand intent. I recommend keeping the order strict: a human finalizes it first, then you make it an asset.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A priority order for what to feed Claude Design so design-system extraction is accurate

✦A composition-Markdown template that makes script-to-slide output reproducible

✦A rough-then-clean pipeline for complex diagrams, and rules that break key-person dependency

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

A priority order for what you feed it

The same prompt — "build a design system" — produces very different accuracy depending on what you pass. In my experience the effective order is:

Finished real artifacts (existing slides, landing pages, logo)
Codebase / Figma files (tokens readable as structure)
Fragmentary specs like color and font choices
Description in words only

A single finished page tells the model far more than paragraphs of spec. That matches Anthropic's own framing — one finished landing page over a color-palette spec sheet. If your brand isn't settled yet, making one good reference page first is the shortcut; a found design or a generated image both work. Concentrating your first cost on one good real artifact is, in practice, the fastest path.

A composition-Markdown that keeps script-to-slide reproducible

The biggest lever for breaking key-person dependency was fixing the format in which scripts are handed over. Instead of pasting free text into chat, decide on a composition-Markdown template so anyone produces slides with the same skeleton. My template:

# Deck: <name> / Goal: <who should decide what>
## Slide: title
- message: <the one message this slide commits to>
- visual: <type: bullets / comparison / matrix / single image>
- body:
  - <point 1>
  - <point 2>
- note: <which design-system usage to apply>

Sharing this gives decks the same effect the Findy engineering team got by turning AI-DLC into a skill so "anyone who runs it produces the same document skeleton." Forcing one message per slide alone cut the classic over-stuffing failure dramatically. With less rework after generation, total production time feels 2x to 3x faster.

A rough-then-clean pipeline for complex diagrams

The most accident-prone part in operation is complex diagrams. Instructing a role-by-phase matrix in words alone melts time into "tighten this, align that column." Fix a standard route:

Decide only the structure first (axes, what fills the cells)
Make a rough single image with image generation
Hand that rough to Claude Design: "clean this up with the same structure"
After cleanup, only tighten spacing and alignment with Edit

Redrawing a single image is cheaper in tokens, so rough by image generation / clean version in Claude Design is efficient on both time and cost. This is a workaround I found by failing several times on real decks, and it helps most exactly when words fail you. One pitfall: putting too much text in the rough drags the layout during cleanup — keep the rough structural and let the composition-Markdown carry the wording.

How to record diffs so the system keeps growing

An extracted design system is never finished the moment you finalize it. Values drift bit by bit every time a new use case appears. In my own workflow I keep a one-line change log inside design-system.summary. The trick is to record not just the value but why it changed — whether future-you can read that line in six months and recall the intent is what decides if the system stays a living asset.

# design-system.summary change log (excerpt)
2026-05  added recruiting to usage (to unify hiring decks with a pale-blue callout)
2026-06  added 48 to spacing.scale (vertical store images felt cramped under headings)
2026-06  spelled out tone.rhythm as "middle dot, up to three words" (heading length varied per page)

Decide that the trigger for an update is "a new use case appeared," and you never agonize over when to review. Conversely, when you want to tweak a value but no new use case has shown up, that's usually a sign you're trying to push one deck's local quirk into the system — holding back here keeps the system clean. Stacking diffs as one-line additions rather than big overhauls is what makes it last.

Operating it so anyone hits the same quality

Summarized as a team workflow, the Before / After looks like this:

Aspect	Before (person-dependent)	After (asset)
Brand reproduction	rebuilt by hand, drifts per page	guaranteed by the design system
Script handoff	free text, uneven granularity	skeleton fixed by composition-Markdown
Complex diagrams	word round-trips, time melts	stable via rough-then-clean
Updates	fix every page by hand	just re-hand the script
Scaling	only a few can make it	newcomers use the same template

The pitfall is deciding the design system and the composition-Markdown once and leaving them. In real operation, adding one usage line each time a new context appears (a tall store image, say) causes fewer accidents than a big later overhaul. Growing it small keeps it usable longer.

Where to trust the AI, where humans hold the line

Finally, the division of labor. I believe humans must hold three things: final spacing tweaks, fact-checking, and the final brand judgment. Claude Design stands up skeleton and consistency astonishingly fast, but it doesn't guarantee "is this number current" or "may we commit to this phrasing as the brand." Hold those and you can delegate the rest boldly.

For me, the artwork itself uses no AI, while operational, outward-facing design — decks, icons, store images — leans on AI fully. That line is my own design for protecting creative time while running four sites and a Stripe membership. Start by deciding one composition-Markdown for your team. With one template in place, the speed of every deck after the first changes completely.

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.