Neha Arsid, Staff Product Designer

A practical guide for designers navigating AI-assisted design: from building your first org design system to handing off production-ready components, without losing creative authority or professional identity.

Who this is for

You are a designer. You have been designing for years, maybe a decade. You understand systems, hierarchy, micro-interactions, and the quiet craft of making something feel right. And now every meeting has someone asking whether AI can just "do the designs." Every PM has Claude open on a second monitor. Every founder thinks they can ship a product by Thursday.

This guide is not about whether AI replaces designers. It is about what actually happens when you use Claude as part of your design workflow: what it genuinely changes, what it doesn't touch, where the new authority sits, and how to ensure you remain the person who defines what ships.

Everything here is grounded in real capability as of mid-2026, using Claude Design (claude.ai/design), Claude Code, and the design system workflow that connects them.

Part 1: What Claude Design actually does and what it doesn't

Claude Design is not a smarter Figma. It is a fundamentally different kind of tool: you describe what you want in natural language, and it generates real, working code on a live canvas. Not a static mockup. Not an exported image. Actual HTML, CSS, and JavaScript that behaves like a prototype.

This matters because the output is implementable from day one. When you generate a toast notification component in Claude Design, you are not generating a rectangle with a shadow. You are generating a component with states, transitions, and DOM behaviour, something a developer can look at and build from.

The split interface (chat on the left, live canvas on the right) means iteration happens in conversation. You say "the spacing feels too tight between the icon and the label," and the canvas updates. You say "show me what this looks like with a warning variant," and a new frame appears. This is closer to working with a very fast junior designer than to using a design tool.

What Claude Design produces well

Complete component designs across all visible states (default, hover, active, focus, disabled, loading, error)
Full design systems extracted from your existing brand assets, codebases, or slide decks
Working interactive prototypes with micro-interactions and animation
Handoff bundles that Claude Code can receive and build from directly

What Claude Design does not do

It has no memory between sessions; your decisions do not carry forward automatically
It has no native version history; you manage this manually through ZIP exports
It does not connect to Figma; there is no direct export path as of today
It cannot see your product's full context; it knows only what you show it in a session
It does not make judgments about whether a component decision is right for your users; that is your job

The honest summary: Claude Design dramatically accelerates the production of design artifacts. It does not replace the judgment required to know what to produce.

Part 2: Setting up your organisation's design system

The most powerful thing a design team can do with Claude Design is establish an organisation-wide design system. Once published, every session any team member opens will automatically use your brand's tokens, typography, component patterns, and layout conventions, not Claude's defaults.

This is also the most important control point for maintaining design authority. If you own the design system, you shape every output that comes out of your org workspace.

Prerequisites

You need admin permissions for design system setup within your Claude organisation. You also need at least one source asset: this can be a React component library, a slide deck, a brand PDF, or even a well-designed PowerPoint that reflects your visual identity.

The setup process

Step 1: Switch to your organisation. Open claude.ai/design. In the lower-left corner of the project picker, click the current organisation name and select your org (or create one). Complete the onboarding flow.

Step 2: Upload your brand assets. During onboarding (or afterward from organisation settings), upload the assets that define your product. Claude will read them and extract a reusable design system.

What to upload, in rough order of value:

Your React component library or design token file, if it exists in code. Claude reads the components and styles directly and builds from what you have already decided.
Existing prototypes, screenshots, or web flows that represent how your product looks today.
Brand documents: a style guide PDF, a well-designed deck, a marketing site. Claude extracts colours, layout patterns, and typographic choices from visual evidence.
Individual assets: logos, colour palette files, font specimens.

A single source is enough to start. Multiple sources give Claude more signal and produce a more accurate system.

Step 3: Review and validate. After uploading, Claude generates a design system (a UI kit) for your organisation. This typically includes: colour tokens (primary, secondary, semantic), typography scale (font families, sizes, weights), component patterns (buttons, cards, navigation elements), and layout conventions (spacing scale, grid system).

Validate it by creating a test project and prompting with something real: "Design a landing page for our product" or "Design a dashboard with our key metrics." If the output looks like your product, the system is working. If it looks generic, upload additional brand assets and iterate before publishing.

Step 4: Publish to your team. Once satisfied, switch the "Published" toggle on. From that point, every project created in your org workspace by any team member uses your design system instead of Claude's defaults.

Step 5: Update when your brand evolves. Go to organisation settings → open the design system → click Remix. Use the chat interface to tell Claude what has changed. Republish when done.

One important note for Enterprise teams: Claude Design is default off on Enterprise plans. An admin needs to explicitly enable it before anyone on the team can access it.

Part 3: Adding new components with micro-interactions

This is where the workflow gets precise. Adding a new component to a published design system, with full states and defined micro-interactions, is a six-step process. Skipping steps is where inconsistency and hallucinated features enter.

Step 1: Design inside your org workspace, not a personal one

This sounds obvious but is easy to get wrong. You must open Claude Design while switched to your org (not a personal workspace) so the published design system is active. The new component will be generated using your existing tokens and patterns, not Claude's defaults.

Describe the component with hard scope boundaries: "Design a toast notification component. Use only tokens from our design system. Variants: success, error, warning. No action buttons inside the toast. Do not add a progress bar unless I ask."

Negative constraints matter as much as positive ones. Claude pattern-completes from training data: it knows what "toast notifications usually have" and will add them unless you explicitly say not to.

Step 2: Define all states before touching animation

Before any micro-interaction work, prompt Claude to render every state as a separate visible frame: default, hover, active, focus (keyboard), disabled, loading, error, auto-dismiss in progress. One frame per state, no animation yet.

If you skip this and jump straight to animation, you will end up defining transitions between states you have not fully designed. This is the most common cause of incomplete component documentation.

Step 3: Specify micro-interactions with precision

The format that works is: trigger → what changes → duration → easing → follow-on effect. Vague prompts like "make it feel smooth" produce hallucinated animation choices. Precise prompts produce what you intend.

Examples:

"On appear: slides in from bottom 12px, fades from opacity 0 to 1. 180ms. Ease-out."
"On hover: background transitions to surface-hover token. 100ms. Ease-out. No other change."
"On dismiss: slides up 8px, fades to opacity 0. 160ms. Ease-in. Remove from layout after transition ends."

Give Claude one interaction at a time. Batching them leads to confusion about which easing applies to which trigger.

Step 4: Validate in Claude Code

Export the component session as a handoff bundle and pass it to Claude Code with: "Build only this component. Implement all states and transitions as specified. Make it interactive."

Test in a real browser. A 160ms ease-out that feels snappy in the Claude Design canvas can feel sluggish in a browser on a slower device, or vice versa. Catch this before the component enters the system. The canvas approximates animation; the browser is the truth.

Step 5: Write the token and documentation spec

Ask Claude to produce a structured component document: token names used, all state values, the full animation spec (trigger, property, duration, easing), when to use and when not to, ARIA role, keyboard interaction notes, and a status tag (Stable or Beta).

This document is what a developer reads six months from now. It is also what prevents the next designer from redesigning the same component in a later session.

Step 6: Commit via Remix

Go to organisation settings in Claude Design, open the published design system, click Remix. Paste the component spec into chat: "Add this as a new component to the system. Name it correctly. Apply our org tokens where applicable. Document it in the component library. Set status to Beta. Republish the design system."

Toggle Published on. Every project created in the org workspace now has access to the component, with its states, micro-interaction spec, and documentation attached.

Part 4: Versioning and how to store different design states

Claude Design does not have native version history. The canonical version of a design lives in Anthropic's cloud, tied to your project session. There is no "save as v2" button.

The workaround that teams have settled on is treating ZIP exports as commits.

Exporting a version: Open the project menu (three dots, top right) → Export → ZIP. The ZIP is a frozen snapshot of the current state. The original session continues to exist on Anthropic's side. The ZIP is your local, offline, archivable copy.

Storing versions: Name ZIP files by milestone: v1-exploration.zip, v2-stakeholder-approved.zip, v3-post-review.zip. Store them in Git alongside your codebase, or in a shared drive folder with a clear naming convention. This gives you a durable, non-Anthropic record of design decisions at each stage.

Share URLs for review: Claude Design generates share URLs with three access levels: view, comment, and edit. Use comment-only links for stakeholder review. This lets anyone leave feedback without modifying the canvas. The designer remains the sole editor.

The handoff bundle as the release artifact: When a design is approved and ready to build, the designer exports the handoff bundle. This becomes the release artifact, the equivalent of a tagged release in code. Treat it with the same discipline: only the designer creates the handoff bundle, and it only gets created after design sign-off.

Part 5: The designer's authority in an AI-powered team

This is the real question. When everyone on the team can open Claude Design and generate something that looks finished, how does the designer maintain authority over what actually ships?

The three structural control points

Own the design system. The designer sets up and controls the org design system. Since every team member's Claude Design output runs through that system, the designer shapes everything downstream, including outputs they didn't personally create. If the tokens are wrong, the output is wrong. This is the single highest-leverage point of authority.

Own the handoff bundle. Nothing goes into a handoff bundle to Claude Code without the designer's sign-off. The bundle is the canonical deliverable. A PM's Claude Design session is a proposal, not a deliverable. The designer's signed-off, exported, versioned bundle is the release. Treat this as a process rule: only the designer exports the final handoff.

Own the review gate. Use share URLs with comment-only access for all stakeholder review. No one modifies the canvas except the designer. Feedback flows through comments; decisions flow from the designer to the canvas.

How to handle AI-generated designs from non-designers

When a PM, founder, or developer generates something in Claude Design and shows it in a meeting, treat it the way you would treat a rough Keynote wireframe: as input, not output.

The designer looks at it, extracts the useful ideas, and rebuilds it properly in the org workspace, using the org design system, accounting for all states, edge cases, accessibility requirements, and system consistency. That rebuilt version is what goes into the handoff bundle.

The framing to establish with your team early: Claude dramatically compresses the cost of exploring ideas. It does not compress the cost of deciding which idea is right. That decision still requires a human with full product context, system knowledge, and accountability. That human is the designer.

What AI has genuinely changed

Production speed for design artifacts is dramatically faster. What used to take a designer three days of Figma work (building a component in all states, writing documentation, preparing a handoff) now takes a few hours in Claude Design. This is real.

The designer's role has shifted from production to curation, judgment, and system ownership. These are actually more senior functions, not lesser ones. A designer who builds and governs a high-quality design system that the whole team relies on is operating at a higher level than one who manually produces every screen.

What AI has not changed

The designer still needs to answer questions Claude cannot: Does this component conflict with a decision made six months ago? What happens at 360px on a slow connection? Does this interaction feel consistent with the rest of the product? Is this accessible to a screen reader user? Should we even be building this feature?

These are not small things. They are the actual work.

Part 6: The handoff from design to development

When a design is ready to build, Claude Design packages everything into a handoff bundle: design files, design system tokens, component structure, intent per page, and a README that instructs Claude Code on how to read and implement the files.

The developer (or Claude Code acting under developer guidance) receives this bundle and builds the production implementation. The handoff is a genuine one-direction step: design intent travels from Claude Design to Claude Code in a single documented artifact.

What developers do with the handoff

Claude Code reads the handoff bundle and generates production code matched to your existing codebase's framework and conventions. If you specify "Build in Next.js with Tailwind, match design tokens, make it responsive," Claude Code maps design tokens to framework components and generates working code.

But this is not the end of developer involvement; it is where the different nature of developer work becomes clear.

What developers still own

Production code quality. Claude Code generates correct, visually faithful code. Developers review it for performance characteristics, bundle size impact, tree-shaking, and technical debt. Claude Code optimises for correctness and fidelity, not for your specific app's performance budget or architectural conventions.

Component API design. A Toast component needs a well-designed props API: how it composes with other components, whether it supports slots, how it handles polymorphism. These decisions affect every team that consumes the component for years. A developer needs to validate the generated API against the existing codebase's conventions.

State management under real data. Design prototypes use representative data. Production components encounter null values, truncated strings, network errors mid-animation, and concurrent updates. Testing these conditions is developer work.

Git versioning and the publishing pipeline. Semantic versioning, changelog writing, breaking change governance, NPM publishing, Storybook integration, automated visual regression testing. None of this exists in Claude Design. The developer owns the mechanism that makes the design system usable as a dependency across multiple products.

Cross-browser testing. Safari, Firefox, older Android WebView, reduced-motion, forced-colors mode. The Claude Design canvas tests none of these. The developer does.

Part 7: Compatibility and edge cases: what developers encounter

This is where teams that have not thought carefully about the transition from Claude Design to production get surprised. The issues are real and predictable. Knowing them in advance prevents them from becoming crises.

CSS and styling conflicts

Token namespace collision is the most common early problem. Claude Design exports tokens as --color-brand-primary etc. If your existing app already uses the same variable names for different values, both will silently coexist and the later declaration wins, unpredictably. The fix is to prefix all design system tokens with a namespace before importing.

Global CSS reset conflicts trip up any team with an existing codebase. If your app applies a global reset (Normalize, Reset.css, Tailwind's preflight) after the design system styles load, button heights, input padding, and list margins will be overridden. Control cascade order explicitly with CSS Layers (@layer).

Dark mode mismatch affects teams with custom dark mode mechanisms. Claude Design generates tokens that respond to prefers-color-scheme. If your app uses a class-based dark mode toggle (.dark), design system components will not respond to it. Map your theme toggle to also set color-scheme on the root element.

Real data edge cases

Text overflow with long strings is guaranteed to surface in production. Claude Design uses placeholder text. Your users have 80-character names, multilingual product names with long compound words, and email addresses that overflow table cells. Every text container needs explicit overflow handling; this must be enforced as a component requirement before any component is marked stable.

Empty states are never designed. Every list, table, chart, and feed component was designed with data in it. When an API returns an empty array (new user, filtered results, deleted content), the component renders nothing, or a broken skeleton with no message. For every data-driven component, explicitly design empty, loading, and error states. These are not edge cases; they are the states new users see most.

Currency, date, and number formatting is locale-specific in ways that design cannot resolve. A component that displays "₹1,23,456.78" correctly for an Indian user will display incorrectly for a German or American user. Design system components should accept already-formatted strings as props, or use Intl.NumberFormat and Intl.DateTimeFormat internally. The component should not own locale logic.

Framework and architecture conflicts

Server-side rendering hydration mismatch affects Next.js and Remix teams specifically. Components that use Math.random() for IDs, Date.now() for timestamps, or read window on mount produce different HTML on server versus client. React throws a hydration error. Use useId() (React 18+) for stable component IDs, gate browser-only APIs behind useEffect, and audit every component for SSR safety before adding it to the system.

CSS Modules versus global class conflicts surface when design system components use one CSS approach and the existing app uses another. Standardise before adopting the system. In your Claude Code handoff prompt, specify explicitly: "Use CSS Modules" or "Use Tailwind utility classes only."

Animation library conflicts occur when Claude Code infers an animation library from your stack and it differs from what the team has already chosen. Two animation runtimes double bundle weight and create inconsistent easing across components. Specify your animation library in the handoff prompt, or default to CSS transitions: no library weight, no version conflict.

Accessibility gaps

Keyboard traps in modals are the most severe accessibility failure from generated components. Claude Code generates close buttons, but keyboard users pressing Tab will cycle through the entire page behind the modal without explicit focus management. Use the native <dialog> element (which handles this correctly) or a library like focus-trap-react. Set aria-modal="true" and move focus to the first interactive element on open.

Colour contrast failures are common with brand colours extracted from visual assets. A mid-tone brand colour (teal, coral, amber) used as a button background may fail WCAG AA contrast (4.5:1) against white text. Run every colour token combination through a contrast checker before publishing the design system. Document the passing combinations; do not leave this to each developer to verify.

Missing ARIA live regions leave screen reader users unable to receive any announcement when toast notifications appear, inline validation messages change, or real-time counters update. Toast components need role="status" (polite) or role="alert" (assertive). Validation messages need aria-live="polite". This is a small addition with significant impact.

Animation and vestibular disorders. Micro-interactions designed and tested on a MacBook Pro will disorient users with vestibular disorders if they cannot opt out. Wrap all @keyframes and transition declarations inside @media (prefers-reduced-motion: no-preference). The default state, without the media query, should have no animation. This is a one-line fix per component, but it requires deliberate attention, because Claude Code does not always add it.

Performance at scale

Unvirtualised long lists are invisible in a design prototype with ten items and catastrophic in production with 500 rows. Any list component that will receive more than approximately 50 items in production must use virtualisation. Design the component API to support this from the start; retrofitting it later is painful.

Animation performance on mid-range devices. Animate only transform and opacity. These run on the GPU compositor thread and never trigger layout. Animating width, height, top, or left triggers layout, the most expensive operation on slower devices. Add will-change: transform to elements that animate frequently. Test on a throttled CPU (Chrome DevTools → Performance → 4x slowdown) before marking any animated component stable.

Part 8: The mindset shift that makes everything else work

The deepest change AI tools bring to design is not about tools at all. It is about where skill lives.

For most of design history, skill lived partly in production: in the ability to work Figma quickly, to build a complex auto-layout precisely, to hand-craft a pixel-perfect screen. This production skill had real value because it was slow and difficult.

Claude compresses production time dramatically. A component that took four hours to build in Figma and document for handoff takes forty minutes in Claude Design. This is genuinely good news for designers; it frees time for higher-order work. But it also means that production speed is no longer a differentiator.

What remains permanently difficult, and therefore permanently valuable, is judgment:

Knowing which components need to exist in the system and which are one-offs
Deciding whether a proposed design actually serves the user or just looks good in a demo
Catching when AI has added features nobody asked for, because it pattern-completed from training data
Maintaining consistency across a product that has been built over years, by multiple designers, with evolving requirements
Understanding what accessibility means not as a checklist but as empathy for users who experience the product differently
Knowing when a design decision is final and when it needs to go back to the conversation

None of this can be prompted away. All of it requires a designer who has developed it deliberately over time.

The wave of AI tools is not the end of design as a craft. It is the beginning of a version of the craft where the low-effort production work is handled by AI, and the high-judgment creative and systemic work is what designers are hired, paid, and trusted to do.

The designers who adapt well are the ones who recognise this early and invest their freed time in deepening judgment, system thinking, and the kind of cross-functional leadership that makes them the person who defines what ships, not just the person who makes it look good.

Quick reference: the decisions that matter most

Set up the org design system before anyone else starts using Claude Design. Once it is published, all outputs are shaped by it. Setting it up after the team has started creates a mess of inconsistent sessions that are difficult to reconcile.

Establish the handoff bundle as the designer's deliverable, not the session. A session is exploration. The bundle is the release. This distinction, communicated clearly and enforced consistently, is what keeps design authority clear.

Use negative constraints in every production prompt. "Do not add X" is as important as "design Y." Claude pattern-completes toward what things usually have. Tell it explicitly what this thing specifically should not have.

Audit every component for three things before marking it stable: a 100-character string in every text field, an empty array in every list, and a Lighthouse accessibility audit. These three checks catch the majority of real-world failures.

Own the token namespace. Prefix all design system CSS tokens with your organisation's namespace before importing them into any codebase. This single decision prevents the most common CSS conflict in mixed environments.

Animate only transform and opacity in production components. Everything else degrades on real devices. Every micro-interaction that uses other properties is a performance debt that the development team will eventually have to repay.

Add @media (prefers-reduced-motion: no-preference) to every animation. This is not optional. It is a baseline accessibility requirement that costs one line of CSS per component.

This article was written in June 2026, based on Claude Design and Claude Code as currently available to Pro, Max, Team, and Enterprise users. Capabilities are evolving rapidly; check support.claude.com for the most current documentation.

The Designer's New Reality: How to Own Your Craft in the Age of Claude