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 …

Read more

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.

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

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

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

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

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

So I did what every vibecoder does:

• ship fast

• add features

• keep momentum

Today:

• thousands of active users

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

Except retention was bad.

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

That’s when I stopped shipping and started thinking.

The mistake I made (classic vibecoder move)

I assumed:

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

Wrong.

What I actually needed was clarity before code.

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

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

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

I use it to:

Read more

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

This article is about what happens when you stop stitching.

The idea behind Superdesigner

Superdesigner is not a design tool.

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

Superdesigner is a reasoning layer that runs inside Cursor.

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

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

I hear this a lot.

And yes you can paste:

• your PRD

• some research

• screenshots

• analytics summaries

Into ChatGPT and get feedback.

But that’s not the same thing.

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

ChatGPT sees what you upload or paste.

Superdesigner sees:

• the actual PRD in Confluence

• the latest research in Notion

• the real Figma file

• the real analytics funnel

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

And when scope changes?

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

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

How Superdesigner actually works (honestly)

One important clarification.

Superdesigner does not magically think on its own.

What it does is very deliberate.

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

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

You just run the workflow.

That consistency is the product.

A real project walkthrough

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

Here’s the actual flow.

1. Connect the sources of truth

• PRD → Confluence (downloaded as Markdown)

• Research → Google Docs (downloaded as Markdown)

• Designs → Figma (via MCP)

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

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

2. Run the review

npm run review

Superdesigner:

• generates a design-review prompt

• hands it to Cursor’s AI agent

• produces a design-review.md

No prompting.
No guessing.
Same structure every time.

3. Read the output (this is the magic)

The generated design-review.md is not UI.

It’s a design review that calls out:

• missing states (empty, error, recovery)

• gaps between PRD and flows

• risky assumptions

• things that will come up in review

• things that should come up but usually don’t

This is what you read:

• before design review

• before handoff

• before launch

This file is the product.

Why Cursor matters

Cursor isn’t just an editor.

It’s an agent runtime.

Because Superdesigner runs inside Cursor:

• it understands the full project context

• it can re-run reviews as things change

• it can chain tools together via MCP

This is where things get interesting.

MCP is where this becomes powerful

Figma MCP

Superdesigner can:

• read Figma file structure

• understand flow coverage

• write high-confidence comments back to Figma

Not visual critique.
Not opinions.

Comments like:

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

• “What happens if the user fails eligibility?”

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

Analytics MCP (e.g. Amplitude)

Now add reality.

Superdesigner can reason like this:

• “This step is unclear in design”

• and analytics shows drop-off here

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

Why this is not a Figma plugin

Plugins are great for:

• generating UI

• manipulating canvas

• speeding up execution

Superdesigner is about:

• thinking

• seeing blind spots

• preventing design regret

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

Solving the blank canvas problem (what’s next)

One of the hardest moments in design is the start.

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

Superdesigner will evolve to support this cold start:

• connect to fundamental research

• read a rough PRD

• generate:

  • user flows

  • state outlines

  • screen structure (not UI)

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

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

What Superdesigner is (and isn’t)

It is:

• a second brain for designers

• a repeatable design review system

• a reasoning layer across tools

It is not:

• a UI generator

• a design replacement

• another dashboard

Why I’m building this in public

Because I’m already using it.

Before reviews.
Before handoff.
Before launch.

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

That’s the value.

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

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

If you’ve reviewed enough designs, you know the moment. The screens are polished. The flows look reasonable. The prototype “works.” And yet.. during review.. small things begin to surface. An edge ca…

Read more

I’ve been genuinely impressed with Google Gemini lately.

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

Including Reddit.

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

The Goal

I had two goals going into this:

1. Learn how to build a Figma plugin

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

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

So I decided to put Gemini to work.

The Prompt I Gave Gemini

Here’s the exact prompt I used:

Read more

And the trio that unlocked it for me is:

Design Tokens → Figma MCP → Cursor.

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

Design → Prompt → Build → Test.

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

Let’s break down exactly how I do it.

1. Start With a Clean Figma File

Here’s what we are going to build today:

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

Here’s the baseline checklist I follow:

• Auto Layout everywhere

• All colors, spacing, radii, typography = tokens

• Real variants, not duplicates

• Logical naming: Button / Primary / Large

• No ghost frames

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

Because whatever is in Figma… becomes your code.

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

This is where things get interesting.

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

• Tokens

• Components

• Variants

• Layer structure

• Metadata

Cursor can literally ask Figma:

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

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

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

3. Cursor Generates a Full Design System Folder

Before any UI is built, Cursor does something magical:

It creates a full folder like this:

design-system/
  tokens.json

Clean, typed, structured.

This is the part that feels like cheating:

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

Generated straight from Figma through MCP.

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

That’s where Cursor Rules come in.

Create a new rule under .cursor/rules

# Theme Rules

You are building a React Native Expo app.

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

4. Skip Prototyping — Go Straight to Building in Cursor

This is where the workflow becomes addictive.

Traditionally, you’d spend days:

• mapping flows,

• designing static screens,

• prototyping interactions,

• presenting it all,

• revising,

• re-presenting…

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

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

For example:

In my recent speed run, I built:

• Profile → QR Code navigation

• Plus → Close animated button

• 5 mini icons fading in sequentially

• Real touch interactions

• True mobile motion

• Zero manual code from me

Cursor built everything from my prompts + tokens

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

They’re real mobile interactions.

5. The Prompt That Drives Everything

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

Here’s my prompt:

Read more

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

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

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

No Figma. No traditional design file.

Just prompts, components, and a browser tab.

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

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

1. Planning with ChatGPT

Instead of wireframing, I started with a conversation.

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

Within seconds, I had:

• A rough site structure

• A narrative flow

• Suggested sections

• A content outline

• A quick list of supporting assets

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

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

Just intent.

2. Generating the hero visuals with Midjourney

Next step: the aesthetic.

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

Something that would make sense as a hero background.

Here’s the prompt:

Read more

Note: This reflection is mainly about how I prompt when I am prototyping or exploring ideas as a designer. It is not meant for full stack apps, BMAD methods, or agentic workflows. This is just what w…

Read more