Design System
Building an internal product for prototyping
How Barte's design team built its own prototyping environment, in code, with the Design System, comments and usability tests.
At Barte, the design team has a prototyping environment of its own: a real repository, running our actual Design System, where prototypes are born working — and with one detail, without the designer having to worry about front-end.
It wasn’t an engineering project. It was built by design, using Claude, with the engineering team backing us up and unblocking us at the right points. A project that started out unassuming and became an internal product.
I want to tell you how we got here, including the problems we created along the way.
Why we built it
Three goals guided everything from the start:
Speed to prototype with the real Design System. Prototyping straight with production components, without rebuilding anything in another tool and without hand-writing front-end, with zero concern about the code being generated. The designer describes it, Claude builds it, always within the DS rules. In this early stage, we basically left Figma and moved to Claude.
Opening up ideas early and getting the team involved fast. A navigable prototype running in the browser changes the quality of the conversation. Instead of debating a static image, the team interacts with the thing working.
Testing and learning without premature attachment to craft. In Figma, people sometimes invest in polish and get attached too early. Here, an idea takes shape in minutes, you can get it wrong fast, throw it away painlessly and iterate at a speed the traditional flow doesn’t allow.

The problems it created
Like any real product, after a few months running with recurring use, we found problems we hadn’t anticipated.
Collaboration scattered. The prototype was there, navigable, but feedback happened on Slack, in loose threads, screenshots and comments that got lost. The environment sped up creation, but had nowhere to accumulate the conversation.
Some projects became too detached. “Don’t get attached to craft” worked so well that, in some cases, it turned into a crutch. Prototypes moved forward in the flow without going through the refinement Barte’s product demands. The speed needed a counterweight: how do we stay efficient in the early stage but still pay attention to refinement later on?
Handoff was still hard. Notice that Figma had dropped out of the flow. Because it’s a separate environment, the prototype’s code wasn’t reused. Engineering got a working reference, but rebuilt it from scratch, so part of the value of prototyping in code was lost. A “dev taking screenshots to start coding” made no sense: Figma with MCP was still far more efficient for engineering.

What we did
Two builds tackled these problems head-on:
A skill that takes the prototype into Figma with full DS fidelity. It’s not a screenshot, and it’s not redrawing from scratch, they are real instances of our library components, generated from the prototype’s code. That gives the designer back the space to work the detail, in the right tool. It closed the loop between code and design in both directions: craft and handoff.
A comment layer inside the environment itself. We built a Figma-style commenting system inside the environment in two days. Anyone on the team comments directly on the prototype, anchored to the exact spot on the screen, from the earliest sketches on. The conversation that used to scatter across Slack is now centralized in one place.
The environment is also where we run usability tests with working prototypes — internally and with customers, as was always the plan. Since we operate in a fintech context, where compliance and data confidentiality are taken seriously, we added a simple access-code authentication layer — only whoever receives the code gets in. That lets us put navigable prototypes in front of real users, safely, without exposing anything.

How it was built
This may be the most important point of the article: all of it was built by design, using Claude.
The repository, the skills, the comment layer, the Figma integration, none of it went through the engineering backlog as a project. Engineering’s role was a different one, and it was essential: engineers backing our infrastructure decisions, validating approaches and unblocking what was beyond our reach (the database infrastructure to persist the comments, for example).
It’s a model I strongly believe in: design with the autonomy to build its own tools, and engineering as a strategic partner.

The outcome
What started as a shortcut for prototyping became an internal product: an environment that brings efficiency to the design team and to Barte’s product process as a whole.
Prototypes born in code, with the real DS. Collaboration that happens on top of the artifact. Craft that goes back to Figma when it needs detail. And an increasingly shorter handoff path between the idea and the product.
Curious to see how this runs in practice? The next article will be an end-to-end case study: how we do design at Barte.