Building a Prototyping Workbench

What if a designer could bring a PRD to a workbench and leave with the product logic—not just the screens—thought through in a realistic, clickable prototype?

vuDS* (aka vuDS-Experimental) is an experimental working environment for vuSmartMaps. vuSmartMaps (vSM) is a business observability platform used primarily by financial institutions to connect IT to business impact. vuDS is the design system behind it; vuDS* is our attempt to turn that system—and the product knowledge around it—into something executable.

The workflow we want: upload a PRD; let the workbench study it in the context of the product; work through the user stories and edge cases; and build the complete clickable flow. Not a generic mock-up. Something recognisably ours, with version control happening automatically and in situ.

Today, it can produce product-specific flows, but it is not yet self-serve. A designer still has to open the repository locally, work with Claude through the CLI and prompt around gaps in the documentation. The shared body of product knowledge exists, but it is not yet a queryable knowledge graph the workbench can reliably use on its own.

That gap is the experiment. Can a design system become more than a component library—can it become the working memory through which a team explores, critiques, and builds a product?

The design system as a working environment

The original vuDS began as a Figma library modelled on Grafana UI’s Storybook. We translated its CSS foundations—typography, spacing, colour and other variables—and matched Figma layer names to their counterparts in code. That gave us closer parity with production, but it also carried forward the limitations of the underlying library. Grafana UI serves a broad open-source community; vSM needs denser, more domain-specific workflows, and we wanted a more current visual and interaction language.

Our first attempt to take the design system into code followed a familiar model: build components separately, package them with npm, and consume them inside product repositories. In practice, the distance between the system and the product slowed everything down. Typography drifted. Every change had to be repackaged and carried across repositories. Components looked controlled in isolation and became awkward under the pressure of a real page. The development overhead was not viable.

vuDS* reversed that model. I built it as a React and TypeScript project where components, tokens, product context, research, and realistic demos live together. It uses the same charting and table libraries as our production stack, along with open-code primitives from shadcn/ui that an agent can inspect and modify directly. The primitives are keyboard-accessible, motion provides feedback rather than fad, and we adapt the system only when real product work demands it.

For a recent large project, two front-end developers requested to be added as collaborators to this repository—to inspect and reuse parts of the code.

This was also a wager. Could a small, Made-in-India product team use an AI-assisted workflow to build polished, clear and accessible interfaces without a much larger team—and without drifting away from the production stack? And would that work better than continuing to inherit the limitations of Grafana UI?

The answer is not a resounding yes—yet. But the proof of possibility is becoming visible.

From facelift to functional lift

So far, the most obvious change is a facelift: denser tables that remain readable, clearer hierarchy, quieter chrome, and interfaces that feel more considered. The more important work is the functional lift underneath it.

We have designed loading, empty, partial-result, failure and recovery states instead of treating the happy path as the entire product. Disabled actions explain themselves on hover. Drawers preserve or dismiss context deliberately. Columns in a table can be discovered, resized, reordered, pinned and restored without making the rest of the table unusable. Motion is no longer decoration; it confirms what changed, where it went, or why an action was refused.

Small interactions add up. In a complex observability product, they determine whether the whole thing feels predictable and trustworthy.

The Data Explorer became our main proving ground. VQL search went through several competing interaction models. Some were retained, some parked, some rebuilt and others explicitly deprecated.

The next question was whether the workbench could carry what it had learned into a different part of the product. Prototyping anomaly-detection configuration and alerting gave us somewhere to test that.

Every prototype added more than a screen. It added product knowledge the next prototype should not have to rediscover.

Designing in code changed the conversation

We have barely touched Figma in months.

That has been liberating. The prototype is the design: responsive, stateful, populated with realistic data and available for stakeholders to use rather than imagine. Reviews changed with it. Instead of asking people to interpret annotated frames, we could ask them to use the flow. Ideas can be judged where the difficult parts actually live—in overflow, latency, validation, navigation, focus, failure and recovery. The gap between describing an interaction and discovering whether it works has narrowed dramatically.

But leaving Figma exposed a weakness we have not solved.

Code remembers everything, but shows almost nothing

Our design record exists, but it is scattered. Some reasoning lives in code comments. Some lives in Markdown files written after a difficult decision. Some survives in conversations with an agent. The changelog captures important releases and decisions. Git remembers every commit.

None of these gives us the thing Figma provides, though: visual memory.

On an infinite canvas, the clean version, the rejected version and the strange in-between attempts can sit beside one another. Annotations remain attached to what they describe. The history is spatial, glanceable and only a scroll away. In code, a previous version may still exist in Git while being functionally invisible. Finding it requires knowing that it existed, locating the right commit, and reconstructing enough context to run it.

Our changelog is a meaningful first step. It records not just that something shipped, but increasingly why it behaves as it does. Still, prose and commit history cannot replace seeing two versions next to each other.

Our next experiment is to preserve meaningful demo versions on separate branches and link past variants from the Demos page. Not every iteration deserves to survive, but the ones that changed the product’s direction should remain directly runnable, with their annotations, decision logs and successors attached. The changelog then becomes a navigable gallery of product thinking.

That is the missing layer between an executable design system and a genuine workbench.

The workbench is the unfinished product

Today, vuDS* is still a proof of concept. It operates out of the terminal, its knowledge is incomplete, its documentation habits are inconsistent, and too much context still depends on knowing where to look—or whom to ask.

But the experiment has clarified what we are trying to build. It is not merely a component library, and not simply a faster way to make prototypes.

It is an institutional memory for the product: one that can explain our patterns, preserve our decisions, expose our discarded ideas, and turn all of that context into working software.

If we get it right, the designer’s job does not shrink to typing a PRD. It moves upward: framing the right problem, applying taste, challenging the generated stories, and deciding what deserves to become part of the product’s shared memory.

The goal remains prototyping at the speed of thought. The work now is making sure the workbench can remember how we got there.