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

I use it to set a vision, and I use it to improve what already ships, to move an activation number, a retention curve, or a drop-off that will not budge. Either way the value is the same. You get to feel the thing, not just describe it.

A real prototype shows the interaction, not only the screens. How you move between them, where a gesture lands, what happens in different states. That is what makes it useful in a design crit or review because those experiences are exactly where the edge cases show up.

That is where most of today’s prototyping tools stop short. They render the screens well. The part that matters most in review, how it actually feels to move through the product on a real device, is the part they cannot fully give you yet.

I have spent months evangelizing Figma Make. I built a reusable UI library on top of it so my generated screens matched our real components, and I have written more than one piece on getting accurate work out of it.

Sometime last year, iOS 26 shipped Liquid Glass. I kept prompting for that true native feel on mobile, and I kept getting something close but not quite real. The preview is a webview. It can look like an iOS app in a screenshot. It does not move like one on a phone.

That gap between looking native and being native is what this whole category is now racing to close. I have used the main tools on real projects. Every one of them is good at the job it was built for.

Here is where each is genuinely great, and where each one stops.

The comparison at a glance

These are the columns I actually weigh when I pick a prototyping tool. No tool here is bad. They are built for different jobs, and the table is about fit, not a scoreboard.

Native is the column I feel most on mobile. A webview can look identical to the real thing in a still. On a device, native gestures, haptics, and scroll physics are the difference you notice in the first two seconds.

Figma Make

Figma Make brought prompt-to-app into the tool I already live in. You describe an interface, it writes working code, and you iterate without leaving Figma. I built a reusable UI library on top of it so its output tracked our real design system, and for web and cross-platform concepts it is fast and genuinely good.

Where it stops for me is native mobile. The preview runs in a webview, so with iOS 26 Liquid Glass I could not get a true native feel no matter how I prompted. That is not a knock on the tool. Web output is the right call for a lot of what I make. It is just not the native iOS reference I want to hand an engineer.

Best for: Web and cross-platform concepts, and teams already standardized on Figma. It is still my default for those.

ProtoPie

ProtoPie is the most capable interaction tool I have used, and I have pushed it hard. At Grab I used it on a purpose-built vehicle project, simulating a driver dashboard, a rear passenger dashboard, and the passenger app, all wired together across devices with handoff sessions between them. Nothing else came close for that kind of work.

That is also the honest boundary. It is a canvas-and-timeline tool, and that multi-device, sensor-rich scenario is a once-in-a-blue-moon project. For everyday screen work it is more machinery than the job needs, and the result is a high-fidelity simulation rather than native code.

Best for: Complex, multi-device, sensor-driven interaction work where hand-authored control is the whole point.

Origami Studio

Origami Studio, from Meta, has a devoted following and a patch graph that can express real logic and animation. It produces convincing, high-fidelity results. I downloaded it ready to learn it.

I gave up. The learning curve was steep, the node canvas sits closer to engineering than design, and I could not justify the time to get fluent. That is a me decision, not a verdict on the tool. Designers who have invested in the patch model get a lot from it. I am not one of them.

Best for: Designers already fluent in the patch-graph model who want deep, hand-built control.

Prototo

Prototo is the one I built, for exactly the gap the others left me: native iOS fidelity, from a designer’s hands, without an engineer or learning React Native.

You describe a screen to your coding agent, Claude Code or Codex, and it renders as a real native iOS app. Real gestures, real haptics, Liquid Glass, actual scroll physics. There is no canvas and no IDE. The iOS Simulator is the canvas, the agent is the design tool, and you never open a file.

> add a native bottom tab bar with a blur background

It is native because it runs on the native runtime, not a webview. From installing Prototo Desktop a running prototype in the Simulator takes under 90 seconds, and you can publish a link anyone opens and runs natively on their own iPhone. It crossed 5,000 installs, 3,600 of them in the first week.

The honest boundary: Prototo is a prototyping tool, not a production build pipeline. You get prototypes you test, share, and hand off.

Best for: Product designers who want native iOS prototypes from a prompt, with no canvas, no IDE, and no waiting on an engineer.

The Play-shaped gap

Before Prototo, the closest thing to native fidelity without engineering was Play. Designers built with real SwiftUI components, and it won a 2025 Apple Design Award. I downloaded it too. Same wall as Origami, too technical for my liking, and I gave up before I got anywhere.

In 2026 Apple acquired the team, and Play wound down, with support ending in April. Designers who wanted native fidelity without the engineering are now looking for where to go next. Prototo answers that with a prompt-native workflow instead of a canvas to learn.

So which one

1. Native iOS prototypes from a prompt, no canvas, no IDE → Prototo.

2. Web concepts, fast, inside Figma → Figma Make.

3. Deep, multi-device interaction design → ProtoPie.

4. Patch-graph control you have already invested in → Origami Studio.

Every tool here is good at the job it was built for and I still reach for most of them.

CLAUDE.md tells your agent how you work. DESIGN.md tells it how things look. I used to stop at those two.

Start a real project and you find that two files are not the system. You also need what you are building, who it is for, how it should sound, what to do next, and where you left off last time. Five more markdown files cover that. A sixth handles the case that tripped me up when I was building Prototo... more than one repo.

The order matters more than you would expect because some of these files read the others. Here they are, in the order you write them.

1. PLAN.md, what you are building

Before you install a single plugin, write down what you are building. Not for the agent yet. For the two files that come right after it.

PLAN.md is the shape of the project before any code. What you are building, who it is for, the core flows, what is in scope and what you are deliberately not building, the constraints. Keep it short enough to read in a minute and honest about the non-goals. The non-goals save you more time than the goals do.

Here is why it goes first, and this part surprised me. When you install the brand and voice plugins and run them, they do not only ask you questions. They read your project folder to ask the right ones. Give them a PLAN.md and the interview is about your actual product. Give them an empty folder and they have nothing to go on but the folder name. I tested it: on an empty folder, the brand it wrote was a guess off the folder name. With a PLAN.md sitting there, the questions got sharp and the output was about my real thing. So the plan is not only for you. It is the foundation the next two files grow from.

2. BRAND.md, who you are

Ask an agent to name a feature and it picks a personality. Ask for a button label and it picks a voice. None of it is wrong, it is only not yours, and it drifts a little further every session. The agent has no idea who the product is for.

BRAND.md is who you are. Audience, personality, the promise, the character. It is the root the words and the design both read from, so they trace back to the same place instead of each one guessing on its own.

I do not hand-write it. The brand plugin runs /brand. It probes you with a good brand designer’s questions, and because it reads what is already in your folder, this is where PLAN.md pays off: with the plan there, the interview is about your real product, not the folder name. Then it writes BRAND.md from your answers.

Here is the part that made me smile the first time. It even draws you a logo. A clean monoline SVG mark, built from the personality it just captured, the kind of thing you would open a design tool for. Then it seeds VOICE.md and DESIGN.md from the same brand, so the words and the look start from who you are.

Open your new project folder:

claude
/plugin marketplace add sherizan/designagent
/plugin install brand@designagent

3. VOICE.md, how you sound

DESIGN.md covers the pixels. It says nothing about the words, which is where AI gives itself away fastest. The em dashes. The hype. The hedging. The copy that reads like every other product.

VOICE.md is how you talk: your personality, your banned words, your punctuation, with examples the agent can match against. Because the plan and the brand came first, the voice starts from who you are, not from scratch. The voice plugin writes it with /voice, then /proofread enforces it on any copy you point at. It strips the AI tells and leaves the substance alone. It will not touch an install command, an id, a tool name, a version, or a line of code.

I run the same rules on this newsletter that VOICE.md enforces in my projects, so I am not selling you a discipline I skip myself.

In the same project folder:

/plugin marketplace add sherizan/designagent
/plugin install voice@designagent

4. BACKLOG.md, what to build next

PLAN.md is the what and the why. It does not tell the agent what to do right now. Without a backlog it starts every session by asking you, or worse, it picks something itself and you find out after.

BACKLOG.md is PLAN.md broken into an ordered queue. Top of the file is the next thing. A “Now” for this session, a “Next” that is ranked, a “Later” you do not have to think about yet, and a short “Done” so the agent has recent context and does not rebuild something you already shipped. The plan is stable, the backlog changes every session. Keeping them in separate files is what lets one hold still while the other moves.

The point is that priority lives in a file the agent reads, not in your head. You stop being the queue.

"Build the next item in @BACKLOG.md that's highest priority"

One honest limit. BACKLOG.md works while the queue fits on one screen and it is basically you. The day it outgrows that, or a second person needs it, or items start needing an owner and a link to the actual work, move it to GitHub Issues and a project board. You do not lose the agent when you do. Claude Code reads issues through the GitHub connection, so you point CLAUDE.md at the repo and it still pulls the queue. This file is the training wheels. GitHub is where the backlog grows up.

5. SESSIONS.md, where you left off

Here is the thing nobody warns you about. Close the chat, come back the next morning, and the AI remembers none of it. Not what you built, not what you left half done, not the thing you were waiting on. It is a brand new assistant every day, and you are the only one who remembers yesterday.

SESSIONS.md is where I write yesterday down. It is a running note of where things stand, and I read it first every time I sit back down. Three simple parts: what I am waiting on, the handful of facts I keep having to explain again, and a short dated log of what happened with the newest bit on top. Two lines at the end of a session, and the next one starts already knowing the story.

Of all six files, this is the one I would keep if I could only keep one. A brand can wait a day. Starting from zero every single morning cannot.

"Before we wrap up for the day, sum up what we did to @SESSIONS.md"

Advanced: CONTRACT.md, when the project spans more than one repo

Everything above lives in one project folder. The day it grows a second one, things break in a new way. My prototo app is split across a few repos: the desktop app, the website, and a shared core. Change a link format in one and forget to tell the other, and the join between them snaps. Two AIs working in two folders, neither one watching the other.

So the contract does not live inside either app. It gets its own small repo. Mine is called “{projectname}-shared”, and it holds one file that lists everything the repos have to agree on: the link shapes, the shared settings, the version numbers that must move together, and who owns each one. Every repo’s CLAUDE.md pulls in that one file, so every session in every repo loads the same source of truth without me thinking about it. There is even a small script that checks all the repos against the contract and tells me the moment one has drifted.

The rule is simple. Change the contract first, then change the code on either side, never the other way around. Skip this file until you have a second repo. The day you add one, write the contract before the agent decides the join for you.

How the files stack

Read in order, it is one system. PLAN.md is what you are building, and it goes first so the brand and voice plugins have something real to read. BRAND.md decides who you are. VOICE.md keeps the words on brand. DESIGN.md keeps the interface on system. BACKLOG.md is what to do next, and SESSIONS.md is what happened last. CONTRACT.md holds the line between repos when there is more than one.

Which leaves CLAUDE.md, and this is the part I had wrong.

EDIT: CLAUDE.md is the index

My first instinct was to @import all six files into CLAUDE.md so the agent always had everything. It works, and it is wasteful. Every session opens by loading a brand you are not questioning, a contract for repos you are not touching, and a backlog you already know, and the context you wanted for the actual work is spent before you type anything.

An index is smaller. CLAUDE.md says what each file is and when to read it, and the agent goes and gets the one it needs. Two are worth loading every session: SESSIONS.md, because where you left off is always relevant, and PLAN.md, because the goal is always relevant. The rest are pointers. Writing copy, it opens VOICE.md. Touching the interface, DESIGN.md. Second repo, CONTRACT.md. The agent decides in the moment, because the index told it what exists.

The term for this is progressive disclosure, and you already know it from the design side. A design system doc does not open with every component on one page. It gives you a contents list and you open the page you need. Same move here, pointed at an agent instead of a designer.

Credit to Cristian Achiardi for calling this out my first version.

The test is easy to run. If CLAUDE.md is long enough that you skim it, the agent is skimming it too.

You write it down once in files the agent reads when they matter, and let it check its own work against them.

How to make all six (paste these into Claude Code):

If you’re running these, make sure you have Plan Mode activated.

BRAND.md and VOICE.md run from the plugins:

/plugin marketplace add sherizan/designagent
/plugin install brand@designagent
/plugin install voice@designagent

/brand      # interviews you -> BRAND.md + a logo, seeds voice + design
/voice      # writes VOICE.md

Read more

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

Why Claude, and not Figma’s AI

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

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

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

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

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

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

What “two-way” actually means

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

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

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

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

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

1. Install the bridge

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

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

The Claude Code side installs from the marketplace:

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

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

2. Turn the bridge on

1. Open the DesignAgent plugin in Figma.

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

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

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

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

3. The prompt pack I run

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

Extract the tokens to DESIGN.md

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

Create a design system from a logo

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

Build the first set of UI components

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

Design a landing page with the UI components

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

Write the screen copy in your voice

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

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

Create a social asset from your branding

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

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

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

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

My Takeaway

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

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

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

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

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

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

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

You have the basics wired. The Figma MCP, a Context7 docs server, Github MCP, the usual starter setup. That is a good floor.

Read more

The most useful design review I ran at Botim in these past months, I did not run. An agent did.

We were shipping a money transfer flow. The confirmation screen showed the amount one way and the entry screen showed it another, just different formatting, the kind of thing you stop seeing after the fortieth look. Research had already told us users lose confidence when the number looks different at confirmation. The agent caught it in one pass, tied it to that research, and flagged the “Send now” button against our own rule for irreversible actions. It suggested “Send AED 250. This cannot be undone.”

That is the production version: five agents, the real superdesigner. This piece is the stripped-down one you run yourself in Claude Code.

Here is the part nobody tells you. I lead design for a product with 150 million users, and the first week I tried Claude Code I opened the terminal, looked at it, and closed it. The capability was right there. The setup was the wall.

Nobody hands a designer the other side of that wall. So here it is, the whole thing: the setup I run, every MCP, the Skills that hold my taste, and the four workflows on top. This is design knowledge work, research synthesis, competitor analysis, design systems, specs, and prototypes you think with. Not for shipping to production, and you do not need to code. You point it at the thinking, not the deploy button.

I also build apps that four people use. The day job and the side project taught me the same thing.. the tool stopped being the bottleneck a while ago, the setup is it. Once Claude Code knows your taste and your stack, it stops improvising and starts building the thing you would have built yourself.

What is in here

The foundation, six pieces, in order:

• The CLI, configured so the terminal stops being the scary part.

• A CLAUDE.md that holds your taste, so it builds like you, not a generic template.

• A DESIGN.md it reads as law, so “good” means your standard.

• Permissions, so it moves fast without doing something you did not ask for.

• The MCPs that wire it to Figma, live docs, and a real browser to check its own work.

• The Skills that turn the moves you repeat into something it runs on its own.

Then the four workflows on top, none of which need a line of production code:

• Keep your design system honest. Audit it against your own rules, catch the drift, sync tokens.

• A prototype you think with. A written flow becomes something clickable that the agent opens, checks, and corrects itself.

• Research synthesis. Raw notes in, the themes and contradictions out, every claim cited.

• Pressure-test a spec. The states and edge cases a PRD misses, found before a single screen exists.

Honest caveat: this is a setup you maintain. It will confidently build the wrong thing if your CLAUDE.md is vague, so the rules carry the weight. It does not replace your judgment. It clears the distance between your judgment and the screen.

The whole thing is below for paid members: the setup, every MCP, the Skills, and the four workflows with the exact prompt I run. It is the same pattern behind superdesigner.ai, the reviewer design teams at OKX and Grab use, stripped to what you need for your own work.

Read more

It started with a real problem at work.

We had a major product change coming. Key UX flows moving, new UI, brand changes. The kind of thing you cannot judge from a Figma canvas. I needed to feel it. Real gestures, real scroll, the way it actually behaves in your hand.

Figma surfing wasn’t going to tell me that. Figma Make is good, and I use it, but it renders the web and I needed to feel native. Xcode would get me there and lose every designer on my team on the way. I’d been dabbling with Expo on personal apps, so I knew native was reachable. It just wasn’t reachable for a designer who didn’t want to live in an engineering setup.

So I asked a simple question. What if I strip Expo down to the basics, point Claude Code at the folder from a terminal, and just let it run?

A couple of hours later, it worked

After an afternoon poking at Expo with Claude, I had it.

One command opens the iOS Simulator with a welcome screen, ready to prototype. Under 60 seconds and you have a live, real, native prototype running in front of you. As far as I can tell, it’s the first tool that does this.

npm create proto@latest myapp

Then the fun part. You open a new terminal, open Claude Code in the project and start prompting. The screens come to life as you type, thanks to Expo’s hot reload. No canvas. No IDE. You describe what you want and it appears in the Simulator.

cd myapp
claude

Then connect the Figma MCP to Claude and you can build your actual designs straight into the prototype. That’s the moment it clicked for me. Within hours, the product we’d designed was running as a live native prototype I could hold and feel.

I sent it to a few friends to see if it would break

That was the real test. Hand it to other designers and watch what happens.

They got hooked. They started sending me videos of their own prototypes running. That’s when I knew it wasn’t just solving my problem.

npmjs now shows around 2,600 weekly downloads. Turns out a lot of folks needed this more than I thought.

Where it sits next to the tools you already use

Every tool here is good at its job. The point is that one specific combination didn’t exist yet: designer-friendly, genuinely native, prompt-only, no IDE, no canvas.

A few comparisons:

Figma Make is designer-friendly and needs no IDE. It renders a webview, so native feel isn’t its job.

ProtoPie is great for rich interaction design, but it isn’t native and isn’t prompt-driven.

Origami Studio can get genuinely native, but it’s a steep canvas-and-patch tool, not a prompt one.

Expo and SwiftUI are as native as it gets. Both are built for engineers, not designers.

Prototo is the one that’s all five at once. That’s the gap it fills, and it’s the only reason it exists.

What’s honest about where it is today

The core works now. One command, the Simulator opening itself, prompting through Claude Code, Figma MCP, hot reload. That’s live today.

It’s a prototyping tool, not a production one. It generates prototypes you test, share, and hand off. Though the handoff is cleaner than usual, since the project itself reads like a spec.

And it’s native only by design. That’s a deliberate constraint, not an oversight.

Try it this week

If you’ve got a flow you can’t judge from the canvas, the kind you need to feel, give it 60 seconds.

npm create proto@latest myapp

Then cd myapp, run claude, and ask for a screen. Watch it come to life.

Learn more at prototo.app, read the docs at docs.prototo.app, and the full demo is on YouTube above.

Sherizan is Chief of Design at Botim, MENA’s fastest-growing super app. Previously Global Design Leader at TikTok and Senior Principal Designer at Grab, where he led the GrabPay redesign. He writes the Design AI Stack newsletter and builds in public.

This is the mobile version of my prompt library.

The web app playbook covered Next.js. This one covers Expo. Same approach, different output. A real app that runs on iOS and Android.

In case you missed the web app playbook:

Before you start: software you need

Create accounts and install these first. They’re all free to sign up.

• Node.js LTS. The engine that runs your app locally. Without it, nothing works. Download at nodejs.org (choose the Installer for your system, Mac or Windows).

• Expo Go. The app that shows your work on your actual phone while you build. Download it on your iPhone or Android from the App Store or Google Play. Free.

• Firebase. Your database and login system. Create a free account at firebase.google.com. No card required on the free plan.

• Claude. Paid subscription required for Claude Code. Make sure you’re on a paid plan at claude.ai before you start.

A note if you’re on a work laptop: you may need admin rights to install software.

Read more

I run jfbi.ai, an AI Builder Sprint days with designers, founders, builders in a room. We hand everyone a stack and a set of prompts. By end of day, most people have shipped something real.

This is that prompt library I’m sharing with you.

Before you start: software you need

• Node.js LTS. The engine that runs your app locally. Without it, nothing works. Download at nodejs.org (choose the Installer for your system, Mac or Windows).

A note if you’re on a work laptop: you may need admin rights to install software.

The stack

• Cursor. Where you write and see your code. Think of it as a smart text editor, like Figma but for building.

• Claude Code. Your AI building partner. Lives inside Cursor’s terminal. Paid subscription required.

• Next.js. The framework that powers your app.

• Tailwind and Shadcn UI. Handles how everything looks.

• Supabase. Your database, if you need to store data.

• Vercel. Puts your app on the internet in minutes.

• GitHub. Saves your work and tracks every change you make.

Read more

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

Hours. Every time. Last week that stopped.

What I tried

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

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

Then I prompted:

That’s it. One line.

What actually happened

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

Then I noticed something off.

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

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

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

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

I didn’t touch a thing.

Why this matters

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

The unlock is that the stitching is gone.

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

Now the stack does it:

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

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

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

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

Where this gets really good

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

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

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

Chef’s kiss when it runs clean.

Want the /mobbin Claude skill?

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

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

Read more

Last week, two things shipped four days apart.

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

Both touched design systems. Both promised to make AI agents 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.

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