How to Use Claude and Figma MCP for Designing Beautiful Software

One of the most useful demos I've seen in a mastermind call in a while came from a founder who screen-shared his entire product's design system, built almost entirely through Claude connected to Figma's MCP server. He's not a designer. He said it himself: he just likes pretty things and knows what looks right when he sees it. What he'd built in under a week looked like the output of a small design team working for a month.

What Figma MCP actually changes

For years, the standard advice for non-designer founders was to hire a designer, live in Figma yourself, or accept a website that looked like a template. Model Context Protocol changed the equation because it lets Claude read and write directly into Figma rather than just generating static mockups you have to manually rebuild. The founder on our call put it simply: he used to dislike Figma. Now that there's a proper MCP connection into it, he does almost everything through it, and he's barely inside the actual Figma interface himself.

His workflow starts with Claude Code, not Figma. He'll describe what he needs, a dashboard, a new landing page, a settings screen, and Claude builds it directly connected to the MCP. From there he can ask Claude to think through the whole design system: colors, card and surface styles, navigation patterns, and the kind of edge cases he wouldn't have thought to spec himself. His example was a brand kit toggle for users who wanted a dark font paired with a light background color. He never asked for that specifically. Claude proposed it as part of thinking through the full range of how the feature could be used.

• Describe outcomes, not pixels. Tell Claude what page or feature you need in plain language and let it propose the structure.
• Ask for the system, not just the screen. Prompting for the whole design system up front produces far more consistent results than asking page by page.
• Let it surprise you with edge cases. Claude will often propose states and toggles you hadn't considered, like the light and dark font example.
• Stay connected through MCP, not exports. Live read and write access into Figma beats generating static mockups you then have to rebuild by hand.

Ninety percent is genuinely achievable

His estimate, and it matches what I've seen elsewhere, is that AI gets you about ninety percent of the way to a finished design on its own. The other ten percent is where it sometimes does something strange, a layout that technically works but doesn't quite make sense, and you have to nudge it back. That last stretch is exactly where he said Figma earns its place in the stack even in an AI-first workflow. Adjusting small details directly in Figma is faster than re-prompting Claude and hoping it doesn't disturb something else on the page. He also names every layer and component deliberately as he builds, which means when his engineers point an AI agent at the Figma file to generate the actual code, everything is already organized into a structure their tools can parse cleanly.

• Start in Claude, not Figma. Describe the page or feature you need in plain language and let Claude build the first version connected through MCP.
• Ask it to think in systems, not pages. Prompt for the full design system, colors, surfaces, spacing, navigation, so new pages inherit consistency automatically.
• Expect to fix the last ten percent by hand. Use Figma for the small adjustments that are faster to click than to re-prompt.
• Name everything on the way in. Deliberate layer and component naming in Figma means your engineering team's own AI agents can parse the file cleanly later.

From high-level taste to a finished product

What struck me most about the demo wasn't the technical setup, it was how little direction he actually gave. He described his process as pulling from a handful of websites he liked, landing on details that stood out to him (a specific color he loved, an illustration style with a certain energy to it), and feeding those impressions to Claude as loose, high-level ideas rather than a formal spec. He compared it to briefing an architect on a house you want built: you describe the feeling you're after, not the blueprint. Even the product's logo came out of that same loop, several rounds of Claude generating concepts based on a rough idea until one clicked.

That's a genuinely different way of working than the traditional design brief, and it's worth naming clearly for anyone who assumes AI-assisted design still requires detailed specifications up front. It doesn't. It requires taste, patience for a few rounds of iteration, and a willingness to say "that's close, but not quite" as many times as it takes.

• Collect references before you prompt. Spend an hour or two pulling colors, layouts, and details you genuinely like from sites you admire.
• Describe the feeling, not the spec. Brief Claude the way you'd brief an architect on a house: the impression you want, not a blueprint.
• Expect iteration, not a single perfect draft. Even a logo can take several rounds of Claude proposing concepts before one clicks.
• Trust your taste to do the filtering. You don't need design training to recognize when something is close but not quite right.

Programmatic design at scale

The workflow gets more interesting once you move past a handful of hero pages into the long tail every SaaS product eventually needs. His product has over a thousand potential integration pages, and building each one by hand would take a designer months. Instead, he designed one integration page deeply, thinking through the layout, the messaging, the visual pattern, and then used that single page as the template Claude replicates across the rest. Because his marketing website and his production app live in the same codebase, Claude can pull real information about how a given integration actually works and generate an accurate page automatically, rather than a generic template with a logo swapped in.

That's the same growth strategy Zapier used to become one of the most visited SaaS sites on the internet: thousands of individually accurate integration pages, each one capturing long-tail search intent nobody would bother targeting by hand. The difference now is that a solo founder can execute that strategy over a weekend instead of staffing a content and design team to do it over a year.

• Design the template once, deeply. Put real thinking into the first page of a type before letting Claude replicate it.
• Connect your marketing site to real product data. Shared codebases let Claude generate accurate pages instead of generic ones with a logo swapped in.
• Look for the long tail in your own product. Integrations, use cases, and pairings are the same programmatic SEO pattern Zapier used to grow.
• Let scale be the payoff, not the effort. Once the template and data pipeline are right, the hundredth page costs almost nothing extra.

From Figma straight into the live page

The loop doesn't stop once a page exists in Figma. When he builds a new landing page for a specific use case, whether it's a niche audience like team celebrations or something more general, Claude generates the mockup inside Figma through the MCP connection, and from there he takes a screenshot and drops it straight into the live website build. He described barely touching Figma directly during this process himself. The tool sits in the middle of the workflow as a structured intermediate format, something both Claude and his human designer can read, rather than the place where the actual design decisions get made by hand. That's a meaningfully different role for Figma than it played five years ago, when it was the primary canvas rather than a checkpoint in an AI-driven pipeline.

• Treat Figma as a checkpoint, not a canvas. Let Claude generate the first pass through MCP, and use Figma mainly to review, adjust, and hand off.
• Build one page deeply before you template it. Invest real thinking time in the first version of a page type, since everything after it inherits that decision.
• Reuse real product data in marketing pages. If your website and app share a codebase, let Claude pull actual product behavior into the page instead of writing generic copy.
• Let curiosity drive the edge cases. Ask Claude to think through scenarios you haven't considered, like accessibility toggles or alternate color modes, rather than only building what you explicitly specify.

A follow-up question worth asking yourself

Another member on the call asked a sharp follow-up question once the demo wrapped: if Claude can build a full design system and generate pages on its own, why keep Figma in the loop at all? The answer the founder gave was refreshingly practical rather than dogmatic. Claude Design is genuinely difficult to nudge on small details. Asking it to adjust a ten-pixel margin or swap a shade of a color often means re-prompting and hoping the model doesn't quietly change something else nearby that you didn't ask it to touch. Making that same adjustment directly inside Figma takes seconds and carries none of that risk. Figma also supports real-time collaboration in a way that generating pages through an AI coding tool simply doesn't yet, which matters the moment more than one person needs to be involved in a design decision.

That's a useful mental model for anyone deciding how to structure their own stack. Use Claude and Figma MCP for the parts of the job that are genuinely generative, coming up with structure, layout, and a first pass at the full system. Keep a real design tool in the loop for the parts of the job that are about precision and collaboration. Treating this as an either-or choice, AI replaces Figma entirely or Figma stays exactly as it was, misses how these founders are actually working day to day.

• Use AI for generation. Structure, layout, and a full first pass at the system are where Claude helps the most.
• Use Figma for precision. Small adjustments are faster and safer to make directly than to re-prompt.
• Use Figma for collaboration. Real-time editing with a designer or teammate still isn't something an AI coding tool replicates well.
• Pick the tool by the job, not by habit. The best workflow mixes both deliberately instead of defaulting to whichever one you're more comfortable with.

Where the human still has to show up

None of this means Figma is obsolete or that a founder can fully check out of the design process. What's changed is where the human effort goes. Instead of spending hours pushing pixels or waiting on a designer's queue, the founder's real job becomes curation: picking the right references, recognizing when Claude's output is close but not quite right, and making the small manual corrections that a model still can't reliably get on its own.

If you've been putting off a redesign because you don't have design resources, this is probably the moment to try wiring Claude into Figma MCP and see how far you get before you need to touch a single layer yourself. Start with one page type, push it further than feels natural, and let the pattern you land on become the template for everything that follows.

• Start with one page, not the whole site. Prove the workflow on a single page type before you template it across the product.
• Push past the first acceptable answer. Keep asking Claude to think through edge cases instead of stopping at the first version that looks fine.
• Reserve your time for curation. Spend your effort choosing references and catching the small misses, not pushing pixels.
• Let the pattern become the template. Once one page type feels right, replicate it rather than redesigning from scratch each time.