Google Stitch is the hype reel. The demo videos look incredible, the animations feel polished, and the output looks like something a senior designer spent a week on. So when it showed up in my feed for the fifth time last week, I decided to actually put it to work on something I'd ship — not a dream-big portfolio piece.
Short answer: if you want inspiration, explore playful concepts, or generate a one-off hero illustration, Stitch is genuinely fun. If you want to design inside your real product — with your real design system, your real brand, and a real path to code — it falls short of tools you probably already have open.
Table of contents
- What is Google Stitch?
- Why the design.md file matters more than the tool
- The test: a 404 page in a real design system
- How to actually use Google Stitch without wasting a week
- Verdict and better alternatives
What is Google Stitch?
Google Stitch is a generative AI design tool from Google that produces UI mockups from text prompts, image references, and design system inputs. It sits in the same category as Figma Make, v0 by Vercel, and Lovable — text-to-UI tools that try to compress the gap between idea and interface.
The pitch is straightforward: describe a screen, attach references, and Stitch generates layout options you can iterate on. It supports reference images, and critically, it reads a design.md file — a concept I'll come back to in a second because it's the most interesting idea in this whole tool.
In practice, the Stitch interface splits your screen into three panels: a prompt area, a canvas, and an agent log. Coming from Lovable or v0, where the whole flow sits on one side like a terminal, it feels scattered. Small thing, but you feel it every iteration.
Google Stitch vs. Figma Make
Figma Make lives inside a tool designers already trust. Stitch is standalone and generative-first. Figma Make benefits from Figma's editing surface — you can grab a rectangle and move it. Stitch outputs are essentially read-only previews with prompt-driven edits, which is the single biggest friction point for designers.
Google Stitch vs. v0 / Lovable
v0 and Lovable target the design-to-code flow directly — their output is code, and their iteration happens through code. Stitch produces more "designed" looking artifacts but with a weaker path to production. If you need a prototype your engineers can pick up tomorrow, v0 and Lovable are much closer to that reality.
Why the design.md file matters more than the tool
The most valuable thing I took away from this whole test wasn't about Stitch at all. It was the design.md file.
A design.md (sometimes called a DMD) is a plain-text blueprint of your design system, written specifically for AI agents to read. Colors, typography, spacing, component rules — plus the things that usually live in designers' heads: the don'ts. "Don't use full-uppercase headers." "Don't stack more than two CTAs." "Don't use the accent color on destructive actions."
This is a huge unlock, and it's not Stitch-specific. Every AI design tool you use this year will be better if you feed it a real design system file. If you're a design lead, this is the kind of artifact you should be building with your engineering team, not in isolation — because everyone (designers, engineers, AI agents) is going to be pulling from it.
The benefits, if you do it right:
- Consistent output across tools. The same design.md works in Stitch, Claude Code, v0, and whatever AI design tool ships next quarter.
- Better prompts. Explicit "don'ts" cut down on bad generations dramatically — I noticed this across every AI tool I use.
- Actual alignment with engineering. A shared source of truth beats a Figma library nobody opens.
The test: a 404 page in a real design system
To stress-test Stitch, I set up a realistic scenario. Qualcomm — an open-source design system I use as reference in a lot of my videos — as the brand. Three 404 page variants: minimal, playful, and split. Each with a header, one illustration, and two CTAs. Reference illustrations attached. Stitch set to Gemini 3.0 on the highest thinking mode. Web app target.
Round 1: Stitch on its own
The problem: Stitch had no structured design system to pull from, just the prompt and the Qualcomm reference. The result: Three options came back with a heavy green color palette. Qualcomm's primary is a dark near-black gray. Stitch invented its own greens, rounded the buttons (nice), but got the hierarchy wrong. The "primary" button used the wrong color entirely. There was no way to click into the swatch and edit it — I could copy the hex, but not tweak.
Round 2: Stitch with a design.md
The problem: Same prompt, but I pasted in the Qualcomm design.md file so Stitch had explicit tokens.
The solution: Stitch acknowledged the file and updated the preview. Typography locked to Cal Sans (correct). Colors moved closer to the real palette after one more nudge asking it to honor the text styles.
The results:
- Type rendered correctly after one correction
- Corner radius stayed generic — it couldn't pin a specific value from the file
- Button hierarchy improved but still not matching the design system exactly
Round 3: Re-prompting for the minimal option
The problem: I asked Stitch to redo the minimal option using the construction screenshot I'd attached and the updated design system.
The result: It ignored the design system, uppercased everything (Qualcomm has no full-uppercase rule), and — based on a second look — seems to have created an entirely new design system on the fly rather than using the one I provided. After asking it to redesign with rounded buttons and no uppercase, the output still didn't look like Qualcomm.
The pattern across all three rounds: Stitch is happy to generate polished-looking screens, but enforcing brand rules through prompting alone is a losing game. And because you can't directly edit colors, radii, or type in the canvas, every correction is another round-trip through the prompt.
How to actually use Google Stitch without wasting a week
If you're going to use Stitch anyway — and there are real reasons you might — here's the workflow that gives you the best ratio of time to value.
1. Use it for exploration, not execution
Stitch is at its best when you're in "dream big" mode. Portfolio concepts, animation ideas, illustrations, playful directions for a marketing page. Prompt loosely, let it surprise you, screenshot the bits you like. Do not ask it to ship pixel-accurate work in your product's design system.
2. Bring a design.md even when you don't expect it to obey
Even when Stitch ignored specifics, having the design.md in the prompt produced cleaner output than going in cold. Treat the file as a prompt-conditioner, not a contract. Good AI design tools will honor it properly — this is still worth building.
3. Budget for iterations, not edits
Every change is another prompt. If you're used to clicking on a text layer and bumping the font size, you will find this unbearable. Set a time budget per screen (maybe 20 minutes of prompting) and move on — don't try to perfect in Stitch.
4. Do not plan on Stitch → Claude Code as a pipeline
Getting Stitch output into a real codebase is genuinely hard. I had to pull in an engineer to get the MCP set up, and I'm not going to walk through that here because it took hours. If production code is your goal, start in v0, Lovable, or Claude Code directly. That's the shorter path by a wide margin.
5. Keep Figma (or your design tool of choice) open next to it
The most honest use pattern I landed on: Stitch for divergent inspiration, Figma for convergence and editing. Stitch screenshots become references for a real design file, not the file itself.
Verdict and better alternatives
Honest take: I would not put Google Stitch in your toolbox as a product designer doing day-to-day product work. The lack of direct editing, the inconsistency with design system inputs, and the arduous setup to get output into code all compound. Figma Make isn't perfect either, but it's closer to where designers actually work. For design-to-code specifically, v0 and Lovable are ahead.
Where Stitch does shine: divergent thinking, concept work, animations and illustrations, portfolio pieces, and anything where "surprise me" is a feature, not a bug.
Tools I'd reach for instead for production design work:
- Figma Make for staying inside your existing design file
- v0 by Vercel for text-to-code prototypes that ship
- Lovable for full-app generation
- Claude Code for the cleanest design-to-production pipeline (we build client prototypes in Claude Code at TDP and the speed gains are real)
We've been using Claude Code alongside a structured design.md on client projects for B2B SaaS teams — the combination of a real design system file and an agent that can actually write code into your repo is, in my experience, the fastest current path from Figma to a working prototype.
If your team is evaluating AI design tools and trying to figure out where they fit — or where they don't — we run hands-on workshops walking product teams through the full design-to-code AI stack. One week or one month, depending on depth. Sign-up for our design-to-code workshop!
