I Took a Claude-Built SaaS UI into Figma and Back to React

Claude gave me a tidy expense inbox. It had a table, statuses, buttons, and all the other signs of a functioning SaaS product. Then I looked at one expense that was missing a cost center. The reason it needed attention was easy to miss.

That seemed like a good place to start. I wanted to see what would happen if I built a screen with Claude, refined its design system in Figma, and asked Claude to continue the React prototype using the new design. Could it keep the same product decisions across an inbox, an expense detail view, and a dashboard?

I recorded the full experiment on YouTube. I used a spend management demo for the experiment, with a finance manager and a connected expense review flow.

I started by telling Claude who would use the product: a finance manager reviewing employee expenses. I described the inbox, the information needed to make a decision, and the actions a manager could take. Claude built the first UI in React with reusable pieces.

It was a useful starting point. But the merchant, the review reason, the urgency, and the available action competed for attention. If you're scanning a queue, you want to know why this expense is here before you spend time opening it. “Missing cost center” should be hard to miss. The button can wait its turn.

I kept one expense in mind throughout the rest of the experiment: Alex Morgan submitted a $2,480 Atlas Cloud charge, and the cost center is missing. The manager opens it, checks the receipt and recent spending, then asks Alex for that information. The expense moves from Needs review to Waiting for employee, and the request appears in its activity.

The short task note I would hand an AI coding tool includes:

User: finance manager Task: review Alex Morgan's $ 2, 480 Atlas Cloud expense Problem: cost center is missing Show: receipt, recent spending, reason for review Action: request the cost center from Alex After the action: Waiting for employee Also show: the request in activity and the updated item in the queue Enter fullscreen mode Exit fullscreen mode Now there is something to check besides whether the screen looks nice.

I moved the initial UI into Figma and worked through its foundations, components, and larger screen patterns. I changed the default indigo/purple direction to blue, adjusted the header and branding, and organized the components so I could use them across the product.

The color change is the most obvious part of the video. The more useful part is deciding what a row, a status, and a review action mean in this product. If Waiting for employee appears in both the queue and the expense detail, I want the label and treatment to agree. If a dashboard card points to Needs attention, it should lead somewhere useful. Claude needs those patterns when it builds the next page.

In Figma, I used variables for repeated values and components for repeated UI. Figma's variables guide explains how values can be applied across a design; aliases let one variable reference another. A token named for its role, such as status/waiting, tells a future implementer more than a blue swatch does. Variants help when a component has predictable states.

I also gave Claude patterns for choosing between tables and cards. A review queue needs dense rows you can scan. An expense detail needs room for the receipt, context, and action. Those are different jobs, even when both screens share the same buttons and statuses.

I didn't resolve every UX question in Figma. I wanted to see what Claude would do once it had a stronger design reference.

After the Figma pass, I connected the design through MCP and told Claude to use the refined system for the next implementation pass. Otherwise, it could happily keep following its first UI. AI tools can be loyal to an old decision long after you've changed your mind.

Figma's MCP server can provide an agent with design context, including components and variables. Code Connect can map Figma components to their code counterparts. Those references help Claude understand what to build. I still inspected the React screen and clicked through the flow.

For this expense, a blue Request information button would be a very small victory if clicking it left the expense in Needs review. The prototype needed to show the request, change the status, and update the activity. The queue then needed to reflect the new state.

There's a straightforward React point here too. Give the expense one status value such as needs_review or waiting_for_employee; don't maintain several independent booleans that can disagree. The React docs on state structure explain why mutually exclusive states help avoid impossible combinations. A real finance product would need persistence and permission rules around this action. The demo tests the screen flow.

Once the expense flow was in place, I asked Claude for a dashboard for the same finance manager. It brought in a Needs attention area, spending against the monthly budget, categories and merchants, notifications, and recent activity. Those pieces made sense for the product we had described.

One choice still bothered me: recent activity had its own white card and looked too prominent. It was getting prime dashboard real estate for telling me what had already happened. I removed that card treatment and put the activity on a quieter gray background. The items needing the manager's decision could take the lead.

That is the part of an AI-generated dashboard I keep checking. The model can assemble all the requested sections. Someone still has to decide what the person should notice first. In this case, a pending expense deserves more attention than a routine activity log.

I would run through the same expense again before asking for five more screens:

If one of those fails, I have a specific problem to give Claude. “Make the UX better” is a much harder prompt to review.

Claude can work from a visual reference. A well-structured file gives it more to work with: layout, named components, variants, and variables bound to the elements you care about. Start with one relevant frame and check what appears in code. You still have to describe behavior such as what happens after Request information. A static frame doesn't contain that whole story.

Show it the relevant Figma design and point it to the components in your codebase. Say which existing variants and tokens the screen should use. If you have Code Connect mappings, they can provide a more explicit link. Then inspect what Claude wrote: did it import the existing component, or make a slightly different button that will become everyone's problem next month?

I prefer a short product context, a place to find the design-system rules, and a task brief for the current flow. Claude should be able to find the role, the current components, and what changes after a click. There's no magic file count. In the video, the finance scenario and the refined Figma system did more work than a long list of generic design adjectives.

It gives the agent access to Figma context. You still need to ask for the code change and review the rendered screen. I explicitly told Claude that the refined Figma work was the current design reference before it continued the React prototype. MCP doesn't know whether Alex's expense changed status just because the component looks right.

Click through a real task. In this demo, I can request Alex's missing cost center and check the status, queue, and activity. That catches broken connections between screens. It doesn't tell me whether finance managers understand the flow; for that, I'd ask people who do the job to try it and watch what happens. The video shows the first kind of check.

Give it the current components and a bounded task. Review the new page against existing screens, including states and behavior. A waiting expense should use the same status language in the inbox and detail view. Check the implementation for one-off colors or duplicate components too. Figma's MCP tools can supply design context; the screen still needs your review.

You can watch the full Claude, Figma, and React walkthrough here, including the initial inbox, the design-system pass, the expense request, and the dashboard change. At UITOP, this is the kind of B2B SaaS work we spend time on: what a screen needs to show, what changes when someone takes an action, and whether the next screen still makes sense.