Spec-Driven UI Component Development
Deliver design intent from multiple origins across design, code and doc libraries
People encounter my specs tooling often first through the Specs Figma plugin that’s been around for years. They see it as a designer-to-engineer handoff helper. That’s understandable, since the plugin’s origin was “Select a component, automate production of a specifications document on Figma’s canvas.”
As AI emerged over 2024 and 2025, it became clear that agents and tools value the underlying data emitted in a structured, predictable schema. So I evolved the specs tooling to generate specs both via the Plugin API and Rest API interfaces, per component at for an entire library.
Yet, these narrower tools don’t necessarily convey how specs fits into a larger UI component production environment.
My work in 2026 builds further towards a single place where a design system records, evolves, projects, and synchronizes expressions of design intent. Specs serve as a hub for expressions across all the surfaces – Figma, prototypes, code libraries, docs – each a source of intent and a surface on which to render intent. To many, that probably sounds like THE source-of-truth. Well, kinda. It’s a place that normalizes, synchronizes, and versions the intent expressed across the many origins-of-truth.
Designers continue with design tools (mostly, Figma and “prototyping kits”) and engineers are expanding code factories to produce React, iOS and Android libraries. My current work provides a home for specs and translations across surfaces, building models and tools that contain design intent of components, tokens, icons and more. I make parts of a broader puzzle: tools (a Figma plugin, a command-line interface, agent skills), models (schemas, ADRs), and also still features (components and tokens) that help me grow as an architect.
I’ll sometimes blog, post or comment about a part in isolation. What’s missing is the broader picture, threading these parts with a designer’s expression in Figma or an engineer’s code factory. No one person or team owns everything. And we must agree on the edges that connect our parts. And the edges are where it gets hard.
This post maps the current specs architecture into which many emerging tools fit. I’ll start with specs: what they contain, how they are authored, and the sophistication we’ve grown into gradually. I’ll then expand on how specs connects into multiple design “origins-of-truth” (Figma and prototypes) and consuming code factories, with a break to ground the reader in the underlying architecture gluing those edges together.
About Specs
Spec serve as the hub of design intent as content to completely describe a component as best as we can. Our specs come in two flavors: generated through deterministic transformation versus authored by humans, agents or both. We favor generated over authored, and build tools that arc specs towards more generated outputs over time.
Generated specs
My specs focus is on component concerns, each extracted from Figma.
API declares component names, props and elements, serving as the exposed surface to configure and override it.
Variants declare layered rules (much like CSS) that declare the styles, tokens, prop bindings, slots, composition, layout, structure, and more. This data is complicated, rich, and best authored today solely in Figma.
Examples carries composed relationships via nested slots, content, and images leveraged for docs, test cases, and reusable scaffolds.
To learn more, try the Specs 2 Figma plugin and emit “Data” or visit the Specs site and follow the simple steps to generate specs for your library.
Authored specs
Figma can’t express every intent you have for a component. Therefore, it’s inevitable that generated outputs are paired with authored content to describe what’s left. Designers I work with don’t use Figma to express behaviors or accessibility. Additionally, Figma can’t express advanced layout and configurations like discriminated unions and other prop relationships.
Therefore, teams augment generated specs with authored supplemental requirements also stored in the specifications repo. Supplemental requirements can be general to all components (such as the precedence of disabled over read-only) as well as platform- and component-specific, stored in files like configurations.md or card.accessibility.android.md. Downstream agents and scripts find and filter requirements as needed.
Designers use agents and skills to research, analyze generated specs, author requirements, and post pull requests for teammates to review, comment and approve. Requirements are consistently formatted (often with MUST, SHOULD, COULD, …) and skills keep descriptions tight and consistent.
Notwithstanding the considerable Figma motion tools released at Config 2026, designers continue to express motion requirements via a combination of prototypes and supplemental requirements for now.
Foundations
Undoubtedly, design system specs are more than just components. Critically, components are served by foundations that include tokens, fonts, icons, images, and other product marks and assets.
Enterprise design systems build tools to store, publish, and manage these assets. Formats per type per enterprise vary. Sometimes it’s a repository consolidating all of them. Other times, it’s databases built with custom UI front ends to manage icons and theming tokens across countless brands.
While I’m involved in architecting relationships and taxonomies, they are highly variable across clients and worthy of a separate post.
Handling specs from multiple origins
Designers should express intent in whatever tool fits best and specs tools blend and normalize those expressions. These days, I encounter designers expressing intent in both Figma and web-based prototypes.
Imagine designing a date picker first in Figma and product card first in a prototyping kit. If intent starts in different places, the system must support porting that intent from one place to another quickly and precisely. It’s not just about generating specs based on an expression of design intent, but rendering that intent elsewhere too.
As a result, my work is expanding from one edge to four: from Figma to specs (existing), specs to Figma, specs to prototype code, and prototype code to specs.
From Figma to specs
Specs from Figma can be generated now in three ways:
Via plugin as designers build and review assets, producing an on-canvas report.
Via commands leveraging Figma’s Rest API via command line, Github action or LLM chat. Commands fetch files, scan for components marked
READY_FOR_DEVand generate a library’s worth of specs in less than a minute.Via bridge into the Figma file via the plugin UI generating specs based on a current selection.
Great care has been put into how multiple paths produce “byte-equivalent” (identical) specs whether from the Figma Plugin API or Rest API. These APIs are not the same, and thus require development (skills, fixtures, loops and harnesses) to sustain equivalent emission across both.
From specs to Figma
A specs render command leverages a bridge and a cache of system data to build a Figma asset from specs in complete detail: >50 style properties, props, tokens, Figma styles, prop bindings across variants, layout, and slots including default content.
render command rendering a component from specs to Figma in 1 secondSure, agents could do this. Yet, inference comes with costs and risks. Specs data is layered and complicated, and imprecision and loss through inference is inevitable. The solitary render script is deterministic, demonstrated through “round trips” (specs to Figma to specs) that prove specs remain byte-identical: no variant, style, element or layout choice is dropped or degraded along the way.
From specs to prototypes
The specs transform command scripts CSS, a TypeScript contract, React component scaffold, and Storybook stories. These leverage Figma authoring conventions for states and component and element-specific roles to generate behaviors beyond what Figma enables designers to author out of the box.
The code isn’t intended for production, although teams could use it as a fast-forwarded starting point to coding work. Nevertheless, the files are evolving to a point suitable as a starting point for an prototyping kit that need not wait for hardened testing or engineering capacity.
From prototypes to specs
A blend of agents and scripts will likely extract data from prototypes into specs.
Early concepts rely on well-scaffolded and organized code that separates “spec worthy” decisions from the platform-specific code specs can’t represent. For example, imagine separate generated.css, extensions.css and overrides.css to relate spec-generated choices to prototype-specific expressions. It’s early days, not everything is simple (particularly the layout tree itself), but results are promising.
These transformations must be lossless, cheap, and fast to scale, regardless of direction or expression surface. Until they are in place and reliable, we can’t pursue the bigger objective: reconciliation and synchronization across surfaces.
Architecting specs
Versions
Specs versions express the evolution of design intent over time. Each version is accompanied by change logs, change sets, and skill-derived release notes. These serve both to validate impact and intent (“Are these the changes we want?”) and communicate to consumers (“What’s different?”).
When specs can be validated against an explicit schema, you remove all doubt about what changes are major/breaking, minor or patch fixes.
Change or remove
<component name>.props.<prop name>? Breaking!Add a
<component name>.anatomy.<element name>? Minor.Bind a different token value to an element in a particular variant? Patch.
I am excited about a future where discussions of “Is this breaking or not?” shift from long, tedious debates relying on subjective taste to immediate, inarguable facts.
Schema
Specs content is delivered within an established schema. This enables us to describe the structure and relationships of all the different intent a system collects. Combining a schema with the content we put in it forms a contract by which any consumer of the specs can build predictably and absorb changes gradually.
For more, read Component Contracts and Schema and browse my Specs’ schema.
Architecture Decision Records (ADRs)
Schema, tools and models are evolved using architectural decision records, or ADRs. These documents record decisions in a format with structured sections:
metadata
context
problem
alternatives
decision
consequences
other concerns.
Authors use straightforward skills to create, implement, and update ADRs. Once initiated, authors work with LLMs using an ADR as the baseline to evolve. They’ll explore divergent ideas, express examples, challenge assumptions, and quickly converge on a recommendation. From there, teammates can predictably review, comment on and approve the familiar format.
While we started using ADRs to ground the schema first, the approach has expanded to cover wider architecture (design and code conventions and transformations, library and asset relationships, and more). Additionally, authors now commit to visions that organize many ADRs helping teams understand the scope and impact of work often spanning many system parts.
For juicy ADR examples, read layout positioning and sides and corners.
Analysis and monitoring
Specs rich with structured data offers ample opportunity to analyze and monitor how design intent is evolving. Every release, the specs analyze command autogenerates reports that itemize the library’s tokens and styling usage, props models, dependencies and “keys” (naming is hard for props and layers/elements). Each report pivots spec data to many perspectives, answering questions like:
Where is the
text-tertiarytoken used across components and elements?How do options available for
statevary across components?If I change the API of the
iconcomponent, what components are impacted?
No agent needs to call a library via MCP, extract and pivot the data themselves. Most questions are directly answered by the data on offer. Adding and generating more reports is extremely cheap, and 5-10 more are already on the docket.
Consuming specs
Once specs is populated with well-structured content, our downstream engineering partners consume it with ease.
From specs to code
Specs are consumed to build component code across platforms like React, iOS and Android. My engineer teammates are architecting and building subsystems:
Cross-platform factories that transform specs data and compare to existing code for things like CSS, contracts, and React TSX
Per-platform skills and workflows where humans and agents polish the components to completion together, grounded in specs data
Cross-platform learning capabilities to identify gaps, weaknesses and areas of improvement, including specs
Testing capabilities automate spec data like variants, content and examples to ease designer review and quicken validation passes
From code to specs and design
Engineers express design intent, too. As they work, they’ll evolve and extend API, identify and resolve accessibility issues, and fill behavior gaps designers hadn’t considered. That’s design work, just not done by a designer. Some choices already filter upstream into requirements that designers see and approve.
That work pushes how specs schema models sophisticated prop patterns, composition, behaviors and accessibility. My hope is that engineers “downstream” engage more and originate intent upstream, not just via requirements but also during planning and design.
Additionally, requests flow upstream from factories, workflows and learnings. These require changes across the ecosystem: schema, transformers, supplemental requirements and how components are built in Figma. I enjoy serving as trafficer, routing tickets to teammates and rapidly resolving them myself. The trafficer roles helps me see the system’s stability and where we can improve. Some parts hum along, others bend but stick together, and a few leak in ways smaller by the day.
From specs to docs? Some, but not much
Undoubtedly, specs inform docs but not so much so far . Specs are a record of names and change. Yet, prop tables and “how to use” React, iOS and Android originate more appropriately from coded implementations. Exhibit artwork remains generated from Figma assets.
Specs are far more about how to make the components well. The other content – how to use components – is really a separate enterprise driven by a partner team.
Where do we go from here?
Teams commit to supporting surfaces like Figma and prototypes for design, React, Android and iOS from development. These choices guide our focus and priority in optimizing how specs threads through each.
Yet, open questions remain:
Is there a future where designers express intent in prototypes but not Figma?
Will we reach a point where design intent can be transpiled across code implementations such that “designer” surfaces cease being valuable?
Can one code implementation serve as the predominant reference implementation other platforms derive from, or will all implementations remain peers to synchronize? Most but not all teams I work with would likely name their “most important” web-based implementation as their reference design.
Will AI just do it? 🤷🏻♂️
On that last point, maybe in a way I can’t visualize today. I believe our tools and systems must make our design intent visible, manageable, and verifiable. We need to make decisions, see their impact, and evolve our systems with intent.