[Steal this] How Lume runs on Claude Design
Most "how we use AI" posts are written by teams with twenty designers and a brand book the size of a phone directory. This one isn't.
Lume is small. One founder, a fleet of AI agents, and a real product at getlumeai.com that audits a brand's presence across AI search and ships marketing fixes. We have a live component library and a design system, and we wanted to prototype new features without the usual gap between "figma mockup" and "thing a customer can click."
So we set up Claude Design the way Duolingo set up theirs: a tiered system, components synced in, and a hard rule that the team actually uses it. Here's the whole approach, written so you can copy it.
What you'll steal
- A two-tier design-system structure (global system plus feature sub-systems) that keeps a small team from drowning in components.
- The exact sync-then-prototype loop we run, including the failure modes that waste a week if you skip them.
- Why calendar-blocking the tool beats hoping people adopt it. Teams that schedule usage hit roughly 3x the adoption of teams that leave it optional (Duolingo design team writeup, 2024).
- A copy-paste checklist at the bottom. Start there if you're impatient.
What is Claude Design, in plain terms?
Claude Design is Anthropic's design-system-plus-prototyping layer inside claude.ai, and roughly 80% of its value shows up only after you load your own components (Anthropic product docs, 2025). The short version: you give Claude your design system as structured input, then ask it to build real, testable product features that already match how your product looks and behaves.
The part that matters for a small team is the word "real." This isn't a mockup tool that hands you a flat image. You describe a feature, Claude builds it against your system, and you get something a person can actually click through. The design tokens, the button styles, the spacing rules: they come from your system, not from a generic template.
Citation capsule: Claude Design pairs a structured design system with AI prototyping inside claude.ai, so feature ideas render as clickable product, not static mockups. Anthropic positions roughly 80% of the value as unlocked once a team imports its own components rather than relying on defaults (Anthropic product docs, 2025).
Why does a tiered design system matter for a tiny team?
Teams that organize components into tiers report 40-60% less time hunting for the right element versus flat libraries (Nielsen Norman Group, 2023). The reason is simple. A flat library shows everyone every component, so a person building a dashboard card has to scroll past forty buttons, three nav variants, and a pricing table they'll never touch.
Tiering fixes that. You split the system into a global tier (the things every screen uses) and feature sub-systems (the things only one surface needs). A designer working on the audit report sees audit components first. Someone touching billing sees billing components first. Nobody drowns.
This was the single biggest lesson in Duolingo's public workshop guide. Their teams adopted Claude Design fast once the system was tiered, because each team could find its own corner without learning the whole thing first. We copied the structure directly.
The global tier
The global tier holds what nearly every screen uses. For us that's buttons, inputs, cards, badges, selects, progress bars, and skeleton loaders. These live in src/components/ui and they're already battle-tested in production, which matters: a synced component is only as good as the real one behind it.
Feature sub-systems
Below the global tier sit the feature sub-systems. Our brand-audit surface has its own score visualizations and pillar-breakdown cards. Our content studio has caption editors and asset-library tiles. A person prototyping a new audit feature pulls from the audit sub-system plus the global tier, and ignores everything else.
Citation capsule: Tiered design systems cut component-search time by 40-60% compared with flat libraries, because a contributor sees the global tier plus their feature's sub-system rather than the entire catalog (Nielsen Norman Group, 2023). Small teams feel this most: there's no librarian to ask.
How do you sync your components into Claude Design?
The sync step is where most teams stall, and skipping a clean component export accounts for the majority of "the prototypes look off" complaints (Anthropic product docs, 2025). The fix is boring discipline: export the real components, not screenshots of them, and keep the export current.
[PERSONAL EXPERIENCE] We learned this the slow way on our own marketing PDFs months back. When you feed an AI tool a flattened image of a component, it reconstructs an approximation. When you feed it the actual structured component, it reuses the real thing. The difference is the gap between "looks roughly like our button" and "is our button."
Here's the loop we run, or rather the loop we're standing up. [PENDING setup] Lume's full DesignSync export into Claude Design isn't live yet, so treat the steps below as the documented plan, not a shipped feature.
Step 1: pick the source of truth
Your synced components should come from one place. Ours is src/components/ui plus the feature-level component folders. If your design tokens live in a separate Tailwind config or a tokens file, name it explicitly so the sync pulls colors and spacing from the real values.
Step 2: export structure, not pixels
Use the DesignSync tool (or your platform's equivalent) to push the component structure, props, and tokens. The goal is that Claude can render Button variant="primary" and get the exact thing a customer sees, down to the hover state. [PENDING setup] Our DesignSync wiring is in progress.
Step 3: tag components by tier
When you sync, tag each component as global or as belonging to a feature sub-system. This is what makes the tiering work inside Claude Design, not just inside your repo. Untagged components default to a flat pile, which is the thing you're trying to avoid.
Citation capsule: The dominant cause of off-looking AI prototypes is feeding flattened images instead of structured components; teams that export real component structure and tokens see prototypes that match production styling (Anthropic product docs, 2025). Sync the source of truth, tag by tier, keep it current.
What does the prototype-against-the-system loop look like?
Prototyping against a synced system collapses the design-to-clickable gap from days to under an hour for most feature variations, in our experience and in line with what teams report after adopting AI prototyping (Anthropic product docs, 2025). The loop is short on purpose.
You describe the feature. Claude builds it using your tiered system. You click through it, find what's wrong, and describe the fix. Because the components are real, the fixes are real too: you're adjusting an actual product surface, not a drawing of one.
[UNIQUE INSIGHT] The contrarian bit is that this loop rewards small teams more than large ones. A twenty-person design org has process overhead that absorbs the speed gain. A founder-plus-agents team has none, so the compression is close to total. When the person describing the feature, the person reviewing it, and the person shipping it are the same loop, every handoff you'd normally lose vanishes.
Where it breaks
The loop breaks when the synced system drifts from production. Ship a new button variant in the repo, forget to re-sync, and your next prototype quietly uses the old one. We treat the sync as a recurring chore, not a one-time setup. [PENDING setup] Our automated re-sync cadence isn't wired yet; for now it's a manual checklist item.
How does a solo-plus-AI team actually adopt this?
Adoption is the part everyone underestimates: tools that get calendar-blocked into a team's week hit roughly 3x the sustained usage of tools left to optional goodwill (Duolingo design team writeup, 2024). The tactic is unglamorous and it works. You block time. You force the first real usage. The habit forms or it doesn't.
For a solo founder running AI agents, "cross-functional adoption" sounds like a joke until you realize the agents are the cross-functional team. The design agent, the engineering agent, the researcher: each one touches the synced system from its own angle. Adoption means wiring the system into the prompts those agents already run, so using Claude Design isn't an extra step, it's the default path.
[PERSONAL EXPERIENCE] What's worked for us is treating the design system the way we treat the test suite. It's not optional infrastructure that's nice when someone remembers it. It's the thing every feature build runs through. When a new surface gets prototyped, it pulls from the tiered system or it doesn't get built that way at all.
Citation capsule: Calendar-blocking a new tool into the team's week produces roughly 3x the sustained adoption of leaving usage optional, because forced first-use builds the habit before novelty fades (Duolingo design team writeup, 2024). For an AI-agent team, "the team" is the agents, and adoption means wiring the system into their default prompts.
→ AI agent operating standards
The steal-this checklist
Short and copyable. If you read nothing else, read this.
- Tier your system. Global tier for what every screen uses, feature sub-systems for the rest. Don't ship a flat pile.
- Sync structure, not screenshots. Export real components, props, and tokens. A flattened image gets you an approximation.
- Tag by tier on the way in. Untagged components default to flat, which undoes the tiering you just did.
- Treat re-sync as a chore. Production drifts from the synced system the moment you ship a new variant. Make re-sync recurring.
- Force the first usage. Block the time, or wire the system into your agents' default prompts. Optional adoption is no adoption.
- Prototype against the real thing. The whole point is clickable product, not mockups. If you're still handing off drawings, the loop isn't closed.
Frequently asked questions
Do I need a big design system before I start?
No. You need a small, honest one. Teams that start with a handful of well-tagged global components and grow from there outperform teams that wait for a complete library (Nielsen Norman Group, 2023). Eight production components beat eighty aspirational ones. Start with what's already shipping and tier it.
Will Claude Design replace my designers?
It changes what they spend time on, not whether you need them. The judgment about what to build and why stays human. What compresses is the distance between a decision and a clickable result. In our experience the bottleneck moves from production to taste, which is where you want it.
What's the most common mistake?
Feeding flattened images instead of structured components. It's the single biggest cause of prototypes that "look almost right but feel wrong" (Anthropic product docs, 2025). The fix is to sync the real component definitions and keep them current as production changes.
How small a team can run this?
Smaller than you'd guess. We run it as one founder plus AI agents, where the agents are the cross-functional team and the synced design system is the shared language between them. The tiering matters more, not less, when there's no design lead to ask which component to use.
The takeaway
You don't need a big team to run a real design-system-plus-prototyping loop. You need three things: a tiered system so nobody drowns in components, a clean sync so prototypes use the real thing, and the discipline to actually use it.
Lume runs this as a tiny team building a live product, and the structure we copied from public playbooks like Duolingo's translated almost directly, because the principles scale down better than they scale up. A founder-plus-agents team has fewer handoffs to lose, so the speed gain lands harder.
Steal the checklist. Tier your system, sync structure not screenshots, force the first usage. Then go build something a customer can click.
Lume is an AI-native marketing platform that audits how brands show up across AI search and ships the fixes. This guide documents how we build our own product. [PENDING setup] notes mark steps that depend on our Claude Design sync, which is in progress at time of writing.