Vibe coding for designers: from design system to working code

Vibe coding for designers means describing interfaces to an AI coding tool and directing it until the working version matches the design. The tool writes the code. The designer sets the standard, judges every screen and decides when it is done.

Designers come to this with more than they think. You already work in systems, components and states, you know what good type and spacing look like, and you write briefs for a living. The hard part is not getting code. It is keeping the design quality when the code is written by a tool that is happy to produce the average of everything it has seen.

I have designed brands and interfaces since 2010, and today I build products with Claude Code as a tool in my hand. This guide covers why designers have an edge, what to build first, how to turn a design system into code, how to keep spacing, type, right-to-left layout and accessibility intact, how to work from Figma, how to review what the tool wrote, and when to bring in an engineer. For the basics of the method itself, start with what vibe coding is.

Why designers have an edge

A model can write a button in a second. It won't notice on its own that the button sits 3 pixels too low, that the Arabic label is a weight too heavy, or that the error message is written in a tone the brand would never use. Those calls are yours, and they are the difference between software that works and software that feels considered.

• Taste you can name. "Make it nicer" gets you a random change. "The line height on the Arabic body text is too tight, and the cards need 24 pixels between them, not 16" gets you the right one. Designers can name the problem precisely, and that is most of a good prompt.
• Systems thinking. You already build with styles, components and variants. That is how good front-end code is organised too.
• Typography and layout. Type scales, line length, grids and breakpoints are design decisions that code has to follow, not invent.
• States and edge cases. Empty, loading, error, disabled, very long content. Designers draw these. Tools often skip them unless asked.

Most of what you know already has a name in code:

What to build first

Start where you own the content and the risk is low.

1. Your portfolio. You know every project, you set the bar, and the site is a live sample of your judgement. My design portfolio guide covers what to put in it.
2. A landing page for a real product, event or service: one page, one action, real copy.
3. An interactive prototype. A click-through in a design tool cannot show how a search filter feels with two hundred real items, or how a form behaves when someone pastes a phone number with spaces. A coded prototype can, and it is a far better thing to test with users.
4. A small internal tool for your own studio: a brief intake form, a contrast checker for a brand palette, a quote calculator, a file-naming helper. Few users, all known, nothing sensitive.
5. Motion experiments. Transitions, scroll effects and small interactions you can tune by feel in the browser, which is often quicker than describing them to someone else.

What not to start with: anything with logins, payments or other people's personal data. Those come later, with help.

Turning a design system into code

The order matters: tokens, then components, then pages. Skip it and you get pages full of one-off values that drift apart within a week.

Tokens first

Design tokens are named values: colours, type sizes, spacing steps, corner radii, shadows, motion durations. Define them once in code, and let every component use the names, never the raw values.

There is now a shared format for this. In October 2025, the W3C's Design Tokens Community Group published the first stable version of its specification (2025.10), and its announcement names Figma, Penpot, Sketch and Tokens Studio among the tools that support it. In practice, a coding tool can turn your exported variables into a tokens file quickly, and you check the names and values against the design.

Two layers help. Primitive tokens are the raw palette (blue-600). Semantic tokens say what a value is for (color-action, color-text-muted). Components use only semantic tokens, which makes dark mode or a second brand a change in one file instead of a hunt through fifty.

Put the rule in the project's instructions file so the tool sees it every session: no raw colour or spacing values outside the tokens file.

Components next

Build the smallest pieces first (button, input, tag, card) and ask for a single page that shows every component in every variant and state, in both languages. Review that page like a sticker sheet before any real screen uses the components. A request might read:

"Build the Button component from the tokens file. Variants: primary, secondary, ghost. Sizes: small, medium, large. States: hover, keyboard focus, pressed, disabled, loading. Show every combination on a /styleguide page in Arabic and English. Use no raw colour values."

Then every state

Ask for each state by name. Tools handle the happy path well and often leave out keyboard focus, error messages, empty lists and loading. A checklist in your brief stops that: default, hover, focus, pressed, disabled, loading, error, empty, too long.

Keeping the design quality in code

Spacing

One scale, used everywhere. If you designed on 4, 8, 16, 24, 32 and 48, the code should contain only those. A stray 13px is a sign the tool improvised.

Type

Define the type scale as tokens, with line heights set per script: Arabic often needs more room between lines than Latin at the same size. Load only the font weights you use, because Arabic fonts can be heavy, and check how the fallback font looks while the real one loads.

Right to left

Set dir="rtl" on the page, not with CSS, and ask for logical properties (margin-inline-start, padding-inline-end) so one stylesheet serves both directions. Mirror the layout, not everything: arrows and progress flip, logos, photos and phone numbers don't. Then test mixed text, such as an English product name inside an Arabic sentence. I go deeper in Arabic RTL UI design.

Accessibility

The W3C's WCAG 2.2 gives clear targets. At level AA, normal text needs a contrast ratio of at least 4.5:1 against its background, and pointer targets should be at least 24 by 24 CSS pixels, with listed exceptions. Add a visible focus style, a label on every form field, a site you can use with the keyboard alone, and respect for the system setting that reduces motion. Ask the tool to check each one and show you how.

Real content

Give the tool your real text in both languages, real photos and realistic data: long names, empty fields, a product with no image. Placeholder text hides problems, and a tool with blank space to fill will invent claims you never made.

Working from Figma

Figma's help centre describes an MCP server that makes "variables, components, and layout data" from your files available to coding tools, and lists Claude Code, Cursor, VS Code and Codex among the supported editors. Its remote version connects to Figma's hosted server, and as I write in October 2026, the guide says it "is available on all seats and plans". Limits and pricing can change, so check the help centre before you count on it.

Whatever the connection, the file decides the result:

• Use components and variables, not detached copies and loose hex values. The tool can only reuse what the file says is reusable.
• Use auto layout, so the structure maps to flexbox and grid instead of fixed positions.
• Name your layers. "Frame 427" tells the tool nothing. "Pricing card / featured" tells it a lot.
• Design the states, not only the default screen.

Without a direct connection, screenshots work too. Claude Code accepts pasted images, and Anthropic's best-practices page suggests a simple loop: paste the design, ask for the implementation, then ask the tool to "take a screenshot of the result and compare it to the original" and fix the differences. If you are new to the tool itself, my Figma for beginners guide covers components and auto layout.

Reviewing what the tool wrote

You don't need to read every line, but a designer's review catches what tests miss.

• Side by side. Compare the build with the design at phone, tablet and desktop widths, in both languages.
• The system. Search the code for raw colour values and odd pixel numbers. Each one is a token the tool ignored.
• The states. Tab through the page with the keyboard. Trigger every error. Empty every list.
• The words. Look for invented copy, leftover placeholders and English strings in the Arabic version.
• The changes. Read the list of changed files after each step, and ask why for anything you didn't expect.
• The weight. Check image sizes and font files, and open the page on an ordinary phone.

For reading diffs, Git and permissions in Claude Code, see my guide to Claude Code for non-programmers.

From my work: a bilingual website

The SkillUp MENA website is a bilingual site in Arabic and English. On that project I lead the work, design the interface and build it, so the person who sets the design standard is also the one checking the code against it.

Holding both roles makes one thing obvious. The decisions that make a bilingual site feel designed (the type in each script, the spacing, the direction, the real content in each language) are design decisions. They have to be written down as tokens, components and rules the tool can follow, or they quietly disappear one prompt at a time.

The limits: when to bring in an engineer

Vibe coding gives designers a working version. Some parts need someone who can read and question the code.

• Security. Logins, roles and who can see which data. A login screen is not protection on its own.
• Personal data. Where it is stored, who can reach it, backups, and the data protection laws of your users' countries.
• Payments. Connect them by the provider's official documentation, and have the flow reviewed before real money moves.
• Scale. Many users at once, slow queries, uptime. Prototypes rarely meet this, products always do.
• Maintenance. Packages need updates and security fixes long after launch.

A simple rule: if a bug could cost someone money, expose their data or break their trust, get a developer's review before launch. That is not a failure of the method. It is part of doing it properly.

Conclusion

Designers are well placed for vibe coding because the hard part is judgement, and judgement is the job. Start with work you own, build tokens before components and components before pages, ask for every state, protect spacing, type, direction and accessibility, prepare your Figma file so the tool can read it, and review the build the way you would review a junior designer's work. Bring in an engineer where money, data or scale are involved.

If you want a product or website designed with this care and built properly, tell me about your project.