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 respect your brand. Most coverage I read treated them as competitors.

They’re not.

• “Does this replace DESIGN.md?”

• “Why would I write DESIGN.md if Claude Design extracts my system automatically?”

These are good questions. I had the same ones when the launch landed.

The short answer: DESIGN.md is foundational. Claude Design is a tool that becomes more useful when you have a DESIGN.md to point it at. They’re not the same layer of your stack.

Here’s why.

What Claude Design actually does

Claude Design launched April 17. Research preview. Available on Pro, Max, Team, and Enterprise plans.

You describe what you need. It generates a prototype, a slide deck, a landing page, a one-pager. Live HTML. Clickable. Refineable through chat.

The part that made designers pay attention isn’t the generation.

It’s the onboarding.

During setup, Claude Design reads your codebase and your design files and extracts a design system automatically. Colors, typography, components, spacing. It builds a token library from whatever you give it. A Figma file. A GitHub repo. A brand PDF. Even a live website URL.

From that point, every new project inherits the system.

That’s a real shortcut. Genuinely useful, especially if your team has been pasting hex values into prompts for the last year.

What DESIGN.md actually does

DESIGN.md is a different thing entirely.

It’s not a design system itself. It’s not a token format like Style Dictionary or W3C Design Tokens. It’s not a style guide your team reads.

It’s a plain-text file in your repo. YAML at the top for tokens the agent can parse. Markdown below for the rules a human wrote. Every AI agent reads it before generating anything.

It’s a contract.

Version-controlled. Editable by your team. Cursor reads it. Claude Code reads it. Figma Make reads it. Any agent you adopt next year reads it.

Google Labs shipped the spec. We’ve been building an extended version using Nova, botim’s production system, as the worked example.

Why the question keeps coming up

Both are working on the same upstream problem.

Agents drift.

You prompt them today, they get close to your brand. You prompt them again tomorrow, they drift a little. By session four the corner radius is different. The button weight is off. The neutral is too cool.

Quietly, consistently off.

That drift is the context tax we’ve all been paying. Every prompt. Every session. Every project. Paying it again.

The fix is a system the agent reads every time before it generates. Both DESIGN.md and Claude Design are working on that. They just approach it from different angles.

Three things that are actually different

1. Where it lives, who reads it

Claude Design is a single product. The system you upload lives inside it. If you stop paying, change vendors, or Anthropic deprecates the feature, your work goes with it.

That said, it is still early. Anthropic ships fast, and Claude Design has only been out for a week. My prediction: this gets more interesting. I’d expect them to expose Claude Design through MCP soon, which would open up a real range of use cases. Reading your DESIGN.md from the repo. Generating output that respects it. Sitting alongside the rest of your stack instead of inside its own box. If that lands, the picture changes for the better.

For now, though, the system you build inside Claude Design is scoped to Claude Design.

DESIGN.md lives in your repo. It travels with your code. Cursor reads it. Claude Code reads it. Figma Make reads it. The next agent you adopt next year reads it. It is to design what tsconfig.json is to engineering. A small open file in your repo that every tool in your workflow already knows how to consume.

One is product-level memory. The other is a portable contract.

This is the foundational layer. You write it once and every tool, current and future, benefits from it.

2. The principles layer

This is where the split is clearest.

Claude Design extracts what your system is. Colors. Typography. Components. The structural facts.

DESIGN.md carries why it is the way it is.

“Primary is rationed. Used once per screen for the most important action.” “Motion is reassurance, not entertainment. Never animate error states.” “When in doubt, remove an option. Decision paralysis is the silent UX killer.”

These aren’t tokens. They’re the principles and constraints behind the tokens.

An agent that knows your hex codes will still sometimes put two primary buttons on the same screen. An agent that also knows your principles is more likely to catch itself.

The principles are the part you write yourself, and they’re the part that makes a system feel yours.

3. Extraction is fast. Writing is deliberate.

Claude Design infers your system from what it reads. For clean codebases and well-structured Figma files, the inference is good. For messier source code, nested tokens, brand-specific shadows, multi-brand setups, the model is making educated guesses.

Anthropic’s own documentation is honest about this.

“The design system import works best with a clean codebase. Messy source code produces messy output.”

DESIGN.md is written by a human who knows the system. You write the corner radius value, and the sentence that explains when to break it.

Different inputs. Different outputs. Both useful at different stages.

“But Claude Design has a Claude Code handoff. Doesn’t that solve it?”

Claude Design has an export called “Send to Claude Code.” It packages up the design tokens, the component structure, the layout hierarchy, the assets, and a PROMPT.md for Claude Code to read. Claude Code receives the bundle, loads it into context, and builds the feature. It’s a real workflow. It works today.

But it isn’t the same thing as a portable contract.

Two reasons.

One. The handoff is a snapshot, not a live link.

When you export from Claude Design to Claude Code, you’re shipping the system as it exists right now. If the design system updates inside Claude Design tomorrow, the bundle you handed off yesterday doesn’t update with it. You re-export. You re-hand-off. Per project. Every time.

A DESIGN.md in your repo is a single source of truth. Update the file once. Every agent reading it from the repo gets the new version on its next prompt. No re-export. No re-handoff.

Two. The handoff goes to Claude Code. That’s it.

Cursor doesn’t receive the bundle. Figma Make doesn’t receive the bundle. The next agent your team adopts in a year doesn’t receive the bundle. The handoff is built specifically for the Claude Design → Claude Code loop, which is exactly the loop Anthropic is investing in. That’s a fine bet for them. Less fine if your team uses more than just Anthropic products.

DESIGN.md sits in your repo. Every agent already knows how to read a markdown file in a project root. No bundle. No vendor-specific format.

This is the same reason I think the MCP prediction matters. Once Claude Design exposes itself through MCP, the handoff stops being the only way out. The system can be read from the repo, by Claude Design and by anything else. That changes the loop for the better. But it isn’t there yet.

For now, the handoff is one bridge. DESIGN.md is the road.

Where it all fits

A quick mental model before we go to setup, since this is the part that confuses most readers right now.

A while back I wrote about the two modes of design: divergent (explore fast, generate options, find direction) and convergent (refine, build, ship). AI tools belong in one mode or the other.

Here’s where the new layer of products fits:

The thing to notice: DESIGN.md sits underneath everything else.

Claude Skills are a useful adjacent layer worth a quick word. A Skill is a markdown file in .claude/skills/ that an agent loads when the task matches. Your DESIGN.md can be a Skill the agent picks up automatically when it’s working on UI. Or you can author additional Skills that point at it. Either way, the system is still in your repo. Skills are the loading mechanism, DESIGN.md is the load.

Divergent tools generate ideas. Convergent tools ship them. Capability layers tell the agent how to behave. The foundation is what every layer reads to stay on-brand.

Set the foundation first. Everything else stops drifting.

So where do you start?

Start with DESIGN.md.

It’s the foundation. It’s open. It’s free. It works with every engineer’s preferred IDE. It is editable by your team in the same way every other config file in your repo is editable. It will outlast any single AI product, including the one Anthropic shipped last week.

Drafting it forces you to do work no extraction can do for you. You have to articulate why your system is the way it is. You have to write down the principles, the heuristics, the dark mode handling, the RTL rules, the motion constraints. Those are the parts an agent can’t infer from a Figma file. They are also the parts that make a system feel like yours and not like every other AI-generated UI.

Once you have a DESIGN.md, Claude Design becomes more useful, not less. You can point it at the file as part of your project context. The output gets tighter. The drift goes down.

The reverse is not as true. A Claude Design extraction without a DESIGN.md still leaves you without a portable contract for the rest of your stack.

DESIGN.md is the foundation. Claude Design is one of many tools that become better on top of it.

If you want a head start on extraction, Claude Design can produce a useful first-draft token list from a Figma file or repo. Treat the output as raw material. Move it into a DESIGN.md. Add the prose that makes it yours.

One thing worth flagging

If your codebase is proprietary and you point Claude Design at it, you are sending that code to Anthropic.

Figma files are different. Parsed locally in your browser. Never uploaded.

But codebase ingestion goes server-side.

If you’re on an Enterprise plan, it’s worth checking that your contract covers this before pointing Claude at a production repo. Quick conversation with your team. Easy to do, easy to skip.

How to set up DESIGN.md for your design org

Next week’s playbook walks through the full setup. The version that’s working in production at botim, on Nova, today.

Here’s what’s covered:

• The 9+5 framework. Nine canonical sections every DESIGN.md should have, plus five production extensions (iconography, motion, RTL, voice, heuristics) that the official spec doesn’t cover yet

• The principles layer. The part the spec doesn’t have. The part that makes a system feel like yours

• The 10 heuristics every production system needs. Hick’s Law. Decision paralysis. WCAG minimums. Each cited, each enforceable, each written for the agent to follow

• The dark mode build workflow. One source-of-truth file, two Stitch-compliant outputs, a small build script that prevents drift

• The starter template you can fork in five minutes. Same structure, your tokens, your principles

• The wiring across Cursor, Claude Code, and Figma Make. Same prompt, three setups, side-by-side outputs

Built on a public GitHub repo you can clone, fork, or pull from directly. Apache 2.0, like the upstream spec.

Take what helps. Adapt it to your team. Skip what doesn’t fit. The whole point is to give you a foundation you can start writing this week, not a rulebook you have to follow.

If you’ve been hand-rolling your own context files for Cursor or Claude Code, this is the one to subscribe for.

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 was collaboration. It wasn’t. Version conflicts and naming chaos: homepage_final_v3_FINAL_USE-THIS-ONE.sketch. You know the drill.

We tried Abstract. We tried Zeplin. Band-aids on a broken workflow.

Then someone pulled up Figma in our weekly sync. Two cursors on the same canvas. Real time.

We were sold in under five minutes.

Migration took three months. A hundred-plus designers exporting out of Sketch, rebuilding libraries, relearning muscle memory. Painful. But nobody asked why. Collaboration wasn’t a feature of Figma. It was the product.

Fast forward to today, and I’m getting déjà vu.

The canvas is moving again

A new wave of tools is here, and they don’t treat pixels as the canvas anymore.

Google Stitch, Paper and Pencil evolved into an AI-native infinite canvas paired with a design agent that reasons across your entire project. You don’t open a blank file. You describe what you want, drop in a screenshot or a few lines of code, and Stitch generates working UI. They’re calling it “vibe designing.” You can literally talk to it. “This header feels too heavy.” It adjusts.

Then last week, Anthropic launched Claude Design. Different bet, same destination. You point Claude at your codebase, and it builds a design system from what already exists. Your colors, typography, components. All reverse-engineered from your live product. Every prototype after that is automatically on-brand. When you’re ready, it bundles the whole thing for Claude Code, the same AI that writes the production code.

Three days before that launch, Anthropic’s CPO Mike Krieger resigned from Figma’s board.

Make of that what you will.

Figma assumed you start with a blank canvas and place elements on it. These tools assume you start with intent and refine the output.

That’s a category shift.

Design used to happen on the canvas. Now it happens in the conversation.

I write weekly playbooks for designers using AI. If that’s you, subscribe to Design AI Stack.

The wallet screen test

A few weeks ago I posted two screenshots in our design team’s group chat at Botim. One was our Wallet screen, hand-designed by a product designer. The other was the same screen, generated end-to-end by Claude.

That moment told me everything I needed to know. AI tools like Claude Code, Cursor, Claude Design, and Stitch are already remarkably good at production-ready UI. Give them a prompt, a design system, and some context, and they ship something competent, consistent, and on-brand.

Not inspired. But shippable.

And for the vast majority of screens in the vast majority of products, shippable is exactly what you need.

What AI still can’t do

This is where designers push back. “AI can do my job?”

That’s not what’s happening. What’s happening is more interesting.

There are two types of design work: the creative and the mechanical.

The creative is the thinking. Understanding a user’s pain. Reframing a problem. Deciding what not to build.

The mechanical is the execution. Mockups, variations, specs, assets, consistency.

The mechanical part? Give it to the machines. Fully. Without guilt.

The creative part is still ours. And it matters more than ever.

Here’s why. AI works by inference. It’s consumed decades of interface design and is extraordinarily good at recombining what already exists. But recombination is not invention.

Pinterest didn’t redesign the grid. They broke it.

TikTok didn’t redesign the video feed. They eliminated it. Tinder didn’t redesign the dating profile. They turned it into a gesture.

Every one of those came from a human insight about human behavior. Not from analyzing existing patterns and producing a variation. They required someone to look at a problem sideways and have the conviction to ship something that initially seemed too simple or too strange.

Could an AI have proposed that swiping on faces would become a billion-dollar interaction?

I doubt it.

The interview question

I’ve been asking my peers a question lately: “As AI disrupts our industry, how do you plan to pivot your career when the work we do is made obsolete by Gen AI tools?”

Most of them freeze.

The honest answer is: the job is splitting in two.

One path is craft. The pixel-level, implementation-focused work that’s defined the profession for fifteen years. This path is being automated, fast. Fighting that is like my old team fighting to stay on Sketch because they’d customized their toolbars. Nostalgia is not a strategy.

The other path is invention. The messy, ambiguous work of identifying unmet needs and proposing interactions that don’t yet exist. This is where the value is moving. It rewards skills design school barely teaches: ethnographic research, systems thinking, behavioral psychology, the conviction to propose something genuinely new. They ones who can see what AI cannot. The unspoken frustration. The latent desire. The gesture that hasn’t been invented yet.

Figma’s legacy

Figma’s real legacy isn’t the multiplayer cursor or the browser-based editor. It’s the proof that tools shape culture. Figma made design collaborative, and in doing so, it changed what it meant to be a designer.

The tools coming next will change the meaning again. When code is the canvas, when an AI agent is your collaborator, when your design system lives in your codebase, “designer” will mean something closer to “inventor” or “interaction architect” or maybe something we don’t have a word for yet.

I don’t know exactly what that looks like. But it feels familiar. That same electricity I felt watching two cursors move on a canvas in 2018, knowing the old way was already over.

The only question is whether we’ll spend three months migrating, or three years resisting.

Want the actual stack I’m running on production work?

The full breakdown. Which tool I reach for when, the prompts that actually hold up under real workloads, where Claude Design, Stitch, Cursor, and Claude Code each fit (and where each one still breaks), and the file structure I use to keep them from stepping on each other.

This is part of my Design Stack Playbook. Constantly being updated as the tools evolve.

Paid subscribers get it below.

Subscribe now

Sherizan is Chief of Design at Botim, MENA’s fastest-growing super app. Previously Design Leader at TikTok and Senior Principal Designer at Grab. He writes Design AI Stack, where he shares weekly playbooks on AI workflows for designers.

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 just trying to figure out:

How does this actually help me design better and faster?

That’s why I created The AI Design Map not to tell you what you should do, but to share what I’ve learned while building with these tools every day. Think of this more like a guide from a friend who’s walked the same messy path and found a few shortcuts worth sharing.

Subscribe now

Let’s break it down:

1. The Two Modes of Design

Before AI tools, designers naturally switched between:

🌀 Divergent mode — exploring possibilities

You sketch ideas, generate directions, mood-board, draft variations.
It’s the playground phase.

🎯 Convergent mode — shaping the final version

You refine, polish, tighten details, and move closer to the final product.

AI doesn’t change these modes it just gives us better tools for each one.

Understanding this is the foundation of the new design workflow.

2. The AI Tools That Belong in Each Mode

Instead of comparing everything (“Is Cursor better than Figma Make?”), it’s more helpful to see where each tool shines in the design process.

This is not a definitive list, more like a cheat sheet I wish I had earlier.

🌀 Divergent Tools: for exploring fast

These tools help you generate ideas quickly without worrying too much about polish.

Stitch, v0, Magic Patterns

These tools are for exploding ideas. Explore fast, test ideas, generate options.

• Fast exploration

• Zero friction

• Great for ideation

• Perfect for “show me 10 options before lunch”

But they are not designed for long-term flows, BAU refinement, or stakeholder demos.

They’re your brainstorming buddies, not your delivery tools.

Cursor

Surprisingly great even at the early stage when you need pseudo-screens or structure.

Convergent Tools: for shaping the real product

When you’re ready to turn an idea into something polished and production-ready, these shine.

Lovable, Replit & Figma Make

Specifically Make is your “okay let’s get serious” tool.

Once your direction is chosen, Make helps you:

• make a flow feel real

• test with users

• show PMs and founders

• build BAU prototypes

• visualize the 6–12 month roadmap

• align everyone without writing code

Make is not for wild exploration. It’s for precision.

This is where designers move from ideas → reality.

My Top Pick: Cursor → The Only Tool That Does Both

Cursor is the first tool that lets designers:

• explore UI with prompts (divergent)

• refine UI and flows (convergent)

• build real product code (production)

Cursor becomes a designer’s superpower because it changes how you design. Instead of drawing rectangles and gradients, you start shaping UI with language.

Sometimes I go Stitch → Cursor.
Stitch helps me quickly visualise what a new app’s UX flow could look like.
Then I move it into Cursor for refinement, exploration, and building.

Sometimes I go Lovable → Cursor too. (Converge → Converge)
I keep hitting a ceiling on Lovable when it comes to more precise edits.
That’s where I move it into Cursor and continue refining and building.

3. Why the Confusion Happens

Most of the frustration comes from mixing these two modes.

• Using a convergent tool too early (e.g., polishing before exploring).

• Using a divergent tool too late (e.g., generating random ideas when dev is waiting for final UI).

The fix? Match your tool to the mode you’re in.
It sounds simple, but it completely changed how I design.

4. How I Personally Use AI Across the Workflow

Here’s my actual workflow not theory, just what’s been working.

Step 1: Explore with Make + Gemini/ChatGPT

Rough flows, ideas, UI directions.

Step 2: Switch to Figma for structure

Use the team’s design system, constraints, components.

Step 3: Move to Cursor when ready to build

This is where the product comes alive.

Step 4: Iterate between Figma ↔ Cursor

This loop has become the real magic.

Step 5: Ship early prototypes

Because now you can.

It’s not linear but it’s fast, flexible, and future-proof.

5. Tips for Designers Navigating the AI Era

Here are the things I wish I knew earlier:

Don’t fight the tools

AI won’t replace your skills, it amplifies them.

Use divergent tools to unblock yourself

When stuck, Generate → Pick → Refine.
It’s wildly efficient.

Your design system matters more than ever

AI becomes powerful only when it knows your components.

Learn how to write better prompts

Prompting is the new UI skill.
Think of it like you’re giving instructions to a junior designer.

Don’t compare tools.. combine them

The winners are the designers who know how to orchestrate tools, not pick sides.

Give yourself permission to explore

You don’t need to be perfect on day one.
Just try, learn, refine.

6. The Big Picture: Designers Are Not Being Replaced

We’re evolving. It’s redefining what designers can do.

More strategy.
More creativity.
More product thinking.
Less grunt work.

Designers who embrace this shift will have more impact than ever.

7. You Don’t Need to Master Everything

This map is not a prescription.
It’s a starting point.

Take what helps.
Ignore what doesn’t.
Adapt it to your style and your team.

And remember:
The best designers in 2025 won’t be the ones who know every tool,
they’ll be the ones who know how to think, explore, and ship with AI.

If you want deeper breakdowns, tutorials, and real workflows, I share them weekly on here.
Always happy to help designers navigate this wild new world together.

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 fixes that.

By the end, you’ll have a complete loop:

Make prototype → Notion database → Notion AI report

All you need is Make, Notion, and a small FigJam plugin.

Outcome: You will have a repeatable user testing workflow you can reuse for every prototype you build.

2. What We’re Building

Before diving into the steps, here’s the full workflow:

3. Prerequisites

You will need:

• A Make prototype (published)

• A Notion workspace

• A Notion internal integration key

• A Supabase account to store Notion keys

No coding knowledge required. Just copy, paste, and follow along.

4. Connect Notion using the new “Add Connectors” feature

You need to set up two environment variables (secrets) for the integration to work:

a. [NOTION_API_KEY]: Your Notion integration API key

• Go to https://www.notion.so/my-integrations

• Create a new integration or use an existing one

• Copy the “Internal Integration Token”

• Paste it when prompted by the app

b. [NOTION_DATABASE_ID]: Your database ID

• Open your “User Testing Findings” database in Notion

• Copy the database ID from the URL (the part between the last `/` and the `?`)

• Paste it when prompted on Figma chat window

c. Grant Database Access

After creating/updating your Notion integration:

1. Open your Notion database

2. Click the “...” menu in the top right

3. Scroll down and click “Add connections”

4. Select your integration from the list

5. Click “Confirm”

d. Supabase Secrets

This is where Supabase comes in to store the keys securely. It will automatically prompt in the chat that it’s storing both variables, all you have to do is to confirm.

Prompt

Save 4 pieces of information and send it to Notion “User Testing Findings”
- rating (1-5)
- comments
- timestamp
- any information you can get from device and user

5. Add your feedback form

I created a simple “CSAT” type of feedback where users can rate between 1 to 5. If rating is below 3, it will trigger another bottom sheet to capture free text.

Prompt

When user leaves a rating below 4, trigger another feedback sheet to capture the free text input.

6. Let Users Test Your Prototype

Publish your Make prototype and share the link.

• Now try submit a rating and leave feedback.

• It will generate device info automatically.

• Every submission goes straight into Notion.

Run a small test with 1–2 users and confirm entries appear in Notion.

You’re Done

In under 10 minutes, you built a working user testing loop:

• Make records Rating + Feedback + Device

• Notion stores everything

• Notion AI summarises it into insights

No testing tools.
No subscriptions.
Just Make + Notion + AI doing the heavy lifting.

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.

Here’s the full breakdown of how the hack works.

1. What This Hack Actually Unlocks

Because the camera works in published Make apps, you can prototype:

• QR / barcode scanning

• KYC & identity checks

• Ticket scanning

• Payment verification

• Any flow where the user points their device at something

This is the first time designers can simulate real hardware in a no-code prototype.

2. What You Need

This hack only works if:

• You’ve published your Make prototype

• You open the link on a real phone (not desktop)

• Your flow includes a screen where Make expects a “camera view”

The camera will not activate inside Figma Preview which is why most people don’t even know this exists.

3. How the Hack Works (Step-by-Step)

Step 1 — Create your “Scan QR” CTA

Place a button in your UI, like:

Scan QR Code

This is your entry point.

Step 2 — Add a Prompt That Suggests Camera Intent

This is the key part.

Make responds to intent, even if it’s not a documented feature.

Prompt:

When CTA is clicked, open a camera scanning view with corner indicators.

Make will generate a special “camera mode” canvas it’s not visible in the editor, but it exists in the published output.

Step 3 — Add a Second Prompt for Detection

Because Make reads intent, you can chain the behavior:

Prompt:

When the camera detects a QR code inside the corner indicators, navigate to <your page>.

Even though you don’t see a “QR detection” block in Make, the published app will activate the camera and fire the event.

Step 4 — Publish the App

This is where it comes alive.

1. Click Publish

2. Scan the QR code on your phone

3. Open the app through the published link

4. Tap your Scan CTA

Your camera will turn on with your UI frame on top as if this were a native app.

4. Why This Hack Works

Make’s runtime is built on real React Native primitives.

Camera access is already baked into the stack even if the interface doesn’t expose it yet.

When you write prompts that imply a “camera action,” Make maps that intent to its underlying native module.

So yes you’re using a feature that technically exists, just not officially offered.

You found the backdoor.

5. Practical Use Cases for Designers

This is insanely useful for high-fidelity prototyping:

• KYC onboarding: “Scan Emirates ID”

• Fintech: “Scan card for verification”

• Ride-hailing: “Scan QR to start trip”

• Events: “Scan ticket to enter”

• E-commerce: “Scan product to add to cart”

Engineers and PMs will think you built a real app.

6. Why This Hack Matters

Designers can now test flows that were previously impossible:

• You can run real usability tests

• You can validate scanning UX

• You can show live hardware interactions without writing code

• You can simulate KYC and verification flows before engineering starts

This pushes Make into “functional prototype” territory.

Happy Prototyping!

Subscribe now

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

What We’re Making

You’ll create two separate Figma Make prototypes that can:

• send information to each other

• update instantly

• behave like a real product

• show live changes on both screens

Yes, for real.
Yes, in Make.
No, you don’t need to code.

Set Up Supabase (Designer-Friendly)

Step 1 — Create a Supabase project, it’s free for first 2 projects.

• Go to supabase.com

• Click “New Project”

• Name it anything (e.g., “figma-make-demo”)

Step 2 — Connect Supabase to Figma Make

• Hit “Connect”

Create Your Two Prototypes

Here’s actually the fun part of building out your prototype and my quick tips on creating them in the best possible manner.

Connect your Design System

Create a base layout

Never one-shot prompt the entire screen

Side by Side View on Figma

Nifty tab trick to put them side by side

Perfect, now you have 2 working prototypes. Let’s get them to talk to each other!

Prompts to Figma Make (Copy/Paste These)

Below are the exact prompts to give Figma Make so the prototypes interact.

Prompt for Prototype A (Sender)

When you click Pay, send this data to Supabase as JSON:

• sender name

• receiver name

• amount

Prompt: 

When the user clicks the Pay button, take the sender name, receiver name, and amount from the page, and save them as a new JSON row in the connected Supabase table.

That’s it for Prototype A.
No need to overcomplicate it.

Prompt for Prototype B (Receiver)

What you want it to do:

• Watch the Supabase table

• When a new row arrives

• Show a card with the exact data from that row

Important detail:
Figma Make auto-creates a table name when you hook it up.
You just copy that table name and use it in your prompt/logic.

Prompt:

Check this Supabase table for new entries. Whenever a new item is added to <table_name>, display a card on this page using the sender, receiver, and amount from that row.

You’re basically telling Prototype B:

“Keep an eye on this table. If something new appears, show it.”

And that’s it!