Prototyping is one of the most important things I do as a designer, actually at every level even today as Chief of Design. It is where early thinking becomes something you can see, a look into the fu…

Read more

TLDR: I gave Claude Code a two-way bridge into my Figma file. It reads my canvas, fixes it, and builds on it directly, with more than thirty tools running on the live file. I built it because I already run everything through Claude, so the natural move was to bring Claude onto the canvas, not adopt a separate AI inside Figma.

Why Claude, and not Figma’s AI

I already pay for Claude. I am on the Enterprise plan, and I am in it all day, for everything.

The subscription is the small part. The real weight is everything I have built around it. The plugins I run, the MCP servers I have connected, the skills I have written, my CLAUDE.md files, the project memory, and the taste I have taught it over months. None of that transfers to a different AI. It is the thing that makes the agent actually useful, and it all lives in Claude.

Claude is also where my work starts. Every project, every build, the terminal is already open. It is my starting point, not something I switch into.

So when I want to work on a Figma file, I do not want to jump into a different AI inside Figma and start that relationship from zero. I want the agent that already knows my work to reach into the canvas. Same context, same memory, same taste, now with hands in Figma. Using Claude on Figma is not a workaround. For how I work, it is the natural move.

That is the whole reason DesignAgent runs two ways now. For months it only ran one. I would select a screen, it turned the design into a spec and a code-gen prompt, I pasted that into Claude Code, and the UI came out somewhere else, in the editor, away from the file my team lived in. I cut a design-to-engineering handoff from about two weeks to four hours once with Figma Code Connect, and the lesson stuck: every time you remove a copy-paste between two tools, the work gets faster and the result stays truer. DesignAgent still had one of those seams in the middle. So I closed it.

DesignAgent now has a two-way bridge. Claude Code can read the canvas, fix things on the canvas, and create on the canvas directly. The handoff runs both directions.

What “two-way” actually means

Claude Code is connected to the open Figma file. It can read the selection, then act on it. Move a layer. Fix the padding. Swap a raw hex for a token. Create a frame, text, a shape, an image. Restyle, regroup, re-layout. There are more than thirty tools on Claude’s side, and they all run against the live file. The canvas is now something Claude works on, not just something it reads from.

The connection is a small thing technically and a big thing in practice. The plugin opens a local socket, Claude Code connects to it, and the tools show up on Claude’s side immediately. You flip one switch in the plugin, the dot turns green, and now you can say “read my current selection and build the empty state next to it” and it does, against the live file.

And the connection holds, which matters more than it sounds. The bridge runs on a heartbeat. It pings on a steady beat and the plugin shows you when it last heard back, so a green dot means actually live, not a socket that quietly died ten minutes ago. If the link drops, it reconnects on its own, and a watchdog notices a silent connection and re-handshakes it. The first version of this thing would connect and then die halfway through a build, which is the worst possible moment. This one stays up while you work. For an agent editing your real file, that reliability is the whole game.

The plugin panel itself does two things, and that is the point: connect the bridge, and pick the project. If you have a few Claude Code sessions open, a small picker lets you choose which one DesignAgent reads and writes, so the agent and the file you mean are always the same thing. Everything else happens in the terminal.

It is all local. No API token to mint, no paid seat, no cloud roundtrip. The plugin runs with network access switched off, so the whole exchange stays on your machine. Nothing about your file leaves the room.

1. Install the bridge

DesignAgent is two halves that talk to each other: the Figma plugin and a Claude Code plugin that ships the bridge.

The Figma plugin is on the Community: search DesignAgent, or open it here.

The Claude Code side installs from the marketplace:

/plugin marketplace add sherizan/designagent-figma
/plugin install designagent@designagent

Restart Claude Code after the install. That gives you the design-to-code skill and the designagent MCP server in one shot. Node has to be installed, the server runs on it. Nothing else to configure.

2. Turn the bridge on

1. Open the DesignAgent plugin in Figma.

2. On the “Claude bridge” bar, click Start. The dot turns green and the status reads “Connected” when Claude links up. The bar also shows a heartbeat (”heartbeat 2s ago”) so you can tell the link is actually live and not stalled.

3. In Claude Code, the bridge tools are live immediately. Test it with one line:

Use DesignAgent to read my current Figma selection and tell me what is on it.

If it comes back with the layers and structure of the screen you have selected, you are connected.

3. The prompt pack I run

These are the kinds of instructions I actually run. They are in assets/prompt-pack.md as well, ready to paste.

Extract the tokens to DESIGN.md

Extract the tokens from my current selection (colors, type, spacing, radius) and write
them to DESIGN.md. Use my real values, do not round or invent any.

Create a design system from a logo

Look at the logo I have selected. Create a foundation for my design system and create/update DESIGN.md

Build the first set of UI components

Using the tokens in DESIGN.md, build a first set of components on a new frame: buttons
(primary, secondary, ghost), slider, toggle and a form (input with label and an error state). On-system only.

Design a landing page with the UI components

Using the tokens in DESIGN.md, design a marketing landing page

Write the screen copy in your voice

If you have your tone of voice in a markdown, you can use DesignAgent to write copy for the screens.

Read voice.md. Write the copy for the screen I have selected using that tone of voice,
and set it on the matching text nodes. Show me each change before you apply it.

Create a social asset from your branding

Create a social media asset templates for LinkedIn/Substack in Figma. Use the branding in DESIGN.md (my colors, type, and logo). Keep every value on-system.

The discipline that makes these work: scope it tight. One frame or one flow at a time, not the whole file. The agent is precise when the target is small and drifts when you point it at everything at once. And let it check its own work: build, screenshot, compare to DESIGN.md, fix.

Bonus: Mobbin MCP: Use DesignAgent to paste the screens into the frame.

Use Mobbin MCP to extract Revolut onboarding flows and paste them to Figma

My Takeaway

This is the part I did not expect to feel so different. Claude is not looking at my design anymore. It is designing on it.

• Claude designs on your real canvas. The same model you already work with, now with hands in Figma. It builds, edits, and arranges on the live file, not a copy of it.

• It brings everything you have taught it. Your plugins, your MCP servers, your skills, your CLAUDE.md, and your taste all come with it. You are not starting a new tool from zero.

• It goes from nothing to a system. A logo becomes tokens. Tokens become buttons and forms. A screen gets copy in your voice. Your branding becomes a finished social asset. All on-system, all in one session.

• It checks its own work. It screenshots what it built, compares it to your DESIGN.md, and fixes what came out off. Build, look, correct.

• It is yours and it is private. Free, local, no token, no extra seat. Nothing leaves your machine.

You still hold the taste. You decide what good looks like, what to keep, what to cut. The bridge just means the agent that already knows your work can finally reach the canvas and do the hands-on part with you. Design and code, one loop, one source of truth, one agent you already trust. That is the shift, and it is a big one.

Open Mobbin. Search the flow. Scroll. Screenshot. Drop into Figma. Reorder. Annotate. Repeat for the next competitor.

Hours. Every time. Last week that stopped.

What I tried

Mobbin shipped an official MCP in beta. Included with all paid plans during beta. Feature access and availability may change in future updates.

I hooked it up alongside the Console MCP and pointed Claude Code at both.

Then I prompted:

That’s it. One line.

What actually happened

Claude went to Mobbin. Pulled the screens. Started laying them out in Figma.

Then I noticed something off.

The first screen was Google Pay India. The second was Google Pay US. The third was Google Pay India again. The “onboarding flow” Claude assembled was a Frankenstein three regions stitched together.

Before I could even type a correction, Claude flagged it itself.

“The screens I pulled span multiple regions (US, India). This breaks the flow continuity. Re-pulling — defaulting to US only.”

It re-queried Mobbin. Filtered to one region. Re-laid the screens in Figma in the correct order.

I didn’t touch a thing.

Why this matters

The unlock isn’t that AI can fetch screens. Anyone can fetch screens.

The unlock is that the stitching is gone.

In the old loop, I was the integration layer between Mobbin and Figma. Every screen passed through my hands. Every annotation, every reorder, every “wait, this is the wrong country” check, that was me.

Now the stack does it:

1. Mobbin MCP: the competitor screen library, queryable by intent.

2. Figma Console MCP: Claude can open, place, and arrange frames in your Figma file.

3. Claude CLI: the brain that connects the two and self-corrects when the data is messy.

Three pieces. One prompt. A workflow that used to take an afternoon now takes the length of a coffee.

Where this gets really good

The one-prompt version is the entry point. The real leverage is wrapping it as a Claude skill so you don’t have to remember the prompt every time.

I built one and called it /mobbin. You type the slash command, name the competitor and flow, and the skill handles everything, fetches from Mobbin, self-corrects region mismatches, places frames in Figma in flow order, then runs a structured analysis pass against the screens.

The analysis pass is the part most people miss. Fetching is table stakes now. Auto-analysing, checking entry points, friction moments, KYC placement, empty states, error handling — is where the time actually compounds.

Chef’s kiss when it runs clean.

Want the /mobbin Claude skill?

Below are the exact prompts I use for region filtering and flow assembly, the structured analysis pass Claude runs against the screens, and the Figma layout config so the frames land in the right order every time.

This playbook is constantly being updated as Mobbin’s MCP evolve out of beta.

Read more

Last week, two things shipped four days apart.

Anthropic launched Claude Design on April 17. Google open-sourced DESIGN.md on April 21.

Both touched design systems. Both promised to make AI agents resp…

Read more

I remember the exact meeting where everything changed.

It was 2018 at Grab. We were a design team of over a hundred people, all using Sketch, all dropping files into Google Drive, all pretending that …

Read more

Read more

As AI becomes faster and more capable at producing UI, some tension is starting to show up:

Our design systems were never built to operate at AI speed.

They were built to be read.
They assume humans will interpret rules, remember conventions, and catch mistakes in review.

AI doesn’t work that way.

This article proposes a shift from Design Systems to what I call a Design Model:
an executable form of design governance that AI tools, agents, and engineers can safely operate inside.

This is still experimental.
But it’s already working.

The problem isn’t generation anymore

AI can generate UI easily now.

Screens. Components. Layouts. Variants.
That part is no longer impressive.

The real problem is something else:

Who decides what is allowed to exist?
Which components are valid?
Which styles are acceptable?
Which combinations should never ship?

When AI can generate anything, what we often get isn’t better UX, it’s AI slop: inconsistent, off-brand, technically valid but unshippable UI.

Design systems were supposed to prevent this.
But they rely on documentation, memory, and human enforcement.

At AI speed, that breaks down.

Going one level up: the Design Model

Instead of asking how AI should generate UI, I started asking a different question:

What should AI be allowed to operate inside of?

That led me to the idea of a Design Model.

A Design Model is an evolution of a design system but expressed as something executable, not just readable.

It has three parts:

• Tokens
  Define what styles are allowed
  (colors, spacing, typography, radius, etc.)

• Contracts
  Define what components exist and what props are valid
  (variants, sizes, defaults)

• Constraints
  Define what decisions are not allowed
  (for example: only one primary action per view)

Together, these don’t describe UI. They govern it.

A brief analogy (LLMs, but lightly)

If the analogy helps:

A Large Language Model is not a collection of sentences.
It’s a system that encodes patterns and rules well enough to produce the next meaningful output.

In a similar way, a Design Model is not a collection of components.
It encodes design decisions: tokens, contracts, constraints so valid UI can be resolved, not guessed.

The goal is not to copy how LLMs work.
It’s to apply the same shift: from static artifacts to an executable model.

Generated vs Resolved

In a Design Model, UI isn’t generated but instead it resolved.

An intent comes in from a developer, an AI agent, or a coding assistant.
That intent is evaluated against the model.

• If it fits → it resolves cleanly

• If it doesn’t → the system explains why and suggests adjustments

No static documentation.
No “please follow the design system 🙏”.
No late-stage reviews trying to catch violations. (My QA team can finally breathe)

Rules are enforced at runtime with guidance, not policing.

A deliberately small demo

To keep this honest, I built a small demo using just one component: a Button.

That’s intentional.

Buttons are:

• universally understood

• easy to misuse

• visually obvious when wrong

• a common source of inconsistency

If a system can’t govern a button, it won’t govern anything more complex.

In the demo:

• You can render one or two primary buttons: it works

• You can then add a constraint (“only one primary button per view”)

• Run the same intent again

• The outcome changes without changing the prompt or the renderer

The only thing that changed was the model.

📹 Watch my Demo video above.

Why this matters for AI-assisted coding

AI tools today can read design documentation (via MCP or similar approaches).
But documentation has no authority.

A Design Model does.

It sits between AI and code and answers one question consistently:

“Is this allowed to exist?”

AI can propose.
The model decides.

That shifts AI-assisted coding from:

“Generate UI and hope it’s right”

to:

“Resolve UI against rules and ship with confidence.”

This is still experimental

This is not:

• a new product announcement

• a framework

• replacing designers or Figma

• a completed standard

It’s a working exploration of an idea that feels increasingly necessary as AI accelerates how UI is built.

The repo is public. You can fork it, add a component, add a constraint, and try to break it.

Repo link: https://github.com/sherizan/design-model

An open invitation

If you’re researching AI and design systems,
or actively trying to adapt design systems for AI workflows,

I’d genuinely love to join forces and work toward a shared standard.

Design systems helped us scale consistency.
Design Models may be how we scale decision-making.

This is early.
But it feels like the right direction.

Figma Make is great at generating components but terrible at reusing them across projects.

So I flipped the workflow.

Build everything once in Make, push to GitHub, then pull it into every new project with a single prompt.

It works beautifully.

The Actual Workflow (The One You Came Here For)

Step 1: Open new Make file

Prompt:

Create a UI Component Library with reusable components for Make prototypes.

Start with a base layout and we can add 1 component after.

• Design your components.

• Test them.

• Swipe them.

• Break them.

• Fix them.

Reach that moment when they finally feel “keeper” quality.

Step 2: Push them to GitHub

Here’s an example of a ToDo card component that I’d like to reuse.

Yeah. Literally export the component code, drop it into a GitHub repo, and commit. Let’s ensure its fully portable using your own design system CSS variables.

Prompt:

Before pushing to Github, ensure it is reusable and cleaned up for other projects to use

Your folder structure can look like this:

/components
  /cards
    ToDoCard.tsx <-- this is what we will commit to Github

Now you have a real design system.
Version controlled.
Portable.
Future proof.

Step 3: Pull components from GitHub in any new Make file

Go ahead and create a new Make file or go to your existing project.

This is the magic line:

Read more

Most designers today are overwhelmed by AI and honestly, I don’t blame you.

The tools are exploding. Every week, there’s another launch that promises to replace your entire workflow. Meanwhile, you’re…

Read more

1. Why This Matters

AI prototyping tools give you power to build interactive flows, but not to test them properly. And good user testing tools are either expensive, slow, or overkill.

This tutorial fix…

Read more

While playing with Make, I discovered that you can access the device camera in your published Make app which means you can build fully functional scanning flows without writing code.

Read more

A couple of months back, my team shipped the designs for a new product.

The usual ritual: end-to-end flows, 100% components, zero drifts, zero detached instances.

Everything was clean, consistent, and ready for a perfect handover to engineering.

We marked the section as “Ready for Dev.”
High fives all around. Designers happy. Product happy.

A few days later, our frontend dev came back and said:

“Your designs are not AI-ready”.

🤯 Wait, what?

Turns out our engineers were already deep into AI-assisted development.
Claude Sonnet vs GPT-4 debates. Cursor vs Windsurf arguments. Then Claude Code appeared like a plot twist.

Meanwhile, Figma’s stack… was not built for this world.

Ghost variants. Unnamed layers. Token inconsistencies.
All the things humans ignore but AI absolutely hates.

The result?
AI hallucinated. It misread intent. It wrote janky UI code. Eventually… engineers gave up on the design and started fixing things manually again.

For months, nothing solved it until I remembered something buried inside our Figma Enterprise plan:

Code Connect.

Code Connect is a bridge between your codebase and Figma’s Dev Mode, connecting components in your repositories directly to components in your design files. When implemented, these connections enhance the Figma MCP server‘s ability to guide AI agents with more precise implementation details by giving them direct references to your actual code.

Then came the breakthrough

We finally decided to combine Figma Code Connect + Figma MCP together . We had to fork our existing design system, prioritized the foundation pieces like buttons, form, cards basically the components that appear in almost every flow.

The AI suddenly “understood” our design intent, things started clicking.

The components Cursor produced came straight from the connected codebase (no more regenerating new components every time).

The final product:

Why this stack just works

Reduced design inspection time AI can trace directly to source code

Cleaner handoffs less context lost between design ↔ dev

Fewer UI bugs every component has a single source of truth

Agent-ready components works seamlessly with Cursor, Claude Code, and beyond

How to implement this at your company?

Spoiler: this isn’t a technical project.
It’s an alignment project.

So we got everyone in a room and asked the hard question:

“If AI is already writing code at the speed of thought… where does design fit?”

That’s when we acknowledged three things:

• AI saves devs time but also exposes every inconsistency.

• Engineers were tired of copy-pasting Figma via “Dev Mode”.

• Business cared about one thing: faster execution without compromising UI quality.

So the mission became:

Make our design system AI-native

The Reality Check: It Wasn’t Overnight

This wasn’t a “flip Code Connect and everything magically works” story.
It took weeks of unlearning and rebuilding.

The timeline roughly looked like this:

Read more

Read more