Building a Custom Website from a Figma Design System

The Problem with AI-Generated Websites

You can spot an AI-generated website within seconds. The same sans-serif font. The same gradient hero section. The same card layout with rounded corners and drop shadows. These sites are technically functional, but they carry no identity. They look like everything else because they were built from the same defaults.

This is the natural consequence of using AI tools to generate a website without giving them anything specific to work from. The AI fills in the blanks with safe, generic choices. The result is a site that looks "professional" in the way stock photography looks professional. It communicates nothing about who you are or how you think.

The site you are reading right now was built with AI. But it does not look like an AI-generated site, because the AI was not guessing. It was reading from a design system I configured specifically for this brand. I started with Figma Make's component framework, then defined the brand layer on top of it: the exact colors, the font pairings, the spacing values that make Framepath look like Framepath. Every visual decision was intentional, defined once, and applied consistently across every page.

The design file should not describe what the code should look like. The design file should be what the code comes from.

The Approach: Design Tokens and Component Architecture

The foundation of this site is a design system in Figma Make, built around two concepts: design tokens and component-based architecture. Figma Make provides the component framework. I provided the brand: the specific colors, typography, and spacing that make this site look like Framepath Partners and nothing else.

Design tokens are the individual visual decisions that define a brand. Component architecture organizes those decisions into reusable building blocks. Together, they form a system where every element on the site traces back to a deliberate choice, not a default.

This matters because the difference between a site that feels custom and a site that feels templated is not the layout or the imagery. It is the consistency of hundreds of small decisions. The exact navy in the header. The weight of the body text. The radius on a button corner. When those decisions are made once and applied everywhere, the result feels cohesive. When they are made ad hoc, page by page, the result drifts.

What Design Tokens Are

For anyone who has not encountered the term, design tokens are the smallest decisions in a design system, given names and a single, central definition.

Every brand has these decisions, whether they are documented or not. The exact hex code for your primary color. The font family for headings versus body text. The amount of padding inside a button. The border radius on a card. These are the values that, collectively, make your brand look like your brand.

In most organizations, these values live in multiple places. The designer has them in a Figma file. The developer has a version in CSS. The brand guidelines PDF has yet another version. Over time, they drift. The blue in the header becomes slightly different from the blue on the marketing page because someone eyeballed a hex code instead of referencing the defined value.

Design tokens solve this by naming every value and storing it in one place. Instead of #0f1e35 appearing as a raw hex code in dozens of files, it becomes --woop-navy, defined once and referenced everywhere. Change the definition, and every reference updates. That is the core idea.

What the Figma Make Project Contains

The source of truth for this site is a Figma Make project called "Framepath-Design-System." It contains two layers: a component library and a brand theme.

The component library comes from Figma Make's framework. It provides the building blocks of a website: Header, Footer, HeroSection, FeatureCard, ArticleCard, Button, Section, and Container. Each component specifies its structure, properties, and layout behavior. These are not wireframes or mockups. They are functional definitions that describe how each piece of the site is constructed.

The brand theme is where my decisions live. It contains the design tokens expressed as CSS custom properties, each using a --woop- prefix:

• Colors: --woop-navy: #0f1e35, --woop-teal: #055960, along with the full Framepath brand palette
• Typography: Playfair Display for headings, DM Sans for body text, with specific weights defined for each context
• Spacing and structure: border radii, container widths, section padding, and responsive breakpoints

The component framework is Figma Make's. The brand decisions are mine. Every color, font pairing, and spacing value I chose for Framepath Partners is named and centralized in that project. Nothing is implicit. Nothing is stored in someone's head or scattered across a Slack thread.

Connecting Figma to Code via MCP

The Model Context Protocol (MCP) is what bridges Figma Make to Claude Code. MCP allows the AI development environment to read actual design definitions from the Figma file mechanically, not from screenshots or verbal descriptions. It reads the structured data: the token values, the component definitions, the layout specifications.

The workflow has three steps.

Two Layers of Specification

The design system defines the visual language, but a professional website needs more than correct colors and fonts. It needs accessible markup, consistent code patterns, and adherence to writing standards. That is where the second layer comes in.

A CLAUDE.md file sits alongside the design system as a development requirements layer. It specifies:

• Accessibility: WCAG 2.2 Level AAA compliance, including proper ARIA roles, keyboard navigation, focus management, and color contrast ratios
• Code standards: BEM naming convention for CSS classes (.header__logo, .btn--primary, .section--navy), external stylesheets for production code, semantic HTML structure
• Writing rules: tone, voice, and specific constraints down to the punctuation level (no em dashes, for example)
• Architecture: which CSS file is generated (never hand-edited) and which is hand-maintained for production extensions

The design system tells the AI what the site should look like. The requirements file tells it how the code should be engineered. Together, they produce output that is both visually correct and properly built. Neither layer alone would be sufficient.

Design Token Synchronization

The most important concept in this workflow is design token synchronization. The same variable names appear in Figma and in the generated CSS. When the Figma project defines --woop-teal: #055960, the CSS file contains that exact declaration. Every button, link, and accent color that references --woop-teal gets that value.

The practical implication: if I change the primary teal in the design system from #055960 to #066d75, regenerating the CSS produces a single-line change that propagates across every page. No find-and-replace across a codebase. No hunting for hardcoded hex values. One change in the source, one change in the output.

This is what "single source of truth" actually means in practice. Not a philosophical commitment to keeping things in sync. A mechanical connection where the design values and the code values are the same values, expressed in different formats. The site you are reading right now uses this exact token layer. The navy in this header, the teal in the links, the spacing between these paragraphs: all of it traces back to the Figma Make project.

Beyond the Website

A brand does not live on a website alone. The same design tokens and visual language that produced this site also generated LinkedIn banners for Framepath Partners. Same navy. Same teal. Same typography. Same intentional visual identity, applied to a completely different format and platform.

This is where the design system approach pays a compounding dividend. Every new touchpoint, whether it is a social media banner, a presentation template, or a PDF report, draws from the same source. The brand stays consistent not because someone remembers to check a style guide, but because every output traces back to the same set of defined tokens.

What This Changes About the Handoff

The traditional design-to-development workflow has a translation step in the middle. A designer creates a mockup. A developer interprets it, eyeballs the spacing, color-picks the values, and writes CSS that approximates the design. Details get lost. Inconsistencies accumulate. The gap between "what was designed" and "what shipped" grows wider with every page.

This workflow removes the translation step entirely. The design values are not interpreted by a person. They are read directly from the source and written into the code. The workflow does not approximate the spacing or guess the border radius. It reads --woop-radius: 0.5rem from the token definition and uses it everywhere the design system specifies it.

For organizations managing multiple brands, products, or properties, this pattern has real implications. A design team maintains the Figma source. The code reflects those decisions exactly. The conversation between design and development shifts from "did you get the right shade of blue?" to "should we change the shade of blue?" Only one of those conversations moves the product forward.

This is the translation layer pattern applied to design. The specialist interface between a designer's intent and production code has always been the handoff itself: the specifications, the redlines, the Slack threads asking "is that 16px or 20px padding?" Removing that translation layer does not eliminate the designer or the developer. It removes the friction between them.

Where This Goes from Here

This workflow is running in production today. The MCP connection already supports component-level updates: point it at a specific component in the Figma project, and it updates just the affected markup without regenerating the full site. That granularity is there now.

The natural extensions are about automation and guardrails.

• Automated triggers. A Figma webhook that fires on design changes and initiates a regeneration pipeline, with the updated code landing as a pull request for human review. The pieces exist: Figma supports webhooks, GitHub Actions can run Claude Code via the SDK, and the MCP connection handles the read. The engineering work is wiring them together.
• Version control pairing. Connecting Figma's branching and version history with git branches, so design changes and code changes move through the same review process. Figma already supports branches. The missing piece is the automated handshake between a Figma branch merge and a git pull request.
• Token validation. A script that reads every --woop-* custom property in the CSS and confirms it maps to a defined Figma token. This would catch drift before it reaches production, straightforward to build with the MCP server providing the Figma side of the comparison.

The trajectory is clear. The Figma file is not a picture of what the site should look like. It is the definition the site is built from. The gap between design intent and production output has closed, and the work from here is making that connection faster, more automated, and more precise.