From component library to working prototypes

Seven named tonal ramps at thirteen stops each. Nothing consumes a raw palette value. Semantic theme roles alias into the ramps, and every role carries an explicit light assignment and an explicit dark one, so a theme swap is a lookup rather than a redesign. Elevation is authored twice for the same reason.

The system needed success, warning, danger, and info roles alongside the Material 3 theme. We gave those roles explicit light and dark assignments in design and code, so individual screens did not have to invent status colors. Extending the base theme also created a maintenance obligation: future Material upgrades would need a reconciliation pass.

About 1,830 variables across nine collections. The split matters more than the count: primitives separated from semantics, semantics separated from component-state matrices, and one collection built purely to serve the codebase rather than the canvas. Component interaction state runs off variable modes instead of hand-built variants. A text input resolves fifteen bound properties across five modes, so the stroke walks from outline to primary to danger by state and the floating label is a boolean, with no duplicated variant holding either.

Code Connect maps one Figma button set to five Flutter symbols, including a named constructor. The mapping targets Flutter's ThemeExtension classes rather than bespoke wrapper widgets.

Dev Mode hands an engineer a standard Flutter button snippet. The design-system connection lives in the theme, so it is less obvious at the call site and must be checked in theme configuration. In exchange, engineers can use framework components without maintaining a parallel wrapper layer.

The spec board and the sandbox are deliberately separate objects. The master variant set is locked. Next to it sits a playground of roughly sixty rendered permutations including a disabled state for every style, because the question a developer actually has is not what the spec says, it is what this looks like when it is off.

The original sandbox opened on a single component example. Navigation sat behind a modal drawer, and components appeared as one long list. It exposed the library, but it did not orient a designer around what they were trying to accomplish, provide a place to review concepts, or show an AI assistant how the repository expected work to be structured.

I redesigned and coded the workspace end to end. A persistent rail separates Home, Components, Prototypes, and Skills. The home page starts with three outcomes: build product UI, explore a concept, or work with AI. That information architecture gives each activity a clear boundary while keeping the same design language and repository context visible across all three.

The Prototyping Studio registers source-controlled concepts with status, category, creator, contributors, and update history. Designers and other non-developers can generate a working concept, open it in a responsive preview canvas, resize across breakpoints, review comments, and inspect the files behind the experience. A prototype is no longer a detached mock or an unexplained branch. It is a reviewable team artifact aligned to production MDS components, with a route back to its source.

The Skills browser surfaces repository-specific instructions, required inputs, file locations, and creation steps for designers, developers, and AI assistants. Figma remains an available input when visual authoring is useful. The aim is to reduce repeated setup and translation work by making the same guidance available to everyone using the workspace.

The design system became a place to browse production patterns, test ideas as working software, and see the instructions an AI assistant would follow.

FORGE is the pipeline built on top. Three ingest paths converge on one representation: analysis of legacy screens, the proven path from Figma files already built out of MDS components, and an R&D path starting from prompt-generated HTML. All three produce the same enriched JSON. Per-component skill files are what the model reads, and those files are treated as source of truth rather than as prompt scaffolding.

The enrichment step filters tool-specific noise, preserves component identity and structure, and packages the MDS context needed to choose and configure production components. I framed this workflow around shared component instructions so the team could investigate generation quality without rewriting the system context for each attempt.

Which model runs is a controlled variable in the design rather than an implementation detail, so output can be compared across models instead of argued about.

Code Connect was wired and reporting connected. The artifact I can show is the panel rather than the figma.connect() source file, so that is the limit of the public evidence.

The redesigned workspace, Prototyping Studio, responsive preview canvas, and Skills browser were implemented as working, repository-backed tools. They give designers and developers one place to create and review concepts against the MDS component context used by coding assistants.

FORGE's enrichment path worked at prototype level. End-to-end Flutter generation was not feasible when I last worked on it, output quality had not been benchmarked, and adoption was not instrumented.

The next measurement step would be to track which teams create and review prototypes, how often they return, and where concepts stall. That would connect the implemented workflow to evidence of adoption before making a delivery-speed claim.