Article•12 min read

My AI-assisted product design workflow

How I use Claude, Claude Code, Figma, and other AI tools to widen exploration, make decisions tangible, and improve delivery without handing product judgment to the model.

Core idea

AI is most useful when it shortens the distance between a question and evidence. Not when it removes the question entirely.

The version of this that does not work is starting with a tool and seeing what it produces. The version that does is starting with a product decision you are trying to make, then choosing the tool that generates the most useful evidence toward that decision.

The productivity gain is real but specific. AI helps reduce the slow work surrounding a decision: organizing inputs, checking states, building first-pass documentation, generating prototypes, and verifying implementation details.

What it returns is time for the work that still requires judgment: deciding what problem matters, choosing the tradeoff, aligning the team, and protecting quality through delivery.

01

Start with the decision, not the prompt

Before I open any tool, I write down the product decision I am trying to make. Not the task. The decision.

Task: redesign the empty state for the activity feed. Decision: which combination of message, illustration, and CTA helps users with no activity understand what to do next, without implying the product is broken.

Give AI a task and it will optimize for completion. Give it a decision and it can generate options, surface tradeoffs, and flag gaps. Writing the decision first prevents an uncertain product problem from becoming a polished but unsupported answer.

  • The decision: what I need to choose between.
  • The constraint: what cannot change.
  • The evidence threshold: what would make me confident enough to move forward.
  • The risk: what goes wrong if I choose incorrectly.

02

Use the right tool for the stage

Different tools have different strengths at different stages. The mistake is treating AI as a single category rather than a collection of capabilities that fit different moments in the workflow.

Claude

Best for challenging framing, structuring messy thinking, critiquing flows, writing decision documents, comparing approaches, and early synthesis.

I use Claude while work is still language-shaped: to think out loud, pressure-test an approach, and create a structured document before anything visual exists.

Claude Code

Best for touching a codebase, generating interactive prototypes, inspecting implementation, and verifying through builds and screenshots.

The workflow that works is: inspect first, plan second, implement third, verify with a screenshot. A rendered browser state can then move into Figma as editable layers for continued refinement.

Figma

Best for interaction design, visual systems, and component decisions. I increasingly bring in a working interface and use Figma to evaluate, refine, compare, and systematize it.

AI research tools

Perplexity, ChatGPT, and Gemini help with pattern synthesis, competitive comparisons, and first-pass documentation. Their output is raw material that I filter against the product context, never the final answer.

03

Set up a design-aware environment

The most impactful setup investment I have made is not learning better prompting. It is building a design-aware project environment so every AI session starts with context rather than requiring me to rebuild it.

The CLAUDE.md file

CLAUDE.md is the onboarding document for AI in a project. It carries project memory and execution guidelines into every session. A clear file means less time correcting and more time evaluating.

  • • Design-system rules, token names, component patterns, and naming conventions.
  • • Architecture constraints, UX principles, and interaction standards.
  • • Anti-patterns, deprecated components, and accessibility requirements.
  • • Verification expectations, breakpoints, and states to check.

Project folder structure

I organize projects so the agent has a reliable source of truth before it generates anything.

/project
  /app
    /components
  /docs
    prd.md
    user-flows.md
    ux-principles.md
    design-system.md
  /design
    tokens.md
    components.md
    interaction-patterns.md
  CLAUDE.md

Building an AI-ready design system

Token naming, component documentation, and design-to-code parity determine how reliably AI can work within a system.

  • • Tokens with intent, not appearance. color.action.primary provides context; color.blue.500 does not.
  • • Structured documentation explains purpose, alternatives, states, and accessibility.
  • • Design-to-code parity reduces guessing between Figma and production components.
  • • Spec files encode how design decisions are made, not only what components look like.

04

Skills that make Claude and Codex useful

The useful skill is not writing a clever prompt. It is giving the agent enough product context to make a reasonable decision, then reviewing what it proposes before it changes anything.

  • Read the existing product first: inspect components, patterns, and handled states.
  • Describe user intent, not interface elements: explain the outcome and confidence the interaction should create.
  • Translate design intent into constraints: define breakpoints, zero states, existing patterns, and system rules.
  • Plan before implementing: review what will change, what might break, and how the result will be verified.
  • Verify with evidence: check screenshots, breakpoints, zero states, and edge cases.

05

Claude Skills for product designers

Claude Skills are reusable instruction files for recurring tasks. Instead of rewriting a long prompt each time, I define a workflow once and apply it consistently.

Skills can encode design knowledge, such as principles, components, tokens, and brand rules. They can also encode capabilities, such as research synthesis, design-system audits, handoff annotation, and UX review.

A practical skill library

The most useful skills turn repeated design work into a consistent review process while leaving the final judgment with the designer.

  • • User research synthesis: extracts themes, recurring pain points, and structured findings.
  • • Design-system audit: checks tokens, state coverage, accessibility, and documented patterns.
  • • Component documentation: generates purpose, usage, alternatives, states, accessibility, and examples.
  • • Dev handoff annotation: describes responsive behavior, edge cases, states, and content constraints.
  • • UX review: evaluates hierarchy, cognitive load, error handling, zero states, and accessibility.

Building a first skill

A Skill needs a clear purpose, review criteria, and output format.

---
name: design-audit
description: Audits a UI component or screen.
---

## Purpose
Review the design against the criteria below.

## Criteria
1. Token compliance
2. State coverage
3. Accessibility

## Output format
Return findings with severity and remediation.

06

Turn the idea into evidence

A recommendation becomes useful when people can inspect it. Depending on the question, I turn direction into a flow, prototype, coded interaction, decision document, or comparison artifact.

My frontend background helps me move from an abstract interaction idea to something product and engineering can react to faster than a strictly visual process would allow.

  • Frame the decision and constraints in Claude.
  • Inspect the existing implementation in Claude Code.
  • Build the prototype or coded interaction.
  • Render and verify it in the browser.
  • Send it to Figma for refinement and comparison.
  • Compare against intent and original constraints.
  • Correct where the output diverges.

07

Where the productivity gain comes from

The productivity gain from AI in product design is real, but it is not evenly distributed. It concentrates in work that is slow and mechanical rather than work that is difficult and consequential.

The gain compounds because every documented project rule, reusable Skill, and encoded design-system decision makes the next session faster.

AI makes fast

  • • Organizing and synthesizing research inputs.
  • • Generating first-pass documentation and structured handoff notes.
  • • Building early-stage prototypes and comparison artifacts.
  • • Checking state coverage, edge cases, and implementation details.

AI does not replace

  • • Deciding what problem actually matters.
  • • Choosing which tradeoff the product should make.
  • • Aligning the team around a direction.
  • • Protecting quality through delivery.
  • • Knowing when a technically correct solution is humanly wrong.

08

Keep judgment human-led

AI does not know which compromise the product should make. It does not own the customer relationship, business context, long-term vision, or qualitative signals that come from spending time with users.

The rule I follow is simple: AI handles the work, I own the decision. Every output goes through my judgment before it becomes a recommendation.

  • Context that is not in the files: recent leadership, support, and customer signals.
  • Calibrated taste: knowing when an interaction is complete but the experience is not.
  • Relationship with tradeoffs: choosing which consequence the product can live with.
  • Quality ownership: deciding when work is genuinely good enough to ship.