Table of contents:
- What are Paper and Figma Make?
- Why this comparison matters now
- Test 1: Building a 404 page
- Test 2: Translating a Storybook component library
- How to start using Paper in your workflow
- Tools and resources
What are Paper and Figma Make?
Paper and Figma Make both support workflows that produce code. Paper is a visual design canvas built on HTML and CSS, with MCP access for agents. Figma Make turns prompts and design context into interactive apps. The useful comparison is how each fits your team's path from design exploration to a reviewed implementation.
Figma describes Make as a prompt-to-app tool. You can refine the result through conversation, work with the generated code, and share a working preview. It is a separate workflow from editing layers in Figma Design.
Paper gives designers a visual canvas based on web layout. Its MCP documentation explains how to connect agents to design files. Moving a design into an existing product still requires checking components, behavior, accessibility, and the conventions of that codebase.
| Question | Paper | Figma Make |
|---|---|---|
| Where do you work? | A visual HTML/CSS canvas that agents can access through MCP. | A prompt-to-app environment with a working preview and editable code. |
| What should you evaluate? | How well the canvas and agent fit your repository workflow. | How well the generated app follows your design context and interaction requirements. |
| What needs review? | Integration with the actual product and its component library. | Generated behavior, code quality, and integration with the actual product. |
About these tests: This article was first published on March 25, 2026. The observations below describe the original experiments; this October update corrects the product descriptions. The 404-page experiment compares Paper with Figma Make. The Storybook experiment uses Figma MCP and should be read as a separate workflow comparison. These examples do not establish a universal winner or describe a new test of today's versions.
Why this comparison matters now
The design-to-code handoff has been broken for years. Designers create pixel-perfect mockups in Figma, developers rebuild them from scratch in code, and everyone pretends the Figma Dev Mode specs are actually useful. We've been doing this dance at TDP with B2B SaaS clients, and the gap between "designed" and "shipped" keeps eating weeks off every sprint.
For a product team, the useful question is how much work remains after the first result. Can you reuse the existing components? Does the page behave correctly? Can engineering maintain the implementation? Those are the questions to bring into a trial of either tool.
Test 1: Building a 404 page
We used cal.com, an open-source scheduling platform, as our testing ground. The task was simple: design three versions of a 404 page — minimal, playful, and split layout — using the same prompt, design tokens, and reference images in both tools.
Figma Make results
Figma Make finished first. It was noticeably faster. But when we looked at the output, all three versions were essentially identical. The prompt specifically asked for three distinct styles — minimal, playful, and split — and Figma Make ignored that entirely. It didn't incorporate the reference images we attached, and the layouts were generic.
Paper results
Paper took longer, and you could watch it work in real time — creating artboards, placing elements, building each variation. But the output was dramatically better. Each version was distinct: one had a progress bar, another had more playful copy, and the split view actually used the reference images we provided.
The real difference showed up in what happened next. We picked the split-view design and asked Claude Code to build it as the actual 404 page in the cal.com codebase. Because Paper's output is already HTML and Tailwind CSS, the translation was nearly one-to-one. Claude Code even pulled in the existing page logic, asked whether to keep the smart URL detection, and checked what the CTA buttons should do.
That kind of context-aware implementation doesn't happen when you're exporting a Figma frame as a PNG and rebuilding it from scratch.
Test 2: Translating a Storybook component library
The second test addressed a pain point we've seen repeatedly: teams that have a component library in Storybook (built in code) but no matching design system in their design tool. Historically, there hasn't been a good way to reverse-engineer Storybook components into usable design assets.
Figma approach
We connected Figma's MCP, pointed it at a button component in Storybook with multiple variants (secondary, icon, base, destructive), and asked it to build out all colors, sizes, and variants in Figma. It created the components, but each variant ended up on its own separate page. The result was functional but disorganized — you'd need to spend significant time restructuring it into a usable component library.
Paper approach
Same prompt, same Storybook source. Paper built everything at once — sizing section, color section, variant section — all organized on a single canvas in a way that actually looks like a component library. The states were clearly defined, laid out in a design-friendly format, and immediately usable for reference.
In this experiment, Paper's arrangement was easier for us to review. That observation concerns the layout produced in this run, rather than the completeness of either tool's component system.
How to start using Paper in your workflow
Start with a small trial in the tools your team uses today. Here is how we would evaluate whether Paper fits an existing product workflow.
1. Pick a contained project
Don't start with your entire design system. Pick something self-contained — a landing page, a 404 page, an onboarding flow. Something with a clear scope and a fast feedback loop.
2. Set up the Paper MCP with Claude Code
Paper's MCP server is what makes the AI workflow click. Connect it to Claude Code so you can prompt against your Paper files directly from the terminal. If you're not familiar with the terminal setup, Paper has onboarding docs, and TDP has a walkthrough video on environment setup.
3. Use planning mode before building
One thing we've learned: don't let Claude Code build on the first prompt. Use planning mode to go back and forth on the approach before any code gets written. The more detailed your plan, the closer the output matches what you're asking for. Use the plan to agree on which existing components to reuse and how you will check the result.
4. Iterate visually, ship in code
Design in Paper's visual canvas, then use the MCP to push changes into your actual repo. The loop is: design visually, review the generated code, refine in Paper, push to codebase. Check the implementation against your repository's styling conventions before merging it.
5. Explore Paper's AI-native features
Paper has built-in features that think like a designer — text orphan control, text balancing, filters and animation effects. These are small touches, but they signal that the tool is being built by people who understand design craft, not just code output.
Tools and resources
- Paper documentation for MCP setup and canvas workflows. Check current pricing for plan limits.
- Figma Make documentation for app generation, editing, and sharing.
- Storybook for documenting and reviewing your existing components.
Start with one product task
Choose a small feature, give both workflows the same context, and review the results with engineering. Record what you had to fix, which components were reused, and how much work remained before the feature could ship. That gives your team a more useful basis for choosing a tool than the first screenshot.
For the next step, see our Paper workflow from design to production and our guide to writing a design.md file.
If your team wants help connecting design exploration to an existing codebase, talk to TDP about your design-to-code workflow.
