Design tools have spent years making the handoff cleaner. The handoff still exists.
That is what makes Paper interesting. It gives me a visual canvas where I can think like a designer while working much closer to the product’s actual code. I can pull tokens from a repository, direct an agent to explore a component, adjust the result visually, and send the approved direction back into the codebase.
The biggest shift is how I spend my time. Pixel pushing used to take up a meaningful part of my day. Now I spend more of that time directing the work, reviewing decisions, and getting a design into the product faster.
In this guide, I’ll walk through the complete workflow we’ve been testing: setting up Paper from an existing repository, comparing it with Figma, exploring a real product problem, and implementing the final component.
Table of contents
- What is the Paper AI design tool?
- Why Paper feels different from Figma
- How to use Paper in a real product workflow
- Where Paper works well—and where it still needs help
- Is Paper worth adding to your design workflow?
What is the Paper AI design tool?
Paper is a professional interface design tool built on HTML and CSS, with a visual canvas that AI agents can read and edit. Designers can work with familiar concepts such as frames, flex layouts, typography, color, and spacing while connecting the canvas to agents, repositories, and production code through MCP.
That code connection is the main reason I keep coming back to it. Paper feels like an extension of the repository while preserving the visual feedback I need as a designer.
According to Paper’s own comparison, its canvas uses real HTML and CSS. This gives agents a more direct representation of the interface than a proprietary canvas that must later be translated for the browser.
In practice, I can use Paper to:
- Extract design tokens and interface rules from an existing codebase.
- Ask an agent to create and revise screens directly on the canvas.
- Copy existing Figma work or capture a live webpage for exploration.
- Turn an approved visual direction into a coded component.
Why Paper feels different from Figma
Paper and Figma overlap, but they currently excel at different parts of the product design process. Figma remains a mature environment for component libraries, collaboration, and established team workflows. Paper gives me a particularly fluid loop between code, an AI agent, and visual design.
| Capability | Paper | Figma |
|---|---|---|
| Canvas foundation | HTML and CSS | Proprietary design canvas |
| AI agent workflow | Agent can work directly on the canvas through MCP | AI features and external integrations work within Figma’s ecosystem |
| Tokens from a codebase | Can create tokens in the file from repository variables | Can document extracted values, though our test did not create matching variables automatically |
| Layout | Native flex behavior | Auto layout |
| Component ecosystem | Still developing | Mature libraries, variants, and team workflows |
| Path back to production | Closely connected to code | Usually requires a translation or handoff step |
This is based on one practical test, not a universal benchmark. We gave both tools the same job: inspect an existing product repository and create a design-system board from its rules.
Figma completed the initial board faster. It laid out colors, spacing, radius, elevation, usage principles, and several interface elements. The result was useful as documentation, but the extracted values were displayed on the canvas rather than created as connected design tokens.
Paper took longer. When it finished, the color, type, spacing, radius, status, and layer tokens were available inside the file. Those tokens came directly from the way the product was defined in code, including a font mismatch the agent surfaced during setup.
That distinction matters when the repository is the current source of truth. A board that resembles the product helps people understand it. Connected tokens give the next design somewhere reliable to start.
Paper’s build log confirms that tokens can be added through MCP from CSS variables, an existing canvas design, or another source. Figma also warns that AI output should be reviewed rather than treated as authoritative in its AI guidance. That advice applies equally here: the agent accelerates the work, and the designer remains responsible for the decision.
How to use Paper in a real product workflow
Our test went beyond generating a design-system board. We used Paper to rethink an actual component from a product we are building: a comment popover that lets teammates leave feedback on working prototypes.
The existing experience could capture an interface element or highlighted text and attach a comment. User feedback showed that the screenshot treatment was confusing, especially when the target was copy. We needed a clearer way to communicate exactly what the commenter had selected.
Here is the workflow we followed.
1. Start with the repository
We opened the product repository in our coding environment and asked the agent to create a Paper project. The first prompt instructed it to inspect the current product and extract the design system into the new file.
Starting from the repository gave the agent the actual vocabulary of the interface: named colors, type rules, spacing, radius, status colors, and existing component patterns. It also exposed inconsistencies that a screenshot would hide.
This is the first place I would start when repo access is available. A browser capture is excellent for quick exploration. The repository gives you the rules that the shipped product is truly using.
2. Pull the current component states onto the canvas
Next, we asked the agent to find the comment popover in code and lay out all of its existing states in Paper. Seeing those states side by side made it much easier to inspect the interaction as a system.
Storybook can serve a similar purpose for engineers. Paper gives me the visual, editable workspace I want as a designer while keeping the states close to their implementation.
3. Research patterns before generating solutions
AI will happily jump straight into making variants. I stopped it.
Good product design still requires understanding the problem, looking for relevant patterns, and deciding which direction deserves exploration. We asked the agent to use the Mobbin MCP to collect examples of interfaces that attach screenshots or anchor feedback to a specific UI element.
Several references were weak or irrelevant. That was useful information too. The designer has to judge the research, discard shallow matches, and explain what should happen next.
The strongest insight was that the screenshot needed to preserve more context around the selected element. For text, a pair of initials was too abstract. We wanted the highlighted copy itself to become the visual anchor.
4. Generate rough options and choose a direction
We asked the agent to create several approaches:
- A context crop with the selected sentence highlighted.
- A compact strip for dense layouts.
- A markup overlay around the selected component.
- A quote-style treatment for highlighted text.
The first output was rough, which is fine. Its job was to make a set of ideas visible quickly. I chose the quote-style direction and asked the agent to place it inside the real popover rather than evaluating it as an isolated concept.
That is where the workflow becomes genuinely collaborative. I can ask the agent for breadth, choose the promising idea, and then narrow the constraints.
5. Refine visually and give specific feedback
The agent’s first implementation was oversized. The buttons, avatar, timestamp, and component padding drifted away from the established product constraints.
I gave it direct feedback about which dimensions needed to return to the existing scale. When the remaining issue was faster to fix by hand, I edited it on the canvas myself: removing an unnecessary divider, correcting the alignment, and simplifying the highlighted-copy treatment.
This balance is important. Prompting every tiny correction can take longer than making it. Paper lets me move between directing the agent and editing visually without changing environments.
6. Ask the agent to rebuild the design within product constraints
Once the concept felt right, we asked the agent to turn the rough composition into a component that respected the product’s padding, sizing, typography, and reusable structure.
This is where a code-connected canvas earns its place. The agent could inspect the current component and build the new state as part of the existing implementation instead of producing an unrelated block of frontend code.
7. Implement, test, and review in the product
Finally, we told the agent to implement the approved design in the codebase. We opened the product, selected text, added a comment, and checked the new component in context.
The first pass still had a clipping issue on the right edge. We sent that specific observation back for correction. AI shortened the route from concept to working UI, while review remained an essential part of shipping it.
The full loop looked like this:
- Extract the system from the repository.
- Bring the current component states into Paper.
- Research relevant interaction patterns.
- Generate several rough directions.
- Choose and refine one visually.
- Rebuild it within product constraints.
- Implement and test it in the actual product.
Where Paper works well—and where it still needs help
Paper is strongest when the work needs to move repeatedly between visual design and code. It gives an AI agent a canvas it can manipulate while letting a designer inspect and adjust the output directly.
What worked well
The token workflow stayed close to the repository. We could build a usable starting system from the values already shipping in the product.
The canvas supported real collaboration. An agent and multiple people can work in the same file, and you can see the work taking shape.
Familiar layout behavior reduced the learning curve. Paper calls auto layout “flex,” and the behavior maps closely to the web model.
Exploration stayed visual. We could paste designs from Figma, capture a webpage with Paper’s browser tool, or generate new directions from code.
Implementation followed the design decision immediately. Once we approved the component, the agent could update the existing product and give us something testable.
What still needs attention
AI output remains inconsistent. The agent misunderstood sizing, produced weak inspiration, and occasionally clipped content. Every stage required design judgment.
Paper’s component system is still maturing. Figma provides a more established model for reusable component libraries and variants.
A connected workflow needs setup. The value becomes much clearer when Paper, the coding agent, MCP integrations, and repository access are all working together.
Token extraction can reveal messy source material. That is useful, but teams should expect to resolve naming mismatches and one-off overrides rather than importing a perfectly clean system.
These limits do not make Paper less useful. They clarify the designer’s role: set direction, evaluate context, enforce the system, and know when to intervene.
Is Paper worth adding to your design workflow?
Paper is worth testing if your team already works closely with code and wants a faster loop between an idea and a production component. It is especially compelling for design engineers, technical designers, and founders who need to move across product decisions and implementation.
I would keep Figma in the workflow when a mature component ecosystem, broad stakeholder familiarity, or established collaboration process carries more weight. The tools can coexist. Existing Figma designs can be copied into Paper, and Paper can become the working space for code-connected exploration.
For me, the real value is agency. I can see the work, change it, direct an agent, and take the result into production. My hands are still in the design. They are spending less time on repetitive execution.
If your product team is trying to connect AI, design systems, and frontend implementation into one practical workflow, join the TDP community. We share the tools, experiments, and lessons we are learning while building AI-managed design systems.
We’re helping B2B SaaS teams implement agentic design systems and build design-to-code workflows. If you’re interested, sign up here.
Related reading
- Paper vs Figma Make: I tested both with the same prompt
- Agentic design system: how to build a component library AI agents can actually use
- Mobbin MCP: pull design inspiration in Claude Code without a single screenshot
- AI design to code workflow: why Figma-to-code is the wrong question
