Spec-Driven UI Component Development
1. Specs are the central hub that connects design intent
- Specs are the reference point that synchronizes design intent across Figma, prototypes, code libraries, and documentation
- Rather than being a simple explanatory document, they are closer to an intermediate language that contains a component’s structure, rules, exceptions, and implementation contract together
- As design systems grow, they play the role of clarifying “where the real source of truth is”
2. Specs are divided into generated and authored forms
- Not all component information can be extracted automatically from Figma or code
- Generated Spec: Contains API, variants, styles, tokens, layout rules, and example information extracted from Figma and similar sources
- Authored Spec: Contains what a person must interpret through context and supplement in Markdown, such as accessibility, complex behavior, interactions, and exception handling
- Both specs are needed for AI agents or developers to understand components more accurately
3. The key is a multidirectional conversion architecture
- Since design intent can start in Figma, web prototypes, or code, specs must be able to move in multiple directions
- Figma → Specs: Extract component structure and properties into spec data through plugins, REST APIs, CLI, GitHub Actions, and similar tools
- Specs → Figma: Deterministically restore Figma components and assets based on spec data
- Specs → Prototypes: Connect to quickly verifiable prototypes by generating React scaffolds, CSS, TypeScript contracts, Storybook, and similar outputs
- Prototypes → Specs: Pull decisions and exceptions that arose during prototype implementation back into the specs to update the source of truth
4. The core of operations is version management and a cyclic structure
- If specs are to become the center of the real system, a way to manage changes and feedback is also needed
- Distinguish change units such as Breaking, Minor, and Patch so the team can understand impact
- Use ADRs to record architectural decisions and the process of agreement
- Monitor system status by analyzing information such as token usage, attribute models, and component dependencies
- It is important to create a virtuous cycle in which accessibility, behavior, and platform-specific exceptions discovered by developers are reflected back into upstream specs
