Anthropic has provided us with the complete guide how to get the most out of Claude Code. This is how I interpret it for my smaller projects where you don’t need a full fledge design system.

Read more

I need to be upfront about something before we start.

I’m a designer. I’ve worked on apps serving over 1.9 billion active users at TikTok, 50 million active users at Grab. My coding knowledge stopped at JavaScript. And I’m writing an article about programming languages.

That alone should tell you how much has changed.

Two years ago, I wouldn’t have had an opinion on this. Now I’m deep in Figma MCP, Claude Code, and vibe coding workflows and the question of what language things are built in is suddenly very relevant to my work. Not because I’m writing code. But because the line between designing and coding is dissolving so fast that the distinction might not matter soon.

Whether that’s exciting or terrifying depends on the day.

The mess under the hood

Here’s something most people outside big tech don’t realise. The apps you use every day are not built in one language.

TikTok? Parts Kotlin and Swift for native UI. A custom cross-platform framework called Lynx that ByteDance built internally and open-sourced in 2025 because nothing on the market could handle their complexity. Grab serving 50 million users across Southeast Asia? Similar patchwork. React Native here, native code there, custom bridges connecting everything.

This is not an exception. This is the norm.

A single design system, the one we spend months perfecting in Figma has to translate into multiple codebases, multiple languages, multiple rendering engines. And the translation is lossy. Every time. “Should this spacing be 16px or 20px?” is a Slack message that has been sent a billion times across the industry, and it exists because design files and code are fundamentally different representations of the same thing.

So when people talk about “design to code” or “design in code,” this is the part they’re skipping. It’s not just a handoff problem. It’s a multi-language, multi-platform infrastructure problem that nobody has cleanly solved.

Which got me thinking. If AI is rewriting how we build software… will it also rewrite what we build software with?

Every era invents the language it needs

Quick history, because it matters for what comes next.

The web needed a scripting language for browsers. Brendan Eich built JavaScript in 10 days in 1995. Mobile needed languages that could talk to hardware. Apple created Swift. Google backed Kotlin. Facebook looked at all of this and said “what if we could use JavaScript to build native apps?” and React was born. Machine learning needed something accessible to researchers who aren’t systems programmers. Python became the default, not because it’s fast, but because the ecosystem made it frictionless.

Every time the paradigm shifted, a new language emerged. Facebook invented React. Vercel invented Next.js. The pattern is consistent.

So here’s the question. AI is the biggest paradigm shift since the internet. What language or what thing will it invent next?

The “language doesn’t matter” argument

The numbers are hard to argue with.

AI writes roughly 30% of Microsoft’s code and over a quarter of Google’s, according to their own CEOs. Y Combinator reported that 25% of startups in their Winter 2025 batch had codebases that were 95% AI-generated. Stack Overflow’s 2025 Developer Survey found 80% of developers using AI coding tools weekly.

Andrej Karpathy coined “vibe coding” in early 2025 the idea of describing what you want in plain English and letting AI handle the implementation. Collins Dictionary named it Word of the Year. By early 2026, Karpathy himself said vibe coding is already passé. The new paradigm is “agentic engineering” you’re not writing code at all, you’re supervising agents that write it for you.

Jensen Huang, NVIDIA’s CEO, put it even more bluntly: “It is our job to create computing technology such that nobody has to program and that the programming language is human.”

If AI can translate natural language into Python, Swift, Kotlin, or Javascript equally well, then the programming language becomes an implementation detail. Like assembly language. You don’t think about assembly when you write Python. Maybe soon, you won’t think about Python when you describe an app.

There are still new languages emerging like Mojo, built by Chris Lattner (the creator of Swift), reads like Python but performs like C++, heading to 1.0 in 2026. But the bigger story isn’t any single new language. It’s the possibility that language choice itself becomes invisible.

OK Sherizan. So what does this mean for designers?

This is where I have to be honest about two things that are both true at the same time.

1) The “design is dead” argument is not wrong.

I know designers don’t want to hear this. I don’t particularly want to write it. But let’s look at what’s actually happening.

PMs and designers at Meta have publicly said they now show working products instead of UI prototypes. Designers are shipping MVPs through AI coding tools before developers even get briefed. Figma’s stock dropped roughly 85% from its post-IPO peak. Wall Street is calling it the “SaaSpocalypse” a trillion-dollar selloff in software stocks driven by fears that AI is eating the workflows these companies were built on.

Shadcn happened. A component library so well-designed, well-documented and so easy to prompt with that people started building dashboards, landing pages, and full interfaces directly with shadcn components with no Figma file needed. You describe what you want, AI generates production-ready React with shadcn, Tailwind, and Next.js. It looks good. It works. No designer touched it. I’m a huge fan of v0 and what Vercel has done for vibecoding.

Then frontier models got scary good. You can one-shot a full interactive dashboard with Claude Opus 4.6 or Gemini Pro. Not a mockup. Not a prototype. A working component with real interactions, real state management, real functionality. The kind of thing that used to take a designer days in Figma and a developer weeks to implement done in literally minutes by someone who never opened a design tool.

There are reports that programmer employment in the US fell 27.5% between 2023 and 2025. The squeeze isn’t just on developers. Entry-level design work, the screen-by-screen production that used to be someone’s first job is exactly the kind of task AI automates first.

If you’re a designer and you’re not at least a little nervous, you’re not paying attention.

2) Something interesting is happening at the edges.

At the same time that people are declaring design dead, a new category of tools is emerging that suggests the opposite.

Pencil.dev calls itself “Design Mode for Cursor.” It’s a Figma-like canvas that lives inside your IDE. Your design files sit in your Git repo. You design visually, AI generates the underlying React. Or you prompt AI, and it designs visually on the canvas. The direction goes both ways.

Paper.design renders every element as real HTML and CSS. No conversion step. You design with real flexbox layouts, real CSS properties, real font rendering. Right-click any element → Copy as React. They raised $4.2M from Accel, and their thesis is interesting: the canvas of the future IS code, you just shouldn’t have to know that.

Figma launched “Code to Canvas” with Anthropic that generates an interface in Claude Code, say “Send this to Figma,” and it lands as fully editable design layers. Plus Figma Make, Code Connect linking components to production code, and MCP integrations letting AI agents read and write to Figma files directly.

These tools aren’t treating design as a step before code. They’re treating design as code. Or code as design. The distinction is breaking down.

And Figma’s own State of the Designer 2026 report shows something that complicates the “design is dead” narrative: 89% of designers say they’re working faster with AI. 91% say AI tools actually improve their designs. Designers leaning into AI are 25% more likely to say they’re satisfied at work.

So which is it? Is design dying? Or is it evolving into something more powerful?

I think the honest answer is: both. At the same time. For different people.

A “what-if” I can’t stop thinking about

I want to be careful here. This is not a prediction. This is a thought experiment. Because I think it’s worth exploring even if it turns out to be wrong.

What if the next programming language isn’t a language at all? What if it’s a design file?

A designer izaias described Figma as “logic wearing a canvas costume.” And he’s not wrong. Every design is JSON. Every component is a node. Auto layout is flexbox. Constraints are code. We’ve been programming all along, we just called it designing.

Paper.design’s canvas renders real HTML/CSS. Pencil.dev stores designs as JSON. Figma’s Code Connect links components to production code. Shadcn gives you a component system that AI can compose into anything.

So here’s the what-if.

And AI handles everything underneath like choosing Swift for iOS, Kotlin for Android, React for web, C++ for the performance layer, building the bridges between all of them automatically.

That messy multi-language architecture at TikTok and Grab? It disappears. Not because someone invented a universal language. But because the design file became the universal specification, and AI figures out the compilation.

Design as the last programming language.

Now, hold on. I can already hear the objections. And they’re valid.

This assumes AI gets good enough at the translation. Right now, it isn’t. Vibe-coded apps have 1.7x more major issues than human-written code according to a CodeRabbit analysis. Security vulnerabilities are 2.7x higher. A Lovable analysis found 170 out of 1,645 apps had data exposure issues. The gap between “looks right” and “works at scale” is enormous.

It also assumes design can encode enough information to replace code. Today’s design files don’t capture business logic, state management, error handling or the thousand edge cases that make software actually work. A beautiful Figma file tells you nothing about what happens when the API fails at 3am.

And it assumes the industry will converge on a standard representation. Figma files are proprietary. Paper.design uses its own format. Pencil uses .pen files. We can’t even agree on design tokens, let alone a universal compilation target.

So yeah. Maybe this is naive. Maybe design files as programming languages is a fantasy that ignores how software actually works at scale.

But.

Two years ago, the idea that a designer could one-shot a working dashboard by describing it to an AI was also a fantasy. And here we are.

Where this actually leaves us

I don’t know if design is the last programming language. I don’t know if programming languages will become invisible. Nobody does. Anyone who tells you they know exactly how this plays out is selling you something.

What I do know is this.

The old workflow aka design in Figma, hand off to developers, argue about spacing in Slack, ship something that doesn’t match the mockup is dying. That part isn’t controversial.

What replaces it is up for grabs. Maybe it’s designers coding directly. Maybe it’s AI agents that make the design-to-code gap irrelevant. Maybe it’s new tools like Paper and Pencil that merge the two entirely. Maybe it’s something we haven’t seen yet.

For developers: if programming languages become an implementation detail handled by AI, then the value shifts to systems thinking, architecture, and knowing what to build, not which syntax to build it in. Karpathy’s “agentic engineering” isn’t just a rebrand. It’s a fundamentally different job description.

For designers: if AI can generate any interface from a description, then the differentiator isn’t your ability to push pixels. It’s your ability to understand users, define problems, make intentional decisions, and apply taste that AI can’t replicate. Paper.design’s founders put it well: AI will help turn design into code, but it’s the designer’s role to decide what to build, steer the AI, and make sure it’s cohesive.

The people who thrive in this next era won’t be defined by their tool like Figma, Cursor, Claude, whatever comes next. They’ll be defined by their judgment.

And honestly? As someone whose coding stopped at JavaScript but who’s now deep in Claude Code and Figma MCP workflows, I find that both terrifying and kind of hopeful.

I just don’t think we should pretend we know how this ends.

What’s your take? Is design evolving or dying? Is the programming language question even the right question? I’m genuinely working this out in public . Hit reply, I want to hear what you think.

You’ve spent hours getting the component just right inside Figma. The spacing is tight, the tokens are named correctly (mostly), and the layout actually makes sense. You open up your AI coding tool and then you write a prompt. Something like:

“Build this card component in React Native.”

And what comes back is... close. But not right. The padding is off. The component ignores your design tokens. The variant states are missing. So you iterate. You write a better prompt. You get closer. You iterate again.

What just happened wasn’t a failure of AI. It was a failure of context. The model didn’t know what it didn’t know and neither did you, until you saw what was missing.

I built DesignAgent because I kept living in that gap.

The Real Problem with Prompting from Design

There are a few things that silently break every build:

• Components without auto-layout that confuse the AI’s understanding of spacing relationships

• Design tokens that exist in Figma but never make it into the prompt

• Platform mismatches: a component built for web being prompted for a React Native context without adjustment

• Missing variant states, unnamed layers, and absolute positioning that looks fine visually but generates brittle code

The result? Inconsistency. Every prompt is a guess. Every handoff is a negotiation.

What DesignAgent Actually Does

DesignAgent is a Figma plugin that sits inside your workspace and does something really simple: it reads your current selection, scores it, and writes the prompt for you.

Not a generic prompt. Not a template you fill in. A context-specific, developer-ready prompt built from what’s actually in your design right now, for the platform you’re actually building on.

Select a component. Open the plugin. Choose your target platform. The prompt is ready.

Five platforms, one consistent workflow

DesignAgent supports five presets out of the box:

• Next.js + Tailwind — for web teams building with the modern React stack

• React Native + NativeWind — for mobile teams who want utility-class consistency across platforms

• Web HTML/CSS — for projects that don’t live inside a framework

• SwiftUI — for iOS builders working natively

• Jetpack Compose — for Android developers handling UI in Kotlin

Switch the preset, and the prompt changes. The structure adapts. The warnings update. The guidance reflects what that specific platform needs from your design.

It doesn’t just generate.. it scores.

Here’s the part that surprised even me during development: the scoring system became the most valuable feedback loop.

Before you ever copy a prompt, DesignAgent evaluates your selection across five dimensions:

1. component structure

2. tokenization

3. layout

4. naming

5. variant coverage

And gives you a score. It surfaces warnings where things will likely break in code. It flags absolute positioning. It tells you when you’re missing token references that your prompt will assume exist.

You don’t have to guess why the output isn’t right. The plugin tells you, in plain language, before you ever leave Figma.

What’s Actually Inside a DesignAgent Prompt

This is the part I want to spend some time on, because it’s where the real work happens and it’s what makes DesignAgent different from any other prompt generator I’ve seen.

Most “prompt generators” are wrappers. They take what you tell them and rephrase it. DesignAgent is not that. The prompt it builds is a structured engineering document and it contains things you would never think to write yourself.

1. It knows what you selected

Before a single word of the prompt is written, DesignAgent reads your selection and classifies it. Not just the name and the size, but the intent: is this a screen? A standalone component? A reusable section? A multi-frame flow?

The classification matters because each of these things needs to be built differently. A screen prompt includes rules for a single output file. A flow prompt includes a sequencing spec — screen order, transitions, routes — before any code is written. A component prompt focuses on props and variants. A section prompt includes instructions for how it mounts into a parent screen. The prompt structure changes based on what you actually selected, not what you described.

2. It sets Figma as the only source of truth

One of the hardest problems in AI-assisted UI development isn’t generating code. It’s preventing the AI from making things up. Left to its own devices, an AI coding tool will fill in gaps with reasonable-looking guesses and those guesses are where bugs and inconsistencies are born.

Every DesignAgent prompt includes a set of hard constraints that the AI must follow. The most important: it may not guess any value that can be retrieved directly from your Figma file. Spacing, typography, color, tokens, component bindings all of it must come from the design. If something is ambiguous or missing, the AI is instructed to surface it as an open TODO with the exact node reference, not to make a decision on your behalf.

This is the “no invention” rule, and it’s baked into every prompt DesignAgent generates.

3. It tells the AI how to read your design in the right order

Here’s something that surprised me in development: the sequence in which an AI queries Figma matters enormously for both accuracy and efficiency. Request too much at once and the context overflows. Request in the wrong order and you miss dependencies between tokens, components, and interactions.

DesignAgent builds a specific, ordered reading strategy into every prompt. It tells the AI to start shallow just the root and immediate children and only go deeper where the design requires it. Then variables and tokens. Then component mappings. Then visual reference. Each step has a fallback if the previous one returns incomplete data.

This sequencing is invisible to you as a user. But it’s what separates a prompt that produces consistent, production-ready code from one that produces something close but structurally off.

4. It accounts for your design system

If your components have Code Connect mappings a Figma feature that links design components to their code equivalents DesignAgent’s prompts will instruct the AI to use those mappings. Not as a suggestion. As a requirement.

The prompt also tracks token coverage: which values in your design are backed by a design token versus which ones are raw hardcoded values. This shows up in the scoring panel, and it also shapes the prompt. The AI is told where tokens exist, where they don’t, and how to handle each case. The result is code that references your actual design system rather than inventing a parallel set of magic numbers.

5. The output is structured, not open-ended

Most AI prompts end with something vague like “build this.” DesignAgent prompts end with a precise output contract: a file tree, code blocks labeled by filepath, and an open TODOs list for anything the AI couldn’t resolve from the design. No alternatives. No multiple implementations.

This matters for teams. When every developer is working from the same structured prompt format, the code that comes back follows the same structure too. It’s reviewable. It’s predictable. It fits into your existing codebase rather than arriving as a surprise.

Why Consistency Matters More Than You Think

The dirty secret of AI-assisted development is that the variance in prompt quality creates variance in output quality (garbage in, garbage out) and that variance compounds across a team.

When four engineers on the same project are prompting from the same designs but writing their own prompts, you get four different interpretations of the same component. Over time, that becomes technical debt. Inconsistent spacing. Token values hardcoded in some places, referenced in others. Components that look the same in Figma but behave differently in production.

DesignAgent solves this not by being opinionated about your design but by being precise about what your design already says. The prompt it generates isn’t my interpretation of your component. It’s a structured reading of your Figma node, translated into the language your AI coding tool needs to hear.

Same design, same platform, same prompt. Every time. Whether it’s you or a teammate who just joined the project.

Who This Is For

If you’re a designer who’s tired of being told “the code doesn’t match the design” then DesignAgent is for you. Not because it fixes the code, but because it equips you with the context to communicate your design accurately to AI tools and to the developers working alongside them.

If you’re a developer who spends too much time reverse-engineering Figma files to write a good prompt then DesignAgent is for you. The analysis work is already done. The spec is already extracted. The prompt is already written.

If you’re a team that’s trying to move faster without letting quality slip — DesignAgent gives you a shared language between design and code that doesn’t depend on whoever wrote the prompt that day.

Where We Are Right Now

DesignAgent is currently available in Figma Community. That means the core engine is working: the analysis, scoring, prompt generation and platform presets are all live inside Figma.

I’d love to hear what breaks, what surprises you, and what you wish it did differently.

Read more

I love vibecoding but I need to talk about the part of vibecoding nobody posts screenshots of.

The bill. 🧾

Read more

High-quality prototypes in Figma Make come from one decision:

Use the same component library engineers already ship.

Figma Make can now install npm packages, including yours or ANY component library package, so your prototype uses real production components instead of lookalikes.

What Figma Make expects (so you do not fight the tool)

Your design system package needs to be:

• React 18+

• Published as an npm package (public npm, or your org’s private Figma npm registry)

• Make currently supports React codebases for design system packages.

Path A: Bring your org design system package into Make (the righteous path)

Step 1: Publish your package (public or private)

If your design system is internal, publish it to your org’s private npm registry in Figma Make.

Private registry setup (one-time admin step):

1. Create a new Figma Make file

2. Make settings → Figma npm registry

3. Enter your org scope (example: @exampleco)

4. Generate key (org admin required)

5. Copy the snippet into your .npmrc

6. npm publish your package

Then, inside a Make file:

• Ask chat: “install @mycompany/design-system”

• Or add it to package.json directly

Tip from Figma: after setting up the npm registry, create another new Make file before installing the package.

Step 2: Teach Make how to use your design system (this is where quality comes from)

Make can inspect your package, but it performs much better with explicit guidance files.

Every Make file has a guidelines/ folder.
Make reads guidelines/guidelines.md first.

Recommended Structure

guidelines/
  guidelines.md
  design-tokens.md

Guidelines writing rule
Use direct, deterministic language. “Do not…” beats “use sparingly.”

Copy-paste: a strong guidelines/guidelines.md starter

This Make project uses our production React design system from @mycompany/ui.

Rules:
- Always prefer @mycompany/ui components over plain HTML elements.
- Do not invent new UI patterns or colors.
- If a component exists, use it. If unsure, inspect /node_modules/@mycompany/ui.

Always read first:
- overview-components.md
- all files in design-tokens/

Before writing code:
1) Choose components from @mycompany/ui
2) Read the relevant file in components/ (example: components/button.md)
3) Implement using documented props and variants only

Unfortunately, you can’t copy-paste my design-tokens.md as its specifically made for my design system but I’ll show you how I wrote mine.

# Botim Design Tokens (Make Guidelines)

This project must use Botim tokens consistently.
Do not invent new values.
Do not hardcode arbitrary colors, font sizes, or spacing outside this file.

If you must add a new token:
- Add it here first
- Use the same naming pattern
- Keep values deterministic and reusable

---

## Typography

### Font families
- **Brand / UI:** `Inter`

### Type scale (px)
Use only these sizes.

- `type.display.lg` = `32px` (40px line-height, 700)
- `type.display.md` = `28px` (36px line-height, 700)
- `type.title.lg` = `22px` (28px line-height, 700)
.. and more

### Usage rules
- Screen titles use `type.title.lg` or `type.title.md`
- Primary body text uses `type.body.lg`
- Secondary/metadata uses `type.body.md` or `type.caption`
- Do not use font weights other than 400, 500, 700

---

## Spacing

### Base unit
All spacing is based on **4px**.

### Spacing scale (px)
Use only these values.

- `space.0` = `0px`
- `space.1` = `4px`
- `space.10` = `40px`
.. and more

### Layout rules (mobile)
- Screen horizontal padding: `space.4` (16px)
- Section vertical spacing: `space.6` (24px)
- Card padding: `space.4` (16px)
- Gap between stacked items: `space.3` (12px) or `space.4` (16px)
- Button height target: 48px using padding + line-height, not random height values

---

## Color

### Neutral
- `color.bg` = `#FFFFFF`
- `color.surface` = `#F7F8FA`
- `color.border` = `#E5E9F0`
.. and more

### Brand
- `color.brand.primary` = `#2F6BFF`
- `color.brand.primaryHover` = `#2557D6`
- `color.brand.primaryPressed` = `#1E47B3`
.. and more

### Semantic
- `color.success` = `#16A34A`
- `color.successBg` = `#EAF7EF`
- `color.info` = `#2563EB`
.. and more

### Usage rules
- Default page background: `color.bg`
- Cards/containers: `color.surface`
- Borders: `color.border` (do not invent lighter/darker borders)
- Primary CTA: background `color.brand.primary`, text `color.brand.onPrimary`
- Destructive CTA: background `color.danger`, text `color.text.inverse`
- Links: `color.info`
- Error messages: text `color.danger`, background `color.dangerBg`

---

## Make enforcement rules

- Always reference tokens by name in code (or via your design system theme).
- Do not introduce new hex codes in components.
- Do not introduce spacing values outside the spacing scale.
- Do not introduce font sizes outside the type scale.

I know it’s pretty long, but that’s how I want it to be, detailed and deterministic so the quality of the output is accurate.

Putting it to the test

As you can see from my example below, the prototype on the left is using the new npm registry that fetches my production-quality code components that my devs use, while on the right is using our Figma design screen with design system file attached (the current or maybe now its the traditional way).

From a UI and visual perspective, the version on the left is MILES BETTER as it adheres to the layout, spacing is being picked up by the guidelines.md whereas the “traditional” way of building from Figma design files, the divider breaks, the spacing is not inherited, it looks like that cheap prototype that does not look like it deserves to be published and shared.

But here’s the best part..

The prototype on the left also inherits all the component props and all the state changes so you get the actual code components that your devs are using in production!

Check out this demo video where you can see how it automatically:

• inherits the input field active state with the “clear values” X icon.

• the buttons have the exact implementation of the pressed and hover states.

Final step: Turn it into a template for the whole org

After installing packages and adding guidelines, publish the Make file as a template so everyone starts from the same baseline.

Path B: No internal design system yet? Use an existing one (the fun path)

Maybe you need to move fast as a solo founder or just a team with no designers, this one’s for you!

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.

I vibecoded an app. It worked. Then it didn’t.

About a year ago, I launched Nasma, a daily habit app.
Not after months of planning. Not with a big team.

I tried Cursor for the first time in Jan 2025, wanted to see if I could actually build a native iOS app, and… two weeks later it was live.

I posted it on LinkedIn.
People downloaded it.
Feature requests rolled in.

So I did what every vibecoder does:

• ship fast

• add features

• keep momentum

Today:

• thousands of active users

• users mainly from the US, UK, India, Indonesia

Except retention was bad.

After Day 14, only ~5% of users came back.

That’s when I stopped shipping and started thinking.

The mistake I made (classic vibecoder move)

I assumed:

“If something feels slow or messy, I just need to refactor everything.”

Wrong.

What I actually needed was clarity before code.

That’s where Cursor’s Plan Mode quietly became the most useful feature I wasn’t using properly. (Well it also didn’t exist back in Jan)

How I actually use Plan Mode (not the marketing version)

I don’t use Plan Mode to “build”.

I use it to:

Read more

And the designer?
Manually stitching meaning together before every review.

This article is about what happens when you stop stitching.

The idea behind Superdesigner

Superdesigner is not a design tool.

It’s not a UI generator.
It’s not a Figma replacement.
It’s not another place to write docs.

Superdesigner is a reasoning layer that runs inside Cursor.

It connects to where real work already lives like Confluence, Notion, Figma, analytics and helps AI reason across them.

“But Sherizan, I can paste all this into ChatGPT”

I hear this a lot.

And yes you can paste:

• your PRD

• some research

• screenshots

• analytics summaries

Into ChatGPT and get feedback.

But that’s not the same thing.

The real difference is not intelligence. It’s grounded, live context

ChatGPT sees what you upload or paste.

Superdesigner sees:

• the actual PRD in Confluence

• the latest research in Notion

• the real Figma file

• the real analytics funnel

Not a summary.
Not a screenshot.
The source of truth.

And when scope changes?

You edit the PRD where it already lives, re-run the review and new gaps surface.

No copy-paste.
No drift.
No stale context.

How Superdesigner actually works (honestly)

One important clarification.

Superdesigner does not magically think on its own.

What it does is very deliberate.

It generates a structured, opinionated design-review prompt grounded in your real project context and passes that prompt to the Cursor AI agent.

You never write prompts.
You never tune roles.
You never say “act as a senior designer.”

You just run the workflow.

That consistency is the product.

A real project walkthrough

In my video, I run Superdesigner on a real project.

Here’s the actual flow.

1. Connect the sources of truth

• PRD → Confluence (downloaded as Markdown)

• Research → Google Docs (downloaded as Markdown)

• Designs → Figma (via MCP)

• Analytics → Amplitude (not in demo, via MCP)

Superdesigner pulls snapshots of these into context so Cursor can reason across them.

2. Run the review

npm run review

Superdesigner:

• generates a design-review prompt

• hands it to Cursor’s AI agent

• produces a design-review.md

No prompting.
No guessing.
Same structure every time.

3. Read the output (this is the magic)

The generated design-review.md is not UI.

It’s a design review that calls out:

• missing states (empty, error, recovery)

• gaps between PRD and flows

• risky assumptions

• things that will come up in review

• things that should come up but usually don’t

This is what you read:

• before design review

• before handoff

• before launch

This file is the product.

Why Cursor matters

Cursor isn’t just an editor.

It’s an agent runtime.

Because Superdesigner runs inside Cursor:

• it understands the full project context

• it can re-run reviews as things change

• it can chain tools together via MCP

This is where things get interesting.

MCP is where this becomes powerful

Figma MCP

Superdesigner can:

• read Figma file structure

• understand flow coverage

• write high-confidence comments back to Figma

Not visual critique.
Not opinions.

Comments like:

• “The PRD mentions a retry state here — I don’t see one.”

• “What happens if the user fails eligibility?”

AI that speaks inside the workflow, not next to it.

Analytics MCP (e.g. Amplitude)

Now add reality.

Superdesigner can reason like this:

• “This step is unclear in design”

• and analytics shows drop-off here

This isn’t design advice anymore.
It’s evidence-backed design reasoning.

Why this is not a Figma plugin

Plugins are great for:

• generating UI

• manipulating canvas

• speeding up execution

Superdesigner is about:

• thinking

• seeing blind spots

• preventing design regret

It doesn’t replace Figma.
It makes you better before you open it.

Solving the blank canvas problem (what’s next)

One of the hardest moments in design is the start.

No screens.
No flows.
Just a rough PRD and some research.

Superdesigner will evolve to support this cold start:

• connect to fundamental research

• read a rough PRD

• generate:

  • user flows

  • state outlines

  • screen structure (not UI)

From there, plugins and tools (e.g. Figma outline generators like CTTF-style workflows) can push that structure back into Figma.

Designers don’t start from a blank canvas.
They start from clarity.

What Superdesigner is (and isn’t)

It is:

• a second brain for designers

• a repeatable design review system

• a reasoning layer across tools

It is not:

• a UI generator

• a design replacement

• another dashboard

Why I’m building this in public

Because I’m already using it.

Before reviews.
Before handoff.
Before launch.

And every time, it catches something small that would’ve turned into a big conversation later.

That’s the value.

If you have a design review this week, run this once before it.

You can clone it entirely free and customise it however you want at superdesigner.ai

If you’ve reviewed enough designs, you know the moment. The screens are polished. The flows look reasonable. The prototype “works.” And yet.. during review.. small things begin to surface. An edge case no one considered. A missing empty state. A flow that technically connects but doesn’t quite make sense when you say it out loud. A requirement that everyone thought they understood but didn’t.

The sprint slows down. Conversations stretch. Designers pissed.

This doesn’t happen because we aren’t careful. It happens because design review today is built on a fragile assumption: that looking at screens is enough to understand intent.

It isn’t.

The real failure mode of design review

In most teams, design work is fragmented by default.

Product requirements live in documents or PDFs. Research lives in decks. Designs live in Figma. Feedback lives in comments. Analytics lives somewhere else entirely. And most of the time, decisions were made in meetings that you didn’t attend.

When review time comes, we open Figma and try to reconstruct the story in our heads. We rely what we remembered happen. We rely on trust that nothing important was lost along the way.

I wasn’t reviewing intent. I was reviewing screenshots.

Why AI hasn’t meaningfully helped (yet)

Over the past year, we’ve seen an explosion of “AI for designers” tools. Most of them promise some variation of speed: faster screens, faster layouts, faster execution.

But review isn’t about speed. It’s about completeness.

The hardest part of design review isn’t drawing the UI. It’s answering quieter questions:
Did we design all the states? Did we account for failure? Does this flow actually satisfy the original intent? Did research insights make it into the final decisions?

AI struggles here because it’s usually given only the output aka the screens and without the inputs that shaped them. Without access to intent, AI can only guess.

Context isn’t a nice-to-have for review. It’s the entire job.

A different approach

Instead of building another web app or Figma plugin, I tried something simpler.

I turned Cursor into my design review workspace.

Cursor already has everything review needs: files, folders, long-form context, and agents that can reason across documents. More importantly, it’s already where I think when I’m trying to understand a system.

So I built Superdesigner.ai as a lightweight, local workflow.

Not a product that generates UI. Not a tool that critiques visual style. But a system that reviews design intent by reading the same artifacts my colleagues rely on just more consistently and on-demand.

What Superdesigner actually does

Here’s a demo of how it works:

At its core, Superdesigner reads three things: the PRD, the research, and the Figma link.

From that, it produces a structured design review. It reconstructs the intended user flow. It generates a checklist of expected screens. It highlights missing states like empty, loading, error, recovery. It surfaces edge cases described in the PRD that never made it into design.

It generates calm, specific comments that can be posted directly into Figma, grounded in intent rather than opinion.

And finally, the icing on the cake. It creates a Figma Make prompt to generate a new prototype with the proposed solutions baked in. Almost Black Mirror-ish.

It doesn’t judge aesthetics. It doesn’t argue taste. It answers a simpler question: is this design complete relative to what we said we were building?

The shift this enables

Design review shouldn’t start in Figma.

It should start with intent.

When intent is explicit and traceable, visual critique becomes easier and more productive. Conversations move from “I feel like something’s missing” to “this requirement hasn’t been addressed yet.”

Superdesigner doesn’t replace designers. It reduces design regret, the kind that shows up late, costs time, and erodes trust.

Why this works inside Cursor

Cursor isn’t just an editor. It’s a thinking environment.

By keeping PRDs, research, review prompts, and outputs in one place, designers stay in flow. There are no dashboards to manage, no accounts to create, no abstraction layers to learn. Just files and agents doing their job.

That constraint is intentional. Review works best when it’s quiet, focused, and grounded.

How I’m sharing this

I’m open-sourcing Superdesigner AI as a template repository.

You clone it, star it, run it locally, and test it on a real project. I recommend starting small like one PRD, one flow, one review. Judge the feedback. Test different models.

See what it catches. More importantly, see what it misses.

That feedback is the point.

Got a design review or critique this week? Run this once and you’re set!

👉 https://github.com/sherizan/superdesigner-ai

Who this is for

This is for designers who care about craft, design managers reviewing multiple projects, founding designers balancing strategy and execution, and teams shipping fast with AI in the loop.

If you’ve ever looked at a design and thought, this seems fine, but something feels off, this tool is built for that moment.

What’s next

I’ll follow this up with a live YouTube build, deeper workflows that connect analytics (Amplitude MCP) before it generates the final design report (now that’s some Black Mirror stuff right there), and thoughts on how we can evolve this into a practice for modern design teams.

For now, try it. Break it. Tell me what it gets wrong.

That’s how this becomes useful.

I’ve been genuinely impressed with Google Gemini lately.

I’ve been testing their Deep Research feature for a while, and it’s surprisingly good at understanding context not just keywords. It doesn’t just scrape the web.. it actually knows where to look.

Including Reddit.

And if you want to understand what designers actually complain about, Reddit is where the unfiltered truth lives.

The Goal

I had two goals going into this:

1. Learn how to build a Figma plugin

2. Figure out real pain points Figma users are facing today

Not vibes.
Not Twitter hot takes.
Real frustrations, repeated by real users.

So I decided to put Gemini to work.

The Prompt I Gave Gemini

Here’s the exact prompt I used:

Read more

And the trio that unlocked it for me is:

Design Tokens → Figma MCP → Cursor.

This workflow completely removed the “prototype first” mindset and replaced it with something faster:

Design → Prompt → Build → Test.

No static flows.No endless handoff meetings. And zero guesswork for how something should feel on mobile.

Let’s break down exactly how I do it.

1. Start With a Clean Figma File

Here’s what we are going to build today:

I prepared two screens (one default state & one end state).

Here’s the baseline checklist I follow:

• Auto Layout everywhere

• All colors, spacing, radii, typography = tokens

• Real variants, not duplicates

• Logical naming: Button / Primary / Large

• No ghost frames

• No random 17px text sizes that “felt right at the time”

Because whatever is in Figma… becomes your code.

2. Activate Figma MCP (Your Design System Becomes an API)

This is where things get interesting.

Figma MCP turns your file into something AI tools can query:

• Tokens

• Components

• Variants

• Layer structure

• Metadata

Cursor can literally ask Figma:

“Give me the real Button component with real spacing, real radius, and the Light/Dark tokens.”

It’s API-level access to your design system.

This is the moment your design file stops being “a handoff document” and starts becoming infrastructure.

3. Cursor Generates a Full Design System Folder

Before any UI is built, Cursor does something magical:

It creates a full folder like this:

design-system/
  tokens.json

Clean, typed, structured.

This is the part that feels like cheating:

Your design system is now real JSON.
Not manually written.
Not reinvented.

Generated straight from Figma through MCP.

And Cursor will reference these tokens for every screen you build.

That’s where Cursor Rules come in.

Create a new rule under .cursor/rules

# Theme Rules

You are building a React Native Expo app.

- Always use tokens from `design-system/tokens.json` for colors, spacing, radius, typography.
- Never hardcode hex colors or random spacing if a token exists.

4. Skip Prototyping — Go Straight to Building in Cursor

This is where the workflow becomes addictive.

Traditionally, you’d spend days:

• mapping flows,

• designing static screens,

• prototyping interactions,

• presenting it all,

• revising,

• re-presenting…

But with MCP + Cursor: the build IS the prototype.

You can actually feel the UI on mobile instead of imagining it.

For example:

In my recent speed run, I built:

• Profile → QR Code navigation

• Plus → Close animated button

• 5 mini icons fading in sequentially

• Real touch interactions

• True mobile motion

• Zero manual code from me

Cursor built everything from my prompts + tokens

The results look and behave better than any Figma prototype because… they’re not prototypes.

They’re real mobile interactions.

5. The Prompt That Drives Everything

Because MCP exposes your design system, your prompts don’t need to be verbose. They just need to be structured.

Here’s my prompt:

Read more

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

There was a time when every new idea started in Figma.

Open a frame.
Drop a layout grid.
Throw rectangles everywhere.
Try a font.
Undo. Redo. Undo again.

This week, I tried something different. I started with ChatGPT first then moving to Midjourney, a UI web library and putting it together with Cursor.

No Figma. No traditional design file.

Just prompts, components, and a browser tab.

The workflow felt natural. Faster. Lighter. Closer to how we think than how we design.

Here’s the full breakdown of how the website came together.

1. Planning with ChatGPT

Instead of wireframing, I started with a conversation.

“What’s the simplest way to build a clean landing page for my idea?”

Within seconds, I had:

• A rough site structure

• A narrative flow

• Suggested sections

• A content outline

• A quick list of supporting assets

This is where designers forget the real shift: AI is not replacing creativity, it’s removing the friction between the idea and the first draft.

Skipping Figma at this stage made everything faster. No frames. No rulers. No component hunting.

Just intent.

2. Generating the hero visuals with Midjourney

Next step: the aesthetic.

I asked Midjourney for a photorealistic vibe that matches the product.

Something that would make sense as a hero background.

Here’s the prompt:

Read more

Note: This reflection is mainly about how I prompt when I am prototyping or exploring ideas as a designer. It is not meant for full stack apps, BMAD methods, or agentic workflows. This is just what worked for me when I wanted to move fast, get something on screen, and iterate without overthinking architecture.

When I decided to build my Make prototype, I did the most natural thing any designer-turned-builder would do. I reached for a PRD. I wrote one that looked suspiciously similar to what PMs hand over in big teams, the kind filled with motivations, user stories, goals, expected outcomes, and a slightly dramatic paragraph about why this work matters. It felt right. Familiar. Safe.

Then I dropped it into Make (even with Gemini 3 Pro).

Make did not agree.

It read my PRD like a loose set of vibes and decided to assemble something completely different, the digital equivalent of a crooked IKEA shelf someone forced together at 3AM. At one point it built screens I never asked for, skipped things I did ask for, and even invented a “coach dashboard” that came out of nowhere. It was impressive in a slightly concerning way.

It was pure HALLÜCIN energy. A piece of furniture that technically stands, if you squint.

That was the moment I accepted the obvious truth. The PRD was not helping. It was too narrative. Too broad. Too philosophical. It was trying to describe the world instead of what needed to exist in the next 30 minutes.

So I deleted the whole thing.

I started over with the smallest possible description I could get away with. Something so simple it almost felt like cheating. This is exactly what I wrote:

Product description:
A Content Writer web app that helps you write customer responses, marketing copy for social media using botim's Tone of Voice.

Core feature:
- Show AI chat with 3 shortcut prompts
- Left panel navigation to show history of chats
- Header with botim logo

Requirements:
- Do not explain code
- Use latest Gemini 3 Pro model
- Keep it minimal, one page only for now

That was it.

And suddenly everything made sense.

Make behaved like a completely different person. It built exactly what I pictured, no more and no less. The hallucinations disappeared. The phantom features stopped. The imaginary architecture decisions went silent. I finally got the small thing I actually wanted, the version I could iterate on instead of the version I had to escape from.

Looking back, I am not sure why I expected a PRD to be a good starting point. It is something I am used to reading as a designer, not something I ever build from directly. A PRD is meant for alignment, justification, and context, not construction. I do not build Figma screens from PRDs either. I always start with one screen, one action, one thing the user sees. So why was I trying to make AI start from a complete narrative?

It makes more sense now. I work better when I collapse the problem into one step. Apparently AI works the same way.

There is something oddly comforting about that. Instead of trying to architect the universe in one prompt, I just let myself build the tiny version first and worry about the rest once something exists. It is the closest thing to flow I have had while building.

And honestly, the moment I stopped trying to make AI understand my entire thought process, everything became calmer. Simpler. Less dramatic.

No more HALLÜCIN shelves.

Just a small working app.

And a small win to build from.

If this is the new way I make things, I am fine with it.

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

We’re diving into the essential techniques that instantly improve how you build and test with Figma Make.

For paid subscribers only part of my Design and Build Playbook. This playbook is constantly being updated.

Alright, let’s dive in.

1. Preview Your Make App Like a Real App

Figma’s preview window is fine for quick checks, but not when you want to test an experience properly. Here’s the workflow that makes your prototype feel like an actual shipped app.

Step 1 — Publish your Make app

Publish your project to generate a live URL that reflects all your logic, state, and data integrations.

Step 2 — Open in Safari and add to Home Screen

1. Open your published URL in Safari

2. Tap Share → Add to Home Screen

3. Launch it from your home screen like a real app

4. Runs full screen without browser UI

Step 3 — Hide the status bar in your design

On Make, prompt:

Hide the status bar on the actual mobile device

If added to your home screen, the app opens in a clean, full-screen environment by default.

Now you’re ready for testing.

2. Use the Device Camera to Scan QR Code

Figma Make prototypes can access real device hardware, including the camera.

How to use it:

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