Claude Design Field Guide

What you will build

The recurring example is Data Pipeline Studio, a fictional extension to a teaching baseline at /pipelines/customer-health/edit. The current product lets an analyst inspect a linear pipeline and edit one step at a time. The extension adds a directed acyclic graph editor, a richer node inspector, a resizable data sheet, and a file importer with mapping and recovery states.

The guide never treats the example as a blank canvas. The global shell, route, permissions, persistence, run APIs, typography, spacing, forms, buttons, tables, dialogs, notifications, and status patterns already exist. The assignment is to preserve that working product while changing a bounded part of it.

What the guide produces

By the end, you will have:

• A source-of-truth map that says which artifact governs each decision.

• A verified Claude Design system based on Figma's Simple Design System and its React codebase.

• A preservation brief for an existing screen.

• A working prompt sequence for a DAG canvas, node inspector, data sheet, and importer.

• A state matrix covering loading, error, permissions, stale data, conflicts, and recovery.

• A component-to-code map that separates reuse, composition, and legitimate extensions.

• A design review record and evidence gate.

• A Claude Code implementation prompt and handoff README.

• A Figma-native branch for teams that require editable frames.

• A guided capstone, answer key, scoring rubric, and final validation checklist.

How to use the field guide

Read Chapters 1 through 3 before opening Claude Design. Those chapters settle scope, sources, and the design-system baseline. Chapters 4 through 7 are the design loop. Chapters 8 through 10 cover review, handoff, implementation, and drift. The capstone runs the whole sequence with a single feature journey.

Each checkpoint asks for a small artifact. Keep the artifacts together. They become the handoff package; they are not homework that gets discarded after the prototype looks good.

Before you begin

You need an approved source package, repository access for implementation, and a Figma account for the native-Figma branch. Claude Design is beta on Pro, Max, Team, and Enterprise. Pro, Max, and Team have Design enabled by default; Enterprise owners enable the Design template under Organization settings > Artifacts. Design systems and standalone Claude Design have separate controls. Confirm the intended organization and surface before importing sources. See the Design admin guide.

Claude Code /design requires version 2.1.265 or later, an enabled Design template, and an artifact-capable session. Sign in with /login using claude.ai. API-key-only sessions cannot publish artifacts, and third-party cloud-provider sessions are unsupported. The artifact guide also lists organization-policy restrictions. Confirm account, provider, and policy before treating a missing command as a setup defect. See artifact availability.

Uploaded assets persist under the applicable retention policies. Anthropic documents unsupported Design data residency and restrictions for CMEK, ZDR, and HIPAA-ready configurations in the new Artifacts experience. Standalone audit logging and integrated artifact records have different coverage. Confirm those requirements with the organization owner before uploading proprietary work. See the Artifacts admin guide.

For this guide, use the public Simple Design System Community file and Figma's open-source figma/sds React repository. Duplicate the Community file into your own drafts before attempting connected inspection or editing. The public source remains untouched.

The workflow at a glance

The work is a loop. Frame the change, ground it in the real system, extend one bounded surface, specify the missing behavior, map every element, hand it off, implement it, and reconcile the rendered result. Drift and new evidence restart the loop.

1. Frame
2. Ground
3. Extend
4. Specify
5. Map
6. Hand off
7. Implement
8. Reconcile

Rendered evidence and drift restart the loop

Diagram relationships

• Frame → Ground
• Ground → Extend
• Extend → Specify
• Specify → Map
• Map → Hand off
• Hand off → Implement
• Implement → Reconcile
• Reconcile → Frame (feedback)

Keep the product surfaces on one state spine

The DAG canvas, node inspector, data sheet, and importer are coordinated views of the same selected node, fixture data, and document state. A change that appears on only one surface is a product defect, even when that surface looks polished in isolation.

SHARED STATEnode / fixture / document

Branches to:

• DAG canvasselection + graph
• Inspectorschema + draft
• Data sheetinput / output rows
• Importermapping + source

Diagram relationships

• SHARED STATE → DAG canvas
• SHARED STATE → Inspector
• SHARED STATE → Data sheet
• SHARED STATE → Importer

The chapters move from source authority to rendered proof. Worksheets and appendices remain part of the same operating package.

Build the source-of-truth stack

Use five layers:

1. Production behavior. The current application, routes, permissions, persistence, data contracts, and tested interaction rules.

2. Production component code. The components, props, tokens, accessibility semantics, and imports that engineers can actually ship.

3. Published design library. Component anatomy, variants, variables, layouts, and design guidance.

4. Representative shipped screens. Evidence for composition, density, hierarchy, responsive behavior, and local conventions.

5. Product intent. The approved problem, target user, success journey, non-goals, and acceptance tests for the change.

When two layers disagree, record the conflict. Do not let Claude select a winner through visual improvisation.

Freeze the preservation boundary

An extension prompt needs two lists: what may change and what must remain stable. The second list is usually more important.

For Data Pipeline Studio, preserve:

• The global app shell and left navigation.

• Breadcrumb, pipeline name, environment badge, and last-run metadata.

• Save, Run, and overflow actions.

• Existing typography, spacing, controls, tables, dialogs, status badges, and notifications.

• Permissions, routing, persistence, and run APIs.

• Current copy outside the approved feature surface.

Change:

• The central linear editor becomes a DAG workspace.

• The right-side editor becomes a schema-driven node inspector.

• The collapsed preview becomes a resizable data sheet.

• The basic file-upload dialog becomes a multi-stage importer.

The boundary lets the team review a small diff. Without it, every generated screen becomes a redesign proposal.

Name the baseline fixture

Claude needs a stable example that can appear in every screen and state. Use one fixture pipeline:

1. Customers CSV - source

2. Normalize Email - transform

3. Validate Customer Schema - quality gate

4. Publish to Warehouse - destination

5. Quarantine Invalid Rows - proposed branch

Use customers-august.csv and its JSON equivalent for one six-record dataset. The importer proposes customer_id and health_score mappings, but leaves the required contact_email to email mapping unresolved. The final confirmation accepts all three mappings and the chosen recovery policy. No graph change occurs before confirmation.

Normalize Email trims outer whitespace and lowercases all six emails. The schema gate requires a nonempty unique customer ID, an email with a domain suffix, and a numeric health score from 0 to 100. Three records pass. C003, C004, and C005 go to quarantine or are excluded under Reject invalid rows. CSV row numbers include the header; JSON uses the corresponding record ordinal plus one. A production parser must track physical file locations separately, including blank and multiline records.

Use the executable teaching contract

Download the local exercise package and extract it. From the extracted folder, start the companion application:

Use Node.js 22 or later and keep the bundled sds/ folder beside example/. Dependency installation needs the npm registry or a populated local cache. Leave the server running while you use the browser; stop it with Ctrl+C when finished. No Claude or Figma account is needed to run this application.

Open http://127.0.0.1:4192/pipelines/customer-health/edit?baseline=1 for the baseline, then remove the query to open the extension. If you have used the application before, choose Teaching test controls > Reset fixture before starting a fresh journey.

Start from the preserved linear baseline at /pipelines/customer-health/edit?baseline=1. Open the extension at the same route without the query. Preserve the shell text, navigation, pipeline identity, environment badge, Save, Run, permissions, and browser persistence. This baseline was authored for the exercise; it is not a shipped product or a Claude Design export.

1. Choose the fixture through the file picker or drop zone. Confirm contact_email -> email and all proposed mappings. Choose Send to quarantine for the main journey.

2. Confirmation replaces the unconfigured Customers CSV placeholder with a new source ID, august, named Customers CSV (August import). It preserves downstream nodes, removes the placeholder's old edge, selects the new source, and opens its raw preview. Import is atomic; cancel or failure leaves the graph unchanged. The local exercise supports one committed import per reset.

3. Connect august to normalize. The normalized preview contains the same six customer IDs. Add quarantine, then connect validate to quarantine. Keep normalize -> validate -> warehouse intact.

4. Save before Run. The configured warehouse target starts as missing-warehouse, so the intended first run fails at warehouse. The fixture's required target is customer_health; a helper hint must not claim it is already configured. Preserve the failure across reload.

5. Select the failing node, set its target to customer_health, Save, and Run again. Expect three published IDs (C001, C002, C006), three quarantined IDs (C003, C004, C005), and zero rejected rows. Under Reject invalid rows, expect three published, zero quarantined, and three rejected.

6. Attempt validate -> august and normalize -> quarantine. The first would create a cycle; the second has incompatible ports. Each attempt must explain the reason and leave the graph unchanged. Deleting a required downstream edge must block Run.

Save failure must preserve the draft and keep Run disabled until Save succeeds. The local conflict control changes only a simulated revision; explicit reapply is safe for that fixture. A real concurrent edit needs a content comparison and reviewed merge. Warehouse lookup, row publication, quarantine storage, server authorization, and telemetry remain implementation requirements.

The local example exercises buttons, inputs, selects, dialogs, tags, and tables from a pinned SDS React snapshot. Its named connection list supplies the non-pointer graph path. Pointer port dragging, drawn edge geometry, virtualized large datasets, resizable columns, a complete schema-driven inspector, and screen-reader behavior remain separate acceptance work. Local screenshots and passing tests do not establish that Claude Design produced the workflow.

Define the success journey

The recurring journey is:

1. Open the existing pipeline.

2. Import customers-august.csv.

3. Resolve one required column mapping.

4. Create a source node from the import.

5. Connect it to Normalize Email.

6. Inspect transformed rows in the data sheet.

7. Add a quarantine branch for invalid records.

8. Save and run the pipeline.

9. Identify and repair a failed node.

10. Run the pipeline successfully.

Every surface in the guide serves this journey. Anything else is either a reusable system concern or a non-goal.

Write the first artifact: the extension brief

Use a one-page brief with these fields:

• Current route and baseline screen.

• Primary and secondary users.

• User problem and job to complete.

• Success journey.

• Change boundary.

• Preservation boundary.

• Supported viewports.

• Data fixture.

• Existing behavior that cannot regress.

• Open product decisions.

• Approval owner for each decision.

Chapter checkpoint

• The team can point to the authoritative source for behavior, components, Figma anatomy, and product intent.

• The existing screen has a named preservation boundary.

• One fixture carries through the complete journey.

• Non-goals are explicit.

• Claude has analyzed the baseline without generating a replacement screen.

Sources 1-4, 18-20. Author synthesis: the source-of-truth method.

Duplicate before you connect

Open the Simple Design System Community file and choose Make a copy. Work in the copy. Figma MCP can read content the authenticated account has permission to view or edit; native writing to an existing file requires edit permission and a Full seat. Confirm that the connected account can access your working copy before inspecting or editing it. See Figma access and permissions and write to canvas.

Keep the original source URL in the project record:

https://www.figma.com/design/AIulMBySUibjRtykdngCUp/Simple-Design-System--Community-?node-id=3-5

Record the duplicate's file URL separately. Do not overwrite the original URL in source notes; the two links serve different purposes.

Pair the Figma file with the codebase

Use Figma's public figma/sds repository as the code counterpart. The project identifies itself as an alpha base system that demonstrates Variables, Styles, Components, Code Connect, and a React implementation.

The code is organized into:

• src/ui/primitives - reusable controls that should not be reduced further.

• src/ui/compositions - example arrangements of primitives.

• src/ui/layout - Flex, Grid, and Section helpers that may not have direct Figma equivalents.

• src/ui/icons - generated icon components.

• src/figma - Code Connect mappings.

• src/stories - Storybook examples and component states.

• src/theme.css - generated CSS variables from Figma tokens.

Inventory the components you can reuse

Use the following SDS React primitives as a starting point. Confirm their names and supported variants in your selected repository revision:

The inventory prevents two opposite mistakes: inventing controls the system already has, and forcing an application-specific graph element into a generic primitive.

Inventory the tokens

Simple Design System exposes semantic color families for background, border, icon, and text across brand, default, neutral, positive, warning, danger, disabled, and utility roles. Its spacing scale runs from space-050 through large layout values; radius, focus-ring stroke, icon sizes, and typography scales are also defined.

Use semantic tokens rather than literal values in every prompt and handoff. A node failure should resolve to the system's danger roles. A selected node may use the brand border and focus-ring rules. A canvas grid may require one new semantic token, but the grid should still derive from existing neutral primitives.

Build a compact context packet

Claude Design can import a repository, but a focused package is easier to validate than an entire monorepo. Include:

• The duplicated Figma working-file link.

• src/ui/primitives, src/ui/layout, and only the relevant compositions.

• src/theme.css and token-generation notes.

• Relevant src/figma Code Connect files.

• Relevant Storybook stories.

• The current Pipeline Detail route and nearby tests.

• Two or three representative shipped screens.

• The extension brief and fixture schema.

Exclude:

• .git, node_modules, build output, generated caches, and unrelated packages.

• Deprecated components.

• Concept work that does not match production.

• Screens containing private customer data.

• Large asset folders that do not affect the target feature.

Connect Code Connect after duplication

The Simple Design System README still documents documentUrlSubstitutions in figma.config.json and expects a fresh duplicate to preserve node IDs. Verify sample IDs in the chosen copy, then update the file keys. Record the repository revision and mapping format before validating.

Code Connect is documented for Dev or Full seats on Organization and Enterprise plans. The current CLI quickstart recommends framework-agnostic template files; existing SDS mappings remain inputs from their own repository revision. Do not migrate parsers or publish mappings merely to run the example. Follow the team's approved process if mapping publication is authorized. The CLI requires Node.js 18 or newer and a locally stored token with Code Connect Write and File content Read scopes. See the Code Connect introduction and CLI quickstart.

Code Connect can supply imports, properties, snippets, source paths, and team instructions. CLI mappings and UI mappings provide different detail: a CLI mapping can omit an import when its source/import fields are missing, and UI mappings do not include full snippets by default. Inspect one returned mapping before relying on it. Keep mappings current. See Code Connect integration.

Chapter checkpoint

• The Community source is untouched and a working duplicate exists.

• The Figma file and React package are paired.

• Components, tokens, Storybook examples, and Code Connect mappings are inspectable.

• The context package excludes unrelated or unsafe material.

• DAG-specific gaps are named before generation.

Sources 2, 6-12, 18-25. Pairing the Figma library with its React implementation.

Establish the system in Claude Design

Choose the setup path that matches the source. For a React product system, the current Claude Code command reference documents /design-login to authorize design-system access and /design-sync [hint] to convert and upload the repository's system to Claude Design. First-time verification can take hours for a large repository. Treat conversion and upload as part of the operation; scope the source package before running it. These commands require the Anthropic path and claude.ai access, and are unavailable through the documented cloud-provider and apps-gateway paths.

For a brand system, use chat with approved fonts, logos, files, and design references. Manage integrated systems in Settings > Design systems. A system created at claude.ai/design can move through the Design sidebar's migration banner, but the migrated guide, tokens, and components need review. See the design-system setup guide.

Standalone setup remains a separate path: select the organization at claude.ai/design, upload or link approved assets, review the generated system, and test it before using the Published toggle. In integrated Artifacts, confirm the attached system and selected organization default. Publishing a system and setting a default are separate decisions. Enterprise administrators can reserve publication, default selection, and deletion for designated users. See the Artifacts admin guide.

Use the built-in Claude Code commands for setup. If a command is absent or authorization fails, record the installed version, account/provider, enabled template, and exact error before changing configuration.

Use /design [brief] for the documented Claude Code artboard workflow. Inspect the returned artifact in a desktop browser. Test whether the chosen surface supports the interactive states your product example needs; broad Design help and the CLI reference describe different scopes. Do not infer complete import/export/sync parity from the command name.

Do not paste private tokens into chat or commit local credentials. Follow the repository's existing secret-handling rules.

Preserve the reviewed baseline

Anthropic documents asking Claude to save the current project before trying another direction, but also lists version history as unavailable. Export a reviewed baseline, record its date and system revision, and verify that the saved artifact opens before experimenting. Treat reliable restore and correction persistence as tests, not assumptions. See Design revisions and limitations.

Give sources a clear authority order

Run three known-screen tests

Choose tests that expose different parts of the system:

1. A settings form tests fields, labels, descriptions, errors, toggles, actions, and vertical rhythm.

2. A dense operational table tests data density, search, filters, pagination, status, empty states, and overflow.

3. A confirmation flow tests dialog anatomy, destructive language, focus handling, and notification behavior.

Do not judge the tests from memory. Compare them to the components, tokens, and representative screens in the source package.

Score system fidelity

Use a ten-point sample on each test screen. Select visible elements across the page and classify each one:

• Exact reuse - correct component, variant, token, and composition.

• Valid composition - existing primitives combined according to known patterns.

• Cosmetic match - looks close but does not resolve to an approved component or token.

• Invented - no source evidence and no explicit proposal label.

• Unverifiable - source package is insufficient.

The system passes when every sampled element is exact reuse or valid composition, or when an exception is explicitly documented and approved. A visual match with unverifiable implementation identity does not pass.

Test correction behavior

Deliberately introduce one correction: ask Claude to replace an invented filter control with the named SelectField and existing Tag pattern. Then regenerate a nearby state. If the correction holds only on one frame and disappears in the next, the system is not stable enough for feature work.

Decide whether to publish

Publish the organization system only when:

• Component names and variants match the source.

• Semantic tokens are used consistently.

• Known-screen composition matches the product.

• Corrections persist across regeneration.

• Missing patterns remain visibly labeled.

• A design-system owner has reviewed the output.

If the system fails, improve the sources before adding more prompt detail. Claude's own documentation says import quality depends on source quality. Prompting cannot repair an ambiguous or contradictory system indefinitely.

Chapter checkpoint

• The imported system has been tested on known work, not only on a new concept.

• Component identity and token use have been sampled.

• One correction has persisted through regeneration.

• Missing patterns are explicit.

• A human owner has approved publication or recorded why it remains a draft.

Sources 1-4, 11, 19-20. Product-preservation synthesis.

Start from the current route

Create a Claude Design project with the validated system attached. Add the current Pipeline Detail screen as a screenshot, existing design asset, web capture, or linked code reference. Include the relevant feature directory and current tests.

Review the first diff

The first review asks five questions:

1. Did the shell remain stable?

2. Did the central editor change without moving unrelated controls?

3. Are the pipeline steps the same fixture throughout?

4. Can the user select a node and understand the graph direction?

5. Are new graph elements labeled as proposals rather than disguised system components?

Reject the first pass if the answer to either of the first two questions is no. A prettier shell is still scope drift.

Add graph behavior in small increments

The DAG interaction contract includes:

• Pan, zoom, fit-to-view, and reset.

• Pointer and keyboard node selection.

• Node movement without changing pipeline semantics.

• Edge creation between compatible ports.

• Cycle rejection and incompatible-connection explanations.

• Undo and redo for movement, connection, and deletion.

• Inspectable nodes while a run is active, with structural edits locked.

• Status communicated through icon, label, and color.

Add one group at a time. After each change, replay the baseline journey and inspect the preservation boundary.

Define proposed graph components

Do not add a generic "Card" variant for a graph node merely because both are rectangles. A pipeline node has operational semantics, ports, selection, validation, execution states, and keyboard behavior. Treat it as a product-specific component composed from system primitives.

Each proposed component needs a design owner, a code owner, a variant model, accessibility notes, and a production import path before the team promotes it to a shared library.

Compare alternatives without multiplying scope

Use alternatives for a specific decision, such as node density or branch readability. Do not ask for three complete product redesigns.

Chapter checkpoint

• The baseline shell remains intact.

• The DAG uses the same pipeline fixture and real product language.

• Navigation, selection, movement, connections, and rejection are shown.

• Proposed graph components are visible in the system delta.

• Undo, keyboard focus, and running-state locks are part of the design.

Sources 1-3, 19. Prompts are author synthesis.

Upgrade the node inspector

Selecting a node opens its schema-driven configuration. The inspector must:

• Load the correct schema for the selected node.

• Show valid, dirty, invalid, testing, success, failure, and locked states.

• Preserve valid drafts when the user switches nodes.

• Warn before discarding invalid edits.

• Block Save when required fields are invalid and link the error summary to the affected controls.

• Run Test node against the fixture data without running the complete pipeline.

• Use the existing confirmation-dialog pattern for destructive actions.

Turn the preview into a data sheet

The data sheet is a resizable bottom surface with collapsed, half, and expanded positions. It shows the selected node's actual input or output fixture. It supports column resizing, sorting, filtering, and cell inspection.

The sheet must distinguish:

• Live data.

• Cached data.

• Stale data.

• Truncated data.

• Sample data.

• No available data.

• Load failure.

The distinction needs language and status treatment. A green dot with no label is not sufficient.

Extend the importer

The importer accepts CSV and JSON through a file picker or drop zone. It should:

• Show parsing progress and allow cancellation.

• Infer headers and types without silently committing them.

• Require mapping for mandatory fields.

• Identify malformed rows by row and column.

• Offer Reject invalid rows or Send to quarantine.

• Create a configured source node after a successful import.

• Open the imported data in the preview.

Use a staged flow because the user is making a series of consequential choices. A single overloaded dialog makes progress, validation, and recovery difficult to read.

Make the surfaces agree

After designing the three surfaces, run a cross-surface review:

• The selected node in the DAG matches the inspector title and data sheet source.

• Dirty state appears once at the document level and is explained locally where needed.

• Import success creates the same source node that appears in the graph.

• Mapping errors use the same field-error language as the inspector.

• A data-sheet error row focuses the exact failed node.

• Running-state locks are consistent across graph, inspector, importer, and Save actions.

• The data sheet never displays unrelated placeholder rows.

Chapter checkpoint

• The inspector, data sheet, and importer share one fixture and state model.

• The system's existing form, table, dialog, status, and feedback patterns are reused.

• Proposed product patterns are explicit.

• Import success creates a real graph consequence.

• Error rows, fields, and nodes link to one another.

Sources 1-3, 11, 19-20. Author synthesis: extending the node editor and inspector.

Build the product state matrix

The matrix is not a request for one frame per cell. Use representative screens, component states, and annotated transitions. The goal is to prove coverage without burying the team under artboards.

Write transitions as contracts

For each consequential action, specify:

• Trigger - what the user or system does.

• Precondition - what must already be true.

• Immediate feedback - what changes before the result returns.

• Success result - data, UI, focus, and status.

• Failure result - what remains stable and what recovery appears.

• Persistence - what survives navigation or reload.

• Telemetry - the event or error the product records.

Example:

Use named evidence for each state

Every state should connect to one of these evidence types:

• A current production pattern.

• A design-system component or token.

• A product requirement.

• An API or data contract.

• An accessibility requirement.

• A recovery rule.

If a state has only visual evidence, it is not ready for handoff.

Specify version conflicts and stale data

Two failure modes deserve explicit treatment:

Version conflict. Another person or process changes the pipeline after the user begins editing. The product must not overwrite the newer version silently. Show what is compared, what can be reapplied, what must be reviewed, and how the user exits safely.

Stale preview. The graph or node configuration changes after preview data was generated. The data sheet must keep the rows inspectable while clearly marking them stale and offering a refresh. "Sample" and "stale" are different conditions and should not share ambiguous copy.

Keep copy operational

Error copy should answer four questions:

1. What happened?

2. What was preserved?

3. What can the user do next?

4. Where can they get more detail?

Avoid messages such as "Something went wrong" when the product knows the failed node, row, column, connection reason, or permission rule.

Chapter checkpoint

• The complete state matrix has a disposition.

• Consequential actions have transition contracts.

• Version conflict and stale data have distinct recovery paths.

• Errors say what happened, what was preserved, and what to do next.

• Unresolved API or product dependencies remain visible.

Author synthesis: application states and transitions.

Set the viewport contract

Data Pipeline Studio supports:

• Primary: 1440 × 900 editing.

• Minimum: 1024 × 768 editing.

• Mobile: view-only; editing is explicitly out of scope.

At the minimum viewport, the canvas, inspector, and data sheet cannot all keep desktop dimensions. Define how the layout reallocates space:

• The inspector may become an overlay or a narrower dock.

• The data sheet may open to a fixed half-height with an explicit expand action.

• The canvas toolbar remains reachable and does not cover nodes.

• The selected node stays visible when adjacent surfaces open.

• Save and Run remain available without horizontal scrolling.

Provide a keyboard model for the graph

The graph needs an equivalent non-pointer path. A practical contract may include:

• Tab enters the canvas toolbar and graph region in a predictable order.

• Arrow keys move focus among nearby nodes or use a documented list order.

• Enter opens the selected node in the inspector.

• A keyboard command starts connection mode; compatible destinations are announced.

• Escape cancels connection, drag, menu, or dialog states without changing the graph.

• Delete asks for confirmation when removal has downstream consequences.

• Undo and redo are available through standard shortcuts and visible actions.

• Focus returns to a sensible element after Save, import completion, deletion, or error recovery.

The exact shortcut set needs usability and assistive-technology review. The prototype should show the model and surface conflicts before implementation.

Make operational status redundant

Node and run status must use more than color. Combine:

• A semantic icon.

• A short label.

• A semantic color token.

• An accessible name or announcement.

• Optional timing or progress detail.

Animation should communicate change without becoming the only way to notice it. Respect reduced-motion preferences in implementation.

Audit fields, dialogs, and the data sheet

Check:

• Every field has a programmatic label and linked description or error.

• Required fields are identified without color alone.

• Error summaries link to the affected controls.

• Dialogs have a clear title, initial focus, trapped focus, Escape behavior, and return focus.

• Sort direction and selected rows are announced.

• Resizable columns and the sheet handle have keyboard equivalents.

• Truncated cells can be inspected without hover.

• Import progress and cancellation are announced.

• View-only and forbidden actions are explained before or when invoked.

Separate design evidence from implementation evidence

The design can prove visible focus treatment, intended tab order, status redundancy, copy, layouts, and annotated semantics. It cannot prove DOM order, ARIA behavior, screen-reader output, pointer target size in the rendered application, or reduced-motion implementation. Those become engineering acceptance tests.

Chapter checkpoint

• Both supported editing viewports are designed and compared.

• The mobile boundary is explicit.

• The graph has a non-pointer interaction model.

• Focus, status, errors, and dialog behavior are specified.

• Design evidence is separated from rendered implementation evidence.

Sources 3, 6-10, 21-25. Component-disposition synthesis.

Review four kinds of evidence

1. Scope evidence

• Baseline and final screenshots show the approved diff.

• Preserve annotations identify regions that should not change.

• The change log names every intentional modification.

• Rejected directions are removed or clearly archived.

2. System evidence

• Every visible primitive resolves to an approved component, an approved variant, a valid composition, or a documented proposal.

• Semantic tokens replace raw color, spacing, type, radius, and focus values.

• Component names match the Figma library and code package.

• Code Connect mappings exist for shared production components where the workflow depends on them.

3. Behavior and data evidence

• The success journey is interactive from import to successful re-run.

• Invalid actions do not mutate the graph.

• The shared fixture appears consistently across surfaces.

• State and transition contracts cover failure and recovery.

• Data provenance is visible.

4. Accessibility and responsive evidence

• Keyboard and focus behavior are specified.

• Status never depends on color alone.

• The two supported viewports have collision-free layouts.

• Implementation-only tests are listed.

Use the component disposition table

Audit Simple Design System precisely

The SDS React package used for this example includes a Table primitive. Its checked-in Figma component metadata lists a Table icon but no Table component. Inspect your working Figma copy before assigning a native component to the data grid. If no matching component exists, build a product-specific Figma extension using SDS tokens and primitives.

This distinction is the point of the gate. "Table exists" is not one fact. It can be true in code and unverified in Figma at the same time.

Run a challenge review

Ask one reviewer to look for reasons the work should not pass. Useful challenges include:

• Show where the selected node, inspector schema, and preview data disagree.

• Find a visible value that does not resolve to a semantic token.

• Attempt to create a cycle and confirm the graph remains unchanged.

• Shrink to the minimum viewport and open both adjacent surfaces.

• Navigate the critical journey without a pointer.

• Reload after Save, failure, and repair.

• Identify every piece of prototype code that should not enter production.

Gate decision

Use one of three outcomes:

• Pass for handoff. No unresolved High finding; component and behavior evidence are complete.

• Conditional pass. Bounded Medium or Low follow-up has a named owner and does not change the implementation approach.

• Hold. A High finding, unverified component identity, missing recovery path, or unresolved product decision would force engineering to guess.

Chapter checkpoint

• The review covers scope, system, behavior, data, accessibility, and responsiveness.

• Every visible pattern has a disposition.

• Code and Figma evidence are not conflated.

• A challenge review has tried to break the proposal.

• The gate decision and unresolved items are recorded.

Sources 1-3, 19, 22-23. Review framework is author synthesis.

Clean the design project first

Before export:

• Name screens, components, states, and flows clearly.

• Remove unused experiments or move them to an explicit archive.

• Record key product decisions in the conversation or decision log.

• Add edge states, data assumptions, and unresolved items.

• Confirm the final frames use the shared fixture.

• Label prototype-only code and simulated behavior.

• Run the design evidence gate.

Build the handoff bundle

Engineering should receive:

• Baseline screenshots with preserve annotations.

• Final screens and interactive flow.

• Screen-by-screen change log.

• Component-to-code import map.

• Design-system delta and token changes.

• State matrix and transition contracts.

• Exact interface and error copy.

• Keyboard and accessibility contract.

• Responsive snapshots.

• Pipeline and import fixtures.

• Scope, non-goals, and unresolved decisions.

• Suggested file and path impact map.

• Acceptance-test checklist.

• Visual-regression baselines.

• A README that says which prototype code is reference only.

Write the component-to-code map

The final map should contain real repository import paths, not the generic examples above.

Export from Claude Design

The Design help guide lists ZIP, PDF, PPTX, standalone HTML, and handoff to a local coding agent or Claude Code Web. Google Slides export is available only at claude.ai/design. For Claude Code /design artboards, the artifact guide specifically documents per-artboard PNG or PDF. Choose the format and handoff on the actual surface; the lists do not prove every surface has identical controls.

When available, choose Export > Hand off to Claude Code and the intended local or web destination. Record the bundle URL, access scope, export time, and a file/content inventory. Test recipient access. Add the team-owned handoff template, component map, fixtures, acceptance tests, and decision log when the export does not contain them. Read/import the bundle first; allow repository edits only under the feature's implementation authority.

Give engineering acceptance tests, not adjectives

Critical tests:

1. The existing shell, route, permissions, Save action, and Run action remain functional.

2. Every visible primitive resolves to an approved component or documented extension.

3. A valid connection is created; a cycle and incompatible connection are rejected without modifying the graph.

4. Editing a node marks the document dirty, persists after Save and reload, and protects invalid drafts. Save failure keeps Run disabled and must not persist the unsaved draft through Run.

5. Import is blocked until all mappings and the recovery choice are confirmed; cancel and parse failure create no source. Completion replaces the placeholder with source ID august.

6. Preview after Normalize Email shows transformed fixture data.

7. The warehouse run fails with target missing-warehouse, focuses that node, and preserves the error after reload. Changing the target to customer_health, saving, and re-running yields three published and three quarantined records.

8. Undo and redo restore node position and graph structure.

9. Keyboard actions have visible focus and an equivalent non-pointer path.

10. Loading, empty, stale, truncated, permission, conflict, and error states are rendered and recoverable.

11. No raw colors, duplicate primitives, inline production styles, or undocumented components are introduced.

12. Visual checks pass at both supported viewports without inspector or sheet collisions.

Record implementation deviations

Engineering will discover constraints the prototype did not model. A deviation log keeps the design and product record honest.

The goal is not pixel identity at any cost. The goal is an approved explanation for every meaningful difference.

Chapter checkpoint

• The design project is clean and named.

• The bundle includes intent, mappings, data, states, tests, and unresolved items.

• Prototype code is visibly separated from production mappings.

• Claude Code has an inspect-before-edit prompt.

• Engineering has objective acceptance tests and a deviation log.

Sources 1, 3, 19. Engineering handoff and implementation review.

Move between the applications

A person owns the sign-ins, organization and file choices, and review of results. Use a coding agent for source inspection, implementation, tests, and connected design tools. Carry the same brief and fixtures between applications.

At each handoff, confirm that the next account can open the artifact. If automation cannot reach a signed-in application, continue there yourself and bring the resulting URL or files back to the coding agent. Record permission denials, connection failures, and actions not attempted separately. A successful login alone does not establish access to a particular system, export, or file.

The final proof lives in the running product. Source inspection and passing tests matter, but neither proves that the right tab, route, state, and viewport render correctly.

Implement in bounded slices

A practical order is:

1. Graph data model and read-only rendering.

2. Selection, navigation, and inspector integration.

3. Movement, connection validation, undo, and redo.

4. Data sheet bound to the selected node's fixture.

5. Importer parsing, mapping, recovery, and source-node creation.

6. Save, run, failure, repair, and successful re-run.

7. Version conflict, permissions, stale data, and remaining edge states.

8. Responsive and accessibility implementation.

Each slice should pass its local tests and the preservation checks before the next slice begins.

Use four verification layers

Static checks

Run the repository's type check, lint, formatting, dependency, and build commands. Confirm that no raw design values or duplicate primitives entered the feature.

Automated behavior checks

Test graph rules, state transitions, persistence, importer parsing and mapping, fixture transformation, run errors, retry, permissions, conflict handling, and undo/redo.

Rendered visual checks

Capture the exact route and required states at 1440 × 900 and 1024 × 768. Compare the shell, major geometry, focus treatment, status, dialogs, sheet positions, and error states to approved references.

Human review

Design reviews conformance and intentional deviations. Engineering reviews architecture, state, data, and maintainability. Product reviews scope, copy, and success journey. Accessibility review covers keyboard and assistive-technology behavior in the rendered application.

Report proof boundaries directly

Use language such as:

• "Unit and integration tests passed."

• "The route rendered at both required viewports."

• "Keyboard navigation was checked through the critical journey."

• "Screen-reader output remains unverified."

• "The design-system owner approved the two proposed product components."

Do not collapse these into "production-ready" unless the team has defined and met that gate.

Use the native-Figma branch when required

Direct native-Figma export is not established by the reviewed Claude Design documentation. If editable Figma content is required, use Figma's separate remote MCP workflow. Figma recommends its Claude Code plugin, which bundles server settings and skills; manual HTTP setup is also documented. Code Connect adds implementation context where eligible and configured.

Figma documents two paths with different permissions:

1. Figma-first: use_figma creates or updates native frames, components, variables, and Auto Layout. Writing needs a Full seat; modifying an existing file also needs edit permission. Load the installed Figma write-to-canvas skills and inspect first. The tool currently has a 20kb output-response limit, no image-asset or custom-font support, and requires manual component publication before Code Connect completes. See write to canvas.

2. Code-first: generate_figma_design captures live browser UI into editable layers. Any seat can use this tool in Drafts; an existing file outside Drafts needs a Full seat and edit permission. This path is distinct from native writing. Inspect captured instances and variable bindings before claiming design-system reuse. See code to canvas.

Use the documented code-to-canvas workflow to capture browser UI into Figma. MCP read quotas vary by plan and seat; check the current access table and authenticated account before planning a full-file inventory.

Reconcile without hiding drift

At the end of implementation:

• Update the design decision record with approved changes.

• Update Figma frames if Figma is an active source of truth.

• Update Code Connect mappings for approved shared components.

• Keep the baseline, approved design, and rendered implementation distinguishable.

• Close or assign every deviation.

• Add regression baselines for the final states.

Avoid overwriting the approved design with a capture that removes the record of what changed. Reconciliation should preserve the chain of evidence.

Monitor future changes

The handoff is a starting point for ongoing maintenance. Track:

• Component or token changes that affect the feature.

• Graph-schema or API changes.

• Import error and mapping rates.

• Save conflicts and failed runs.

• Accessibility regressions.

• Layout regressions at supported viewports.

• Design/code drift and stale Code Connect mappings.

Chapter checkpoint

• Implementation proceeded in bounded slices.

• Static, behavioral, rendered, and human evidence are reported separately.

• The actual route and states were rendered at both supported viewports.

• The native-Figma branch was used only if the team requires it.

• Design and code drift remain visible and assigned.

Sources 6-10, 21-25. Native Figma editing and component mappings.

Capstone rules

• Work from the duplicated Simple Design System file and relevant React package.

• Keep the public Community source untouched.

• Preserve the existing shell, route, permissions, Save, Run, persistence, and unrelated copy.

• Use the exact six-row fixture and expected outputs from Chapter 1 throughout. Record CSV/JSON hashes and each invalid row and column. Keep the companion application separate from the prototype you generate in Claude Design.

• Label new product components and tokens.

• Do not treat generated prototype code as production code without a real mapping.

• Do not pass the capstone with an unresolved High finding.

Phase 1 - Frame and ground

Produce:

• A source-of-truth stack.

• An extension brief.

• Baseline and preserve annotations.

• A compact context package.

• A design-system inventory and gap list.

Use the baseline-analysis, system-inspection, and draft-system prompts from Chapters 1 through 3. Run the settings form, dense table, and confirmation-flow tests before starting the DAG.

Phase 2 - Build the bounded DAG extension

Produce:

• The approved shell with a DAG replacing only the linear editor.

• Canvas navigation.

• Node selection and movement.

• Valid and rejected connections.

• Undo and redo.

• A proposed component sheet for nodes, ports, edges, toolbar, and run status.

Demonstrate that a cycle and incompatible connection leave the graph unchanged.

Phase 3 - Complete the working surfaces

Produce:

• A schema-driven inspector for Validate Customer Schema.

• A data sheet showing the output of Normalize Email.

• A staged importer for customers-august.csv.

• Cross-surface consistency annotations.

The importer must block completion until the required mapping is resolved. Successful import must create the configured source node and open its preview.

Phase 4 - Specify states, accessibility, and viewports

Produce:

• A complete state matrix.

• Transition contracts for Create edge, Import, Save, Run, and Repair.

• A version-conflict sequence.

• A stale-preview sequence.

• 1440 × 900 and 1024 × 768 layouts.

• A keyboard and focus contract.

• An implementation-only accessibility test list.

Phase 5 - Review and hand off

Run the design evidence gate. Produce:

• A component disposition for every visible pattern.

• A token audit.

• A challenge-review record.

• A gate decision.

• A handoff README.

• A component-to-code map with real import paths.

• The state matrix, transition contracts, fixtures, copy, responsive references, accessibility contract, acceptance tests, and unresolved items.

Export the Claude Design handoff only after the gate passes or receives a bounded conditional pass.

Phase 6 - Plan implementation and proof

You do not need to implement a production application to complete the design capstone, but the implementation plan must be executable.

Produce:

• The exact Claude Code implementation prompt.

• A bounded implementation sequence.

• Static, behavior, visual, and human review commands or procedures.

• Required rendered states and viewports.

• A deviation log template.

• A Figma reconciliation choice: not required, Figma-first, or code-to-canvas.

Capstone scoring

Interpretation:

• 90-100: Production-ready candidate for implementation review.

• 80-89: Ready for implementation with bounded follow-up.

• 70-79: Useful prototype; handoff gaps remain.

• Below 70: Exploration only.

Mandatory gates apply regardless of score:

• No unresolved High finding.

• All critical acceptance tests have a design and implementation disposition.

• Production components and tokens are traceable.

• Design and engineering have reviewed the rendered implementation before release.

Capstone synthesis of Chapters 1-10.

Phase 1 answer

A strong source stack ranks current production behavior and component code above visual inference. The duplicated Figma file and React package are paired, while shipped screens supply composition evidence. The preservation brief names the shell, route, permissions, Save, Run, persistence, and unrelated copy. The context package is focused and excludes private data, dependencies, build output, and unrelated packages.

The system test samples component identity and token use. It does not pass because the screen "looks like SDS." The record shows exact reuse, valid composition, proposals, and unverified areas.

Phase 2 answer

The DAG replaces only the current linear editor. PipelineNode, PipelinePort, and PipelineEdge are product-specific extensions rather than disguised card or button variants. Canvas controls reuse existing buttons, icons, and tooltips. The graph rejects a cycle and incompatible ports without mutation and explains the reason. Node status uses icon, text, and semantic color. Undo and redo cover both layout and structure.

Phase 3 answer

The selected node, inspector title, and data sheet provenance agree. Import creates source ID august after confirmation. Normalize Email produces six rows; C001 and C006 become alice@example.com and frank@example.com. Validation retains C001, C002, and C006, while C003, C004, and C005 are invalid at CSV rows 4, 5, and 6. The warehouse repair changes missing-warehouse to customer_health, then saves before re-running. The importer does not commit inferred mappings silently. The required mapping blocks completion, malformed rows point to row and column, and the user can reject them or route them to quarantine. Success creates the same source node shown on the graph.

Phase 4 answer

The state matrix covers document, canvas, node, inspector, data sheet, importer, run, and permissions. Transition contracts say what remains stable after failure. Version conflict preserves local work and supports review; stale preview remains inspectable and clearly marked. The minimum viewport uses an explicit docking or overlay rule rather than shrinking everything. Keyboard focus can complete the critical journey, and implementation-only evidence remains a test plan rather than an unsupported claim.

Phase 5 answer

Every visible element has a disposition. The record distinguishes the code Table primitive from the unverified Figma Table component. The challenge reviewer attempts invalid connections, minimum-viewport collisions, keyboard navigation, reload persistence, and data inconsistency. The handoff contains real imports, fixtures, exact copy, states, transitions, acceptance tests, prototype-only warnings, and named unresolved items.

Phase 6 answer

The Claude Code prompt requires inspection before editing, updates the current route, follows repository conventions, and asks for rendered proof. The implementation plan proceeds in bounded slices. Test the reviewed Claude Design export in Claude Code, then run the repository and browser checks on the resulting implementation. If editable Figma remains a source of truth, reconcile the changed screens, component instances, and variable bindings in the working file.

Common deductions

A1. Baseline analysis

A2. Draft design system

A3. Bounded screen extension

A4. Full state coverage

A5. Conformance audit

A6. Claude Code implementation

A7. Native Figma update

Feature

[Feature name and route]

Workflow and export evidence

[Design surface, organization, plan, Claude Code version/provider, selected system, source revision, sync result]

[Export format/date, actual file inventory, chat/README completeness, recipient access, missing inputs and owners]

[Reviewed baseline path/hash and open result; repository edit authority]

Inspect the bundle before implementation. Use the companion handoff template for the full evidence fields and the separate Figma write/capture eligibility checks.

Decision

[One paragraph: what is changing, for whom, and why]

Scope

Change: [Approved surfaces and behavior]

Preserve: [Shell, routes, actions, data, permissions, and unaffected behavior]

Non-goals: [Explicit exclusions]

Source-of-truth stack

1. [Production behavior and route]

2. [Component package and revision]

3. [Working Figma file and design-library revision]

4. [Representative shipped screens]

5. [Product brief and approval date]

Approved journey

[Numbered end-to-end user journey]

Design references

• Baseline: [link or path]

• Approved design: [link]

• Responsive references: [links]

• Prototype: [link]

• Claude Design bundle: [URL]

Component-to-code map

[Link to map with real imports, props, variants, and proposal owners]

Product-specific extensions

[Component, state model, accessibility contract, owner, intended code path]

Data and fixtures

[Fixture paths, schemas, expected transformations, error cases]

States and transitions

[State matrix and transition-contract links]

Copy

[Approved labels, helper text, errors, confirmations, empty states]

Accessibility and responsiveness

[Keyboard model, focus rules, announcements, viewports, mobile boundary, implementation-only tests]

Acceptance tests

[Critical numbered tests]

Prototype-code warning

Prototype code demonstrates design intent. Use only the mappings explicitly identified in the component-to-code table. Do not copy scratch components, simulated data, local styles, or generated state management into production without review.

Open decisions and deviations

[Item, severity, owner, due date, implementation consequence]

Verification record

[Commands, rendered routes and states, screenshots, reviewers, unverified items]

Setup and observation

• ☐

  Surface, organization, plan, provider, installed version, and selected system are recorded.

• ☐

  Design, Design systems, and standalone controls are checked separately.

• ☐

  Sync upload destination and completed source revision are confirmed.

• ☐

  Read, native-write, capture, and Code Connect eligibility are checked separately when Figma is used.

• ☐

  A reviewed baseline export opens and is preserved.

• ☐

  Documentation claims and observed runtime results are recorded separately.

Source and scope

• ☐

  Current route and production behavior are named.

• ☐

  The source-of-truth hierarchy is approved.

• ☐

  The public Community file is untouched.

• ☐

  A working Figma duplicate is used when connected inspection or editing is required.

• ☐

  The preservation boundary is visible.

• ☐

  Non-goals are explicit.

• ☐

  One fixture carries through the complete journey.

Design system

• ☐

  The focused code package, tokens, stories, and mappings are linked.

• ☐

  Settings form, dense table, and confirmation-flow tests pass; a correction persists in a neighboring state.

• ☐

  Component and token identity were sampled.

• ☐

  Every visible pattern has a disposition.

• ☐

  Raw values and duplicate primitives are absent.

• ☐

  Proposed components have owners, states, behavior, accessibility notes, and code paths.

Behavior and data

• ☐

  The complete success journey is interactive.

• ☐

  Invalid graph actions do not mutate state.

• ☐

  Undo and redo cover layout and structure.

• ☐

  The importer blocks unresolved required mappings.

• ☐

  Malformed rows have row and column references.

• ☐

  Import success creates the configured source node.

• ☐

  Preview data belongs to the selected node and shared fixture.

• ☐

  Save, reload, failure, repair, and re-run are covered.

• ☐

  Conflict, stale, permission, empty, loading, and error states recover safely.

Accessibility and responsiveness

• ☐

  The 1440 × 900 and 1024 × 768 layouts are reviewed.

• ☐

  Mobile editing is supported or explicitly out of scope.

• ☐

  Critical actions have a non-pointer path.

• ☐

  Focus is visible and restored after dialogs and state changes.

• ☐

  Status uses icon, label, and color.

• ☐

  Fields, errors, tables, progress, and dialogs have semantic behavior specified.

• ☐

  Reduced-motion and assistive-technology tests are assigned to implementation.

Handoff

• ☐

  Baseline, final design, prototype, and change log are present.

• ☐

  Component-to-code map uses real import paths.

• ☐

  State matrix, transition contracts, copy, and fixtures are included.

• ☐

  Prototype-only code is labeled.

• ☐

  Acceptance tests are objective.

• ☐

  Unresolved items have severity, owner, and consequence.

• ☐

  Export inventory and recipient access are checked; missing files or decisions are supplied or assigned.

• ☐

  The Claude Code prompt requires inspection before editing.

Implementation proof

• ☐

  Static checks pass.

• ☐

  Behavior and data tests pass.

• ☐

  The actual route renders in required states and viewports.

• ☐

  Keyboard and assistive-technology checks are reported separately.

• ☐

  Design, engineering, and product review are recorded.

• ☐

  Deviations are approved or assigned.

• ☐

  Figma and Code Connect are reconciled if they remain sources of truth.

Component-bearing metadata pages

The metadata snapshot contains 396 components across 19 component-bearing pages: Accordion, Avatars, Buttons, Cards, Dialog, Examples, Forms, Icons, Inputs, Menu, Navigation, Notification, Pagination, Sections, Tabs, Tags, Text, Tooltip, and Utilities. Confirm the page list in your working file before using it as an inventory.

Useful component node IDs

Token collections

Use @color semantic roles in product design. Raw primitive palettes are inputs to the system, not interface decisions.

Product gaps for Data Pipeline Studio

SDS is a strong source for the shell, forms, controls, typography, themes, layout, and basic feedback. It does not provide the product-defining graph, port, edge, schema-mapping, importer, or operational run-state model. The example snapshot includes a React Table primitive but no Table component in its Figma metadata. Check both the code revision and working Figma file before choosing a data-grid implementation. Build confirmed gaps as explicit product extensions from SDS primitives and tokens.

Tool roles

Current Claude Design limitations

1. Claude Design remains beta. Large repositories, intermittent comments, incomplete source imports, and simultaneous editing have documented limits. Mobile can request and view designs; canvas editing and sharing changes require web or desktop. Version history is not yet available. See the Design help guide.

2. Usage draws from the existing Claude allowance, including Claude Code. Confirm the organization's billing arrangement; usage-based Enterprise differs from seat-based plans. See the Artifacts admin guide.

3. Design and Design systems have separate Enterprise template controls. Standalone Design uses its own setting. An enabled organization setting is required before a custom role can grant access.

4. Uploaded assets persist under the applicable retention policies, Design data residency is unsupported, and the new Artifacts experience is unavailable for the documented CMEK, ZDR, and HIPAA-ready configurations. Confirm tenant requirements before upload.

5. Standalone Design lacks audit logs. Integrated designs in conversations and Artifacts have artifact-level Compliance API recording. Verify the event coverage required by the team; artifact-level records do not establish complete edit or comment history.

6. Generated accessibility reviews and conformance checks assist the reviewer. They do not establish human approval, component identity, or production behavior.

Figma workflow limits

The write-to-canvas documentation lists unsupported image assets and custom fonts, a 20kb output-response limit, and manual component publication before Code Connect completes. Those limits apply to that tool. The code-to-canvas path has different seat rules, and editable captured layers still need component and variable inspection. Confirm read quotas, Code Connect eligibility, and file permissions separately.

Operational controls

• Pilot with a small design-system group before broad rollout.

• Use non-sensitive fixtures and sanitize screenshots.

• Define who can publish or revise the organization system.

• Sample generated projects for system compliance.

• Keep a feedback path for source and mapping errors.

• Record the repository and design revisions used for each handoff.

• Treat field reports and vendor testimonials as adoption signals, not controlled quality evidence.

Primary product sources

1. Anthropic. "Get started with Claude Design." Accessed October 2, 2026. https://support.claude.com/en/articles/14604416-get-started-with-claude-design

2. Anthropic. "Set up your design system in Claude Design." Accessed October 2, 2026. https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design

3. Anthropic. "Using Claude Design for prototypes and UX." Accessed October 2, 2026. https://academy.claude.com/tutorials/using-claude-design-for-prototypes-and-ux

4. Anthropic. "Claude Design admin guide for Team and Enterprise plans." Accessed October 2, 2026. https://support.claude.com/en/articles/14604406-claude-design-admin-guide-for-team-and-enterprise-plans

5. Anthropic. "Introducing Claude Design, an Anthropic Labs research preview." April 17, 2026. https://www.anthropic.com/news/claude-design-anthropic-labs

Figma and design-system sources

6. Figma. "Figma MCP Server: Introduction." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/

7. Figma. "Code Connect integration." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/code-connect-integration/

8. Figma. "Structure your Figma file for better code." Accessed August 5, 2026. https://developers.figma.com/docs/figma-mcp-server/structure-figma-file/

9. Figma. "Workflow lab: Code to canvas." May 2026. https://help.figma.com/hc/en-us/articles/40219873508247-Workflow-lab-Code-to-canvas

10. Figma. "Getting started with Code Connect CLI." Accessed October 2, 2026. https://developers.figma.com/docs/code-connect/quickstart-guide/

11. Figma. "Simple Design System" open-source repository. README accessed October 2, 2026; detailed inventory retains August 5 cutoff. https://github.com/figma/sds

12. Figma. Simple Design System Community file supplied for this guide. https://www.figma.com/design/AIulMBySUibjRtykdngCUp/Simple-Design-System--Community-?node-id=3-5

Current setup and operating references

18. Anthropic. "Commands." Accessed October 2, 2026. https://code.claude.com/docs/en/commands

19. Anthropic. "Share session output as artifacts." Accessed October 2, 2026. https://code.claude.com/docs/en/artifacts

20. Anthropic. "Artifacts admin guide for Team and Enterprise plans." Accessed October 2, 2026. https://support.claude.com/en/articles/16994751-artifacts-admin-guide-for-team-and-enterprise-plans

21. Figma. "Set up the remote server." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/remote-server-installation/

22. Figma. "Write to canvas." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/write-to-canvas/

23. Figma. "Code to canvas." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/code-to-canvas/

24. Figma. "Rate limits & access." Accessed October 2, 2026. https://developers.figma.com/docs/figma-mcp-server/rate-limits-access/

25. Figma. "Code Connect: Introduction." Accessed October 2, 2026. https://developers.figma.com/docs/code-connect/

Field evidence - directional, not governing

13. Paul Kuo. "Claude Design sync codebase" field test. https://paulkuo.tw/articles/claude-design-sync-codebase/

14. Sebastian Proost. Claude Design case study. https://blog.4dcu.be/ai/programming/2026/04/27/claude-design.html

15. byCrawford. Claude Design review. https://bycrawford.squarespace.com/blog/claude-design-review

16. Builder.io. Claude Design review. https://www.builder.io/blog/claude-design

17. Creative Bloq. Claude Code and Figma MCP review. https://www.creativebloq.com/ai/designing-using-claude-code-and-figma-mcp-how-good-are-they

Use the official documentation above for setup, capabilities, and permissions. Field reports provide historical examples; confirm their instructions against the current documentation before following them.