If your product already has a working component library in code, how much of it do you need to rebuild in a design tool before you can explore the next feature? That’s a question I keep coming back to as our team experiments with Paper and Storybook.
For a product we’re building, the buttons, icons, comment containers, and tokens already lived in the repository. We had built the library using shadcn/ui as a starting point and documented key components in Storybook. When users asked to leave feedback by voice, I wanted to explore that feature visually while keeping those existing foundations close.
I used an agent to inspect the relevant code, bring its styles into Paper, work through the interaction, and build a prototype back in the product. The interesting part was how much we could reuse, and how clearly the working prototype exposed the decisions I still needed to make.
Table of contents
- How do Paper and Storybook work together?
- Start with the components your product already uses
- Research the interaction before designing the UI
- Design the feature one state at a time
- Bring the design back into a working prototype
- What still needs engineering review?
- Do you still need a separate Figma library?
How do Paper and Storybook work together?
Paper and Storybook can support a workflow where existing code guides new design work. Storybook shows the implemented components and their states, while Paper provides a visual canvas for exploration. An AI agent with access to the repository and Paper can use that context to create designs, then implement the approved direction using existing components.
Each piece has a specific role. Storybook stories capture rendered component states, which makes the library easier to inspect. Paper’s MCP connection lets an agent read and edit its HTML and CSS canvas. The agent also needs access to the product repository so it can inspect the actual implementation.
If you’re setting this up for the first time, our getting started with Paper guide covers connecting Claude Code or Codex, testing the MCP connection, and trying a first task.
That last connection matters. A design that looks like your product can still be built from unrelated styles and duplicated components. In this workflow, I explicitly ask the agent to find the source files, use the existing tokens, and explain what it has reused. Connecting the tools gives us access to that context; keeping the work aligned still takes direction and review.
Here’s the process we worked through:
- Inspect the components and tokens used by the existing feedback flow.
- Create an editable visual reference in Paper from those sources.
- Research voice-comment patterns and map the interaction.
- Design and review the feature’s states on the canvas.
- Implement a prototype using the product’s existing components.
- Test it in context and prepare the remaining work for engineering.
Start with the components your product already uses
Start with a small part of the product that already works. For this feature, I focused on the container where a stakeholder leaves a comment, along with its buttons, identity details, icons, and styling.
Our feedback product lets people comment directly on a prototype. Users wanted to record what they were thinking instead of typing everything out, so the design problem was specific: add a microphone and a recording flow to the commenting experience they already understood.
Before designing that addition, I asked the agent to inspect the relevant repository files and create a reference in a particular Paper file. Its audit reported 33 widget theme variables referenced by the feedback components, plus their theme counterparts. We focused on the light appearance for this exercise, and the audit separated existing CSS tokens from values written directly into components.
An adapted version of that first prompt:
Inspect the components used when a stakeholder leaves feedback. Identify their source files, existing CSS tokens, and any hardcoded values. In this Paper file, create a visual reference of those components and their relevant tokens. Focus on the light appearance. Show what you found before designing the new voice-comment feature, and flag any approximations.
Watching that reference appear gave me a way to compare the canvas with the actual product. I could inspect the colors, typography, and spacing before asking for a new interaction. Paper also documents how an agent can create tokens from CSS variables in a codebase.
I tried a webpage snapshot as well, but the pasted result came through awkwardly in this attempt. More importantly, a visual capture alone didn’t establish which repository components should be reused. For this task, starting from the source files gave the agent more useful context.
If your library needs work before this step, our Figma to Storybook workflow covers auditing one component and documenting the rules around it.
Research the interaction before designing the UI
I still wanted to see how other products handled voice messages before deciding how ours should work. I used Mobbin MCP to pull examples, then looked through patterns from ClickUp, Slack, Discord, and others. The examples helped me think through the recording controls, how an audio attachment appears, and whether people should be able to read a transcript.
From there, I asked for a quick wireframe of the flow in the same Paper file. The sequence was straightforward: click the microphone, record, confirm the recording, attach it to the draft, and send the comment. The posted comment would include playback and an option to show a transcript.
Putting those states next to each other helped surface questions early. When should Send become available? Can someone write a note alongside the recording? What remains visible while the microphone is active? Those answers shape the component before we spend time refining its appearance.
The agent initially put the flow in a different file, so I had to redirect it. Small details like naming the destination file are part of making this process work. If you want to try the research step, here’s how we use Mobbin MCP for design inspiration.
Design the feature one state at a time
Once the flow made sense, I asked for the first state using the current comment container and existing repository components. Starting there let me check that the new feature still belonged to our product before generating the rest of the flow.
We needed a microphone icon that wasn’t already displayed in the comment box. The agent found one in the icon library we were using, which kept the addition consistent with the existing set. Then we moved into the recording state and worked through the controls beside the original design.
One generated version removed the microphone while recording. I asked to bring it back with an active treatment so the user could see that it was working. I also questioned whether the text field should remain available. Keeping it made sense for our use case, because someone might want to add a short written note alongside an audio message.
Those were the useful design decisions in this exercise. The agent could arrange the components quickly, while I stayed close to what the person leaving feedback would understand and expect. Once those first states felt right, I asked it to extend the same styling into the attached-audio draft, posted comment, and transcript view.
Here’s a prompt you can adapt:
Using the existing comment container, tokens, and icon library, design the idle state with a microphone control. Keep the current identity details and text input. Put the recording state beside it in the same Paper file, then wait for review before extending the remaining states. Identify any UI that needs a new component or behavior.
Bring the design back into a working prototype
Build the approved direction in the context where people will use it. I wanted a prototype on our existing page, using the product’s component library, so I could test the commenting experience from beginning to end.
I had to clarify that request when the agent proposed an interactive Storybook prototype. Storybook was useful for inspecting our components, but for this review I needed to click on the page, open a comment, record feedback, and see where it appeared.
The first working version exposed two gaps. The comment box had been placed as a separate floating demo instead of opening through the product’s existing click-to-comment behavior. The transcript also displayed sample text rather than transcribing the actual recording.
Both issues were easy to miss on a static canvas. I could record and play back audio, and the component looked convincing, but the surrounding experience still needed correction. I asked the agent to connect it to the existing commenting flow and address the transcript behavior, then tested again by leaving feedback on a button.
That’s why I want the prototype in context. A useful review starts with the user’s first action and follows through to the result, including where the comment is attached and whether the content shown is real.
What still needs engineering review?
The output of this process is work an engineer can review, with clear notes about what functions, what is mocked, and what remains unfinished. Reusing established components helps with consistency, while new interactions and integrations still need scrutiny.
The agent produced handoff notes describing how to run the prototype and which parts remained mocked. For a voice-comment feature, I’d want engineering to review the recording and transcription implementation, how audio is stored and retrieved, and how failures or microphone permissions are handled. The design review also needs to cover mobile layouts and accessible controls.
Those are review areas for taking the feature further, rather than claims that the walkthrough completed every integration. At the end of the exercise, my next step was to create a pull request for our engineering team to inspect and finish as needed.
The initial prototype build was around eight minutes into its work when I checked its progress. That was exciting to see, but it was one pass in a longer process of research, design, testing, and corrections. I’d use the experience as a reason to try a small feature with your team, rather than a delivery estimate.
Do you still need a separate Figma library?
A team with a usable component library in code may be able to explore new features without maintaining a complete duplicate library in Figma. This is what we’re testing: keep the implemented components as the reference, make them understandable through documentation, and use Paper when we need a visual space to explore changes.
There are still good reasons for a team to keep an established Figma library, including how designers collaborate and how stakeholders review work. Our example started with a relatively small library already built in code. A larger product with multiple platforms or conflicting implementations will have more decisions to resolve.
What I’m excited about is being able to start a feature from the product we actually have. I can research patterns, compare states, question an interaction, and test the result while the existing components stay part of the conversation. We’re still figuring out how this changes the day-to-day work, but this feels like a useful place to keep experimenting.
If your team is exploring the same process, our getting started with Paper guide walks through the connection and a first task. At TDP, we also help teams build and document component libraries in code and practice these workflows together. Talk to us about a component-library sprint.
Related reading
- Paper AI design tool: a code-connected workflow from design to production
- Figma to Storybook: build a component library AI can use
- Mobbin MCP: pull design inspiration in Claude Code
