1. Introduction
This document states what UI Designer must do to reach version 1.0: the product, its features, the file it edits, the command line surface that AI agents use, and the quality it must meet.
1.1 Purpose#
This document states what UI Designer must do to reach version 1.0: the product, its features, the file it
edits, the command line surface that AI agents use, and the quality it must meet. It is the reference for
planning (the requirements become items of planning.pb), implementation, testing and
acceptance.
1.2 Scope#
In scope for 1.0:
- A vector design editor for user interfaces: pages, frames, shapes, vector paths, boolean operations, text, images, fills, strokes and effects.
- Responsive layout: constraints, auto layout (flex and grid), layout guides.
- Design systems: components, variants, component properties, instances with overrides, styles, variables with modes, and libraries shared between files of the workspace.
- Prototyping: interactions, transitions, overlays, scrolling, variables in prototypes, and a preview player.
- Developer handoff: inspection, measurements, code snippets, design token export, asset export, and code generation into the workspace.
- A command line tool,
ud, with full parity with the editor. It offers the tools of the Figma MCP server under the same names and parameters, includinguse_figmawith a Figma Plugin API compatiblefigmaglobal, a markup language for building designs from text, and rendering to images so an agent can see its own work. - Claude Code skills, an MCP server with the Figma MCP tool interface, and VS Code language model tools for AI-driven design.
- Import from SVG, images, HTML pages and Figma files; export to PNG, JPG, WebP, SVG and PDF.
Out of scope for 1.0 (Appendix A): real-time multiplayer cursors over the network, a hosted cloud, FigJam-style whiteboarding, Figma Slides and Sites, video and animated GIF fills, a plugin marketplace.
1.3 Definitions and abbreviations#
| Term | Meaning |
|---|---|
| Design file | A .design file: one design document with its pages (FMT-001). |
| Node | Any object in the layer tree: page, frame, group, section, shape, text, component, instance, … |
| Frame | A container node with its own size, clipping, fills, layout and prototype behaviour. A top-level frame is a screen or artboard. |
| Component | A reusable node (the main component). Its copies are instances. |
| Component set | A component with variants, selected by variant properties (e.g. State=Hover). |
| Override | A property of an instance that differs from its main component. |
| Style | A named, reusable fill, text, effect or layout-grid definition. |
| Variable | A named value (colour, number, string, boolean) in a collection, with one value per mode (e.g. Light/Dark). |
| Auto layout | Layout of a frame’s children by rules (direction, gap, padding, alignment, sizing) instead of absolute positions. |
| Command | A named, parameterised operation in the command registry (section 3). Every user-visible action is one. |
| Action | A command that changes the document. It produces one or more events. |
| Event | One line of the write-append list (WAL) of the file. |
| Tool | One of the Figma MCP server’s tools (use_figma, get_metadata, …) as offered by ud and ud mcp (section 3.2). |
| Plugin API | Figma’s JavaScript plugin API. use_figma scripts run against a compatible figma global (section 3.3). |
| UDX | UI Designer markup: an HTML-like text form of a node tree (CLI-001 §7). |
| Agent | A program that drives ud, typically Claude Code. |
| WAL | Write-append list: the event log of the file (FMT-001 §5). |
| MoSCoW | Must, Should, Could, Won’t. |
1.4 References#
- Project Board file format 2.0 (
vscode-extension-project-board/docs/pb-file-format.md): the tree plus write-append list design that FMT-001 follows. - Project Board webview page contract (
vscode-extension-project-board/docs/webview.md). - Project Board licensing (
vscode-extension-project-board/docs/licensing.md). - Software Board requirements (
vscode-extension-software-board/docs.src/content/specifications/requirements.md). - W3C Design Tokens Community Group format (DTCG), 2025.10 draft.
- VS Code Custom Editor API, Webview API, Language Model API.
- Model Context Protocol, 2025-06-18.
- Figma MCP server, tools and prompts (
developers.figma.com/docs/figma-mcp-server): the tool interface that section 3.2 mirrors. - Figma Plugin API reference and
@figma/plugin-typings: the API that section 3.3 implements a subset of.
1.5 How requirements are written#
Each requirement has an ID (AREA-n), a statement with shall (Must/Should) or could (Could), a
priority (P), a type (functional, non-functional, constraint, interface), a verification method (Ver.:
test, demonstration, inspection, analysis) and the milestone (M) that delivers it (section 9). Where useful
a requirement ends with Done when: its acceptance criterion.
An exit criterion of a milestone (section 22) depends only on Must requirements delivered at or before that milestone; a Should or Could never gates a release.