Automating Web Design: The Role of AI in Creative Processes
AI design tools now generate a layout, not just a mockup: v0 turns a prompt into a styled Next.js page, Figma Make turns a design file into an interactive prototype using the same variables and components the design team already built. The risk that moved with that speed is accessibility, since a generated layout that looks correct can still fail keyboard navigation or contrast requirements nobody checked.
This is the design-process question, not the code-ownership question
Neither tool works by magic. Both are pattern-matching against the training data and, where available, the existing project context they're given, which is exactly why what a team feeds them, a design token set, an existing component library, matters as much as the prompt itself.
A separate post, Design Without Limits: How AI and No-Code Tools Are Reshaping UI Development, covers what happens after generation: who reviews the code, where it should sit in a Git workflow, and the OWASP-documented security risks of low-code output. This post is about the step before that: how these tools actually generate a layout, what a design token is doing in that pipeline, and where accessibility risk enters before a single line of code gets reviewed.
How layout generation actually works today
v0: a prompt becomes a styled, structured page
v0 turns a natural-language description into a Next.js and React project styled with Tailwind CSS and shadcn/ui components, running the live preview in an isolated sandbox with real routing and data connections, per Vercel's own documentation (v0 by Vercel — Quickstart). The layout decisions, spacing, component choice, responsive breakpoints, come from the model's training on existing component patterns, not from a design system the team already owns, unless that system is explicitly provided.
Figma Make: generation inside the design tool itself
Figma Make takes an existing Figma design, a component, or a plain-language prompt and produces a working, interactive prototype inside the same tool a design team already uses for static mockups, according to Figma's own documentation (Figma Learn — Explore Figma Make). Because it runs inside Figma, it has a structural advantage v0 doesn't: direct access to the file's existing variables and components, if the design system has them defined.
Builder.io's approach: generation constrained to an existing structure
A third tool worth naming for contrast: Builder.io's visual editor connects to an existing, engineer-owned codebase rather than generating a standalone one, letting a non-engineering team edit real sections while structured content stays available to the application through its API, according to Builder's own documentation on how the platform works (Builder.io Docs — How Builder Works). Because it edits inside a defined structure rather than generating one freely, it has a narrower but more predictable layout-generation surface than v0 or Figma Make.
That trade-off, less generative freedom in exchange for guaranteed structural consistency, is worth naming explicitly when choosing a tool: the more freedom a generation tool has, the more that design tokens and a review gate have to do the work of keeping the output consistent.
Design tokens are the seam that determines output quality
A design token is a named, reusable design decision, a color, a spacing value, a type scale step, stored once and referenced everywhere instead of hardcoded per component. Figma's own variables documentation describes these as reusable values applied across design properties and prototyping actions, explicitly built to keep a design system consistent as it scales (Figma Learn — Guide to variables in Figma).
The W3C-affiliated Design Tokens Community Group reached a first stable specification version in October 2025, defining a vendor-neutral file format so a token set can move between Figma, code, and other design tools without a manual re-translation step at each handoff (W3C Design Tokens Community Group — Design Tokens specification reaches first stable version).
An AI tool pointed at an undefined design system generates its own defaults. An AI tool pointed at a token set that actually exists generates output that's consistent with the brand by construction, not by luck. That's the entire argument for setting up tokens before adopting generation tools, not after.
What happens without tokens in place
Without a token set to reference, a generation tool invents spacing, color, and type values that look plausible in isolation and drift from the existing design system in aggregate. A handful of generated components each 90% aligned with the brand compounds into a design system that's quietly inconsistent everywhere, without any single component looking wrong on its own.
A generation tool that can't see your design tokens will still generate a layout. It just won't generate one that looks like it belongs on your site, and that gap is invisible to the model itself.
Accessibility risk enters before the code review stage
The review-gate problem for AI-generated code, checking auth, dependencies, and licensing, is well covered elsewhere. The design-process-specific risk is narrower and easier to miss: a generated layout can be visually correct and structurally inaccessible at the same time, because visual correctness and WCAG conformance are checked by two different processes.
The Web Content Accessibility Guidelines define specific, testable success criteria for contrast, keyboard operability, and focus order, and none of them are verifiable by looking at a rendered screenshot (W3C — WCAG 2.2). A generated component can render pixel-perfect and still fail every one of these checks.
Automated tooling closes part of the gap, not all of it
Running axe-core, an open-source accessibility testing engine used across millions of projects, against generated output catches a meaningful share of WCAG violations automatically, contrast failures, missing labels, invalid ARIA usage, without requiring a manual audit of every component (GitHub — dequelabs/axe-core). It does not catch everything: keyboard focus order and the logical sense of a screen reader's reading order both still need a human pass.
Comparing where each risk actually shows up
| Risk | Caught by a visual review | Caught by axe-core | Needs a manual check |
|---|---|---|---|
| Off-brand spacing or color | Sometimes, if the reviewer knows the system well | No | Design-token diff against the source system |
| Missing alt text or form labels | No | Yes | No, automated coverage is reliable here |
| Contrast ratio failures | No | Yes | No |
| Keyboard focus order | No | Partial | Yes, tab through the component manually |
| Screen reader reading order | No | No | Yes, always a manual check |
The generation pipeline that actually protects the design system
Tokens shape what the model generates; the accessibility gate decides what actually ships. Skipping either step is where design-system drift and WCAG failures both originate.
Prompting for layout is a different skill than prompting for copy
A prompt that produces good marketing copy from a language model doesn't automatically produce a good layout, because layout generation is constrained by more than word choice: spacing scale, breakpoint behavior, and component reuse all have to come from somewhere. When a token set exists, the most reliable prompts name it directly, referencing existing component and variable names rather than describing a look in prose.
A prompt like "use the existing Card component and the spacing-4 token for internal padding" gives the model something concrete to anchor to. A prompt like "make it feel clean and modern" gives it nothing but its own defaults, which is exactly the scenario that produces design-system drift.
Iteration inside the tool versus iteration in code
Both v0 and Figma Make support conversational refinement, adjusting the generated output through follow-up prompts rather than starting over. That's genuinely useful for early layout exploration, but it has a ceiling: once a generated component needs a change that depends on understanding existing application state or business logic, refining through the chat interface stops being faster than a developer editing the code directly.
Recognizing that ceiling early, and moving to direct code edits at that point rather than continuing to iterate through prompts, is part of what separates teams that get consistent value from these tools from teams that fight the prompt interface past its useful range.
A checklist before a generated layout reaches production
- Confirm the generation tool was pointed at the actual design token set, not left to invent its own values.
- Run the output through axe-core or an equivalent automated accessibility scanner before any human visual review.
- Tab through every interactive element manually to confirm focus order matches the visual and logical order of the page.
- Check color and non-text contrast against WCAG 2.2's success criteria, not against how it looks at a glance.
- Diff the generated component's spacing and type values against the token set to catch invented defaults before merge.
Version control for prompts, not just for code
A prompt that reliably produces on-brand output is itself a reusable asset, worth keeping alongside the token set it references rather than retyped from memory each time. Teams that get consistent results tend to maintain a small library of proven prompts for common component types, the same way they'd maintain a snippet library for code.
What actually changes for a design team
- Design-system setup work, tokens, variables, component libraries, becomes more valuable, not lower-priority, since it's the input that determines generation quality.
- Accessibility review moves earlier in the process, because a generated layout needs the same WCAG check a hand-built one does, and skipping it doesn't get easier just because the layout arrived faster.
- The design-to-code handoff compresses, but the review step on both sides, design fidelity and accessibility, has to expand to match, not shrink because the first draft appeared instantly.
FAQ
Do these tools produce accessible layouts by default?
No. Visual correctness and WCAG conformance are separate properties, and a generated layout that looks right can still fail contrast, labeling, or focus-order requirements that need a dedicated check.
Does having design tokens guarantee brand-consistent AI output?
It significantly improves the odds, since the tool has something concrete to reference instead of inventing values, but it still requires a diff check against the token set before merge to catch drift.
Is axe-core enough to certify a generated component as accessible?
No. It catches a meaningful share of automatable checks, contrast, missing labels, invalid ARIA, but keyboard focus order and screen reader reading order both still require a manual pass.
What's the difference between this post and the one about AI and no-code UI development?
This one covers the design-process side: how layout generation works, what design tokens do in that pipeline, and where accessibility risk enters before code review. The companion post covers what happens after generation: code ownership, Git workflow, and low-code security risk.
Should a design system be built before or after adopting an AI generation tool?
Before, if possible. A tool generating against an established token set produces meaningfully more consistent output than one generating against nothing.