Claude CoWork for Designers

What is Claude CoWork?

Claude CoWork is the practice of configuring Claude as a persistent design collaborator embedded in your actual workflow — not a one-off tool you open when stuck. Claude Design launched in April 2026 and changed what teams expect AI to produce visually. That shift commodifies execution. What it cannot commodify is your judgment: the design system decisions, the brand-coherent critique, the dev handoff that actually sticks.

Claude-native prompts. The prompts in this guide use Claude's XML tag structure (<context>, <instructions>, <format>, <avoid>) for precise, consistent output. These tags reduce ambiguity and give Claude clear parsing boundaries. They work in other models too but are optimized for Claude.

This is about staying the decision-maker. When Claude Design generates a screen, your DESIGN.md is what it references for constraints. When a component spec hits engineering, your handoff prompt is what keeps tokens coherent and interaction states complete. The designers who stay relevant post-Claude-Design are the ones who control the system — not the ones who fight it.

This guide covers setup, five high-leverage workflows, and the anti-patterns that will waste your time.

Install the Designer Plugin

This guide works on three Claude surfaces. The plugin is the fastest path on two of them. Pick whichever you use:

If you're on Cowork (desktop or mobile app)

Claude Cowork is Anthropic's agentic workspace — Claude completes work autonomously and returns finished deliverables. The Designer plugin packages the workflows below as native skills and slash commands.

1. Open the Cowork plugin directory in your desktop app.
2. Filter by Cowork, search for "Designer", and click Install.
3. The plugin's slash commands and ambient skills are now available in any Cowork task.

If you don't see the plugin in the directory yet, install via custom marketplace: paste https://github.com/alexclowe/awesome-claude-cowork-plugins in your Cowork plugin settings.

If you're on Claude Code (CLI)

Install from your terminal:

claude plugin add alexclowe/awesome-claude-cowork-plugins/designer

The plugin's slash commands and skills load on next session.

If you're on Claude.ai (web chat only)

Plugins aren't directly installable on the web chat surface. You have two options:

1. Use the prompts in this guide directly in a Claude Project (covered in the next section). Same outputs, more typing.
2. Upload the plugin's skills as a zip via Settings → Features → Custom Skills (Pro/Max/Team/Enterprise plans). Higher friction; only worth it if you want the auto-activating skills, not the slash commands.

What the plugin gives you (any surface)

Slash command	What it does
/design-system	Capture brand colors, typography, spacing, and component patterns into a complete DESIGN.md ready for Claude Design
/design-critique	Evaluate a design against accessibility (WCAG 2.2), brand consistency, and layout principles
/design-iterate	Plan token-efficient batch iterations: which slots to lock, what to vary, target outputs
/design-export	Generate dev-handoff specs: component inventory, design tokens, interaction states, redlines

Auto-activating skills (no command needed — Claude applies them when relevant):

• Brand Voice Design — Maintain consistent visual + verbal tone across outputs and resist generic Claude Design defaults
• Accessibility Audit — WCAG 2.2 contrast, focus states, keyboard nav, screen reader semantics — flagged before handoff

The plugin works standalone for one-off tasks. Pair it with the surface-specific setup below for persistent context across every task — that combination is the full Claude CoWork setup.

Setting Up Claude for Design Work

Surface note: The Project setup below is for claude.ai web users. Cowork users have their own task-context mechanism (set context once when starting a Cowork task). Claude Code users get the plugin's ambient skills automatically — no Project setup needed. The workflows themselves are surface-agnostic — paste the prompts wherever you're working. The key to consistent output is Claude Projects. A Project holds your custom instructions permanently, so Claude knows your brand, component system, and accessibility standards without re-prompting.

Step 1: Create a Design Practice Project. In Claude, open Projects and create one called something like "Design System — [Client or Company]". One project per brand context is cleaner than one mega-project.

Step 2: Set your custom instructions. In Project settings, add:

You are my design system and critique assistant. Here is my context:

<practice-profile>
- Role: [UX Designer / Product Designer / Brand Designer]
- Tools: [Figma / Claude Design / Linear / Notion]
- Design system: [Custom / Material 3 / Radix / Primer / etc.]
- Token naming convention: [e.g., semantic: color.surface.primary]
- Accessibility standard: WCAG 2.2 AA mandatory; AAA where feasible
- Brand: [Company name, key adjectives — concise, exact, human, etc.]
</practice-profile>

<rules>
- All critique must cite WCAG 2.2 success criteria by SC number
- Component specs must include all interactive states: default, hover, focus, active, disabled, error
- Never produce copy or layouts that conflict with the brand voice above
- Flag any pattern not covered by ARIA APG before recommending it
</rules>

Step 3: Upload your DESIGN.md. Your DESIGN.md is the single source of brand and system truth Claude references for every task. If you do not have one yet, Workflow 1 below builds it. See the full DESIGN.md library for templates.

Step 4: Upload supporting references. Add your component inventory, token dictionary, and any existing dev handoff specs. Claude will cite these rather than inventing patterns.

Step 5: Pin a starter prompt. Begin every session with: "We're working in [Project name]. Confirm you have the DESIGN.md loaded and summarize the top-level brand constraints before we start." This takes ten seconds and prevents context drift on long conversations.

Five High-Leverage Workflows

1. Build a Team DESIGN.md

A DESIGN.md is a structured brief your team — and Claude Design — drops into any AI session to enforce brand and system constraints from the first output. Without it, every AI-generated screen starts from scratch.

<context>
Brand: [Company name]. Industry: [e.g., B2B SaaS, consumer fintech]. Current state: [Figma file exists / legacy style guide PDF / starting from scratch]. Adjectives the brand must feel: [e.g., precise, calm, trustworthy]. Adjectives it must never feel: [clinical, loud, chaotic].
</context>

<instructions>
Draft a DESIGN.md with these sections: Brand Overview, Typography (scale + usage rules), Color (semantic token names + roles, not hex values), Spacing (base unit + scale), Component principles (3-5 rules), Accessibility baseline (WCAG 2.2 AA, call out 1.4.3 and 1.4.11 minimums), Voice and tone (2-3 sentences max), Anti-patterns (what this brand explicitly avoids).
</instructions>

<format>
Markdown. Each section under an H2. Rules as bullet points. Token names in code format. No decorative prose — this is a reference doc.
</format>

<avoid>
Hex values in the color section (use semantic names). Generic adjectives like "clean" or "modern" without definition. More than 800 words total.
</avoid>

2. Accessibility Critique Against WCAG 2.2

Paste a screenshot description or Figma frame spec and get a structured audit against current WCAG 2.2 success criteria with SC numbers, not vague advice.

<context>
Component: [e.g., modal dialog with a close button, heading, body text, and two CTAs]. Description: [paste Figma layer structure or screenshot description]. Foreground/background color pairs: [e.g., #1A1A1A on #FFFFFF for body, #FFFFFF on #2563EB for primary CTA]. Font sizes: [e.g., body 14px/400, CTA label 14px/600].
</context>

<instructions>
Audit against WCAG 2.2 AA. For each issue: cite the SC number and name, describe the failure, give a specific fix. Check at minimum: 1.4.3 (contrast, normal text), 1.4.11 (non-text contrast for UI components), 2.4.7 (focus visible), 4.1.2 (name, role, value for interactive elements). Also check against ARIA APG dialog pattern for keyboard interaction requirements.
</instructions>

<format>
Table with columns: SC Number | Criterion | Pass/Fail | Issue | Recommended Fix. Summary paragraph at the end.
</format>

<avoid>
Generic statements like "consider accessibility." If a criterion passes, say it passes — do not leave it ambiguous.
</avoid>

3. Token-Efficient Iteration

When you have 80% of a component locked, you want Claude to vary only the specific dimension you are exploring — not regenerate the whole thing.

<context>
Locked: component structure, typography, spacing, and all states except the one listed below. Base spec: [paste current component spec]. Iteration target: [e.g., surface color treatment for the card at rest vs. elevated vs. selected states].
</context>

<instructions>
Propose three options for the iteration target only. For each option: token name(s) that change, rationale tied to the brand profile, and any WCAG 2.2 implications (cite SC if relevant). Do not re-describe the locked portions.
</instructions>

<format>
Three numbered options. For each: Option label, changed tokens (code format), rationale (2 sentences max), accessibility note if applicable.
</format>

<avoid>
Re-specifying locked portions. More than three options. Suggestions that require changes outside the iteration target.
</avoid>

4. Dev Handoff Spec

Generate a complete component spec that engineering can implement without a meeting — covering all states, tokens, interaction behavior, and ARIA requirements.

<context>
Component: [e.g., inline text input with label, helper text, and error state]. Design system base: [e.g., Material 3 / custom]. Brand constraints from DESIGN.md: [paste relevant section or reference the uploaded file]. Supported variants: [e.g., default, focus, error, disabled].
</context>

<instructions>
Produce a dev handoff spec covering: component anatomy (list every element), token map (element → semantic token name), interactive states with transition behavior, ARIA role and required attributes per ARIA APG, keyboard interaction model (tab, arrow keys, escape where applicable), and implementation notes for any pattern that deviates from Material 3 or the ARIA APG spec.
</instructions>

<format>
Markdown. Component anatomy as a nested list. Token map as a two-column table (Element | Token) — use token names that match Figma Variables/modes where applicable. States as H3 subheadings. ARIA and keyboard sections as bullet points.
</format>

<avoid>
Hex values or hardcoded pixel values — token names only. States that are not listed in the context. Assumptions about framework (React, Vue, etc.) unless specified.
</avoid>

5. Designer to Claude Code Handoff Loop

You set the design intent. Claude Code implements it. This workflow structures the handoff so intent is not lost in translation.

<context>
Feature: [e.g., onboarding stepper, 3 steps, linear flow]. Design intent: [paste your DESIGN.md excerpt + component spec from Workflow 4]. Constraints: [e.g., must use existing token system, no new dependencies, accessible at WCAG 2.2 AA]. What should not change: [e.g., step indicator visual treatment is locked].
</context>

<instructions>
Write a Claude Code prompt I can paste directly that: (1) describes the component intent clearly, (2) references the token and state spec, (3) specifies ARIA requirements (ARIA APG "tabs" or "steps" pattern), (4) includes a checklist of acceptance criteria Claude Code should verify before considering implementation complete.
</instructions>

<format>
A single ready-to-paste prompt block. Acceptance criteria as a checkbox list at the end of the prompt.
</format>

<avoid>
Implementation language (React, HTML) unless I have specified it. Acceptance criteria that are vague (e.g., "looks good") — all criteria must be verifiable.
</avoid>

What This Looks Like in Your Week

Monday. A PM drops a new brief in Notion. Before opening Figma, you run Workflow 1 to draft or update the DESIGN.md with the project's brand constraints. You paste it into your Claude Project so every session this week starts with it loaded.

Tuesday. You have three card component variants to explore. You run Workflow 3 to iterate on surface color treatment only, locking everything else. Claude returns three token-level options with rationales. You pick one, annotate the Figma frame, and move on in 20 minutes instead of 90.

Wednesday. Design review. You take the Figma frame description from the feedback session and run Workflow 2. The audit surfaces a 1.4.3 contrast failure on the secondary label and a missing 2.4.7 focus-visible treatment on the icon button. You fix both before the dev handoff instead of after.

Thursday. Handoff day. You run Workflow 4 on the finalized components — input, button, card — and paste the resulting specs into the Linear ticket. Engineering has the token map, state inventory, and ARIA spec without scheduling a sync.

Friday. A Claude Code PR comes in for review. You run Workflow 5 in reverse: paste the implementation back into Claude with your original acceptance criteria and ask for a gap analysis. Two missing keyboard interactions surface. You comment on the PR with SC citations and the ARIA APG link. Closes the loop.

What to Avoid

Prompting Claude Design without a DESIGN.md. Every session without it starts from generic aesthetic defaults. Your brand drifts one generation at a time. The DESIGN.md is the constraint layer that makes AI output yours.

Asking for "a component" without specifying states. Claude will produce the default state and nothing else. Engineering will ask about hover, focus, disabled, and error states anyway. Specify all states in the prompt or you will be back twice.

Treating Claude's accessibility audit as a compliance sign-off. It surfaces failures efficiently. It does not replace manual testing with a screen reader (NVDA/JAWS), automated tooling (axe-core), and keyboard-only navigation. Use it to catch issues before testing, not instead of testing.

Giving Claude your design intent and asking it to decide the system. Claude will make decisions you have not made, using defaults from Material 3 or its training data. You decide the system. Claude documents and implements it. The direction flows one way.

Letting Claude Code handoffs skip the acceptance criteria checklist. Without explicit, verifiable criteria, Claude Code will produce something that renders correctly and fails keyboard navigation. Workflow 5 exists to prevent this.

Resources

• DESIGN.md library — production-ready templates by project type
• Designers After AI hub — the survival guide for working designers in the Claude Design era
• Designer plugin for Claude — pre-built Claude tools for design workflows
• Designers profession hub — AI career resources for design professionals
• WCAG 2.2 Understanding Docs — SC-level guidance for every criterion
• ARIA Authoring Practices Guide — interaction patterns and keyboard behavior by component