Figma is the canvas of record. Dock is the interpretive surface around it. When a design agent generates four hero variations against a brief, Figma stores the frames and components, and Dock stores the brief row, the agent's rationale per variation, the reviewer's verdict, the timestamp, and the pointer back to figma_file_key plus figma_node_id. The source file is never duplicated. The decision history is never lost. The work surfaces as rows your team and your agents can both read, comment on, and act on tomorrow morning.
The split: canvas vs. interpretive layer
Figma, Adobe Creative Cloud, Sketch, Webflow, and Framer remain the system of record for the canvas itself: frames, layers, components, the design source files. Dock is the system of record for what the agent and the team interpret around that canvas: the brief, the review thread, the variation rationale, the approval status, the production-asset queue. Each Dock row carries a pointer to the platform record (figma_file_key, figma_node_id, webflow_collection_id, and the rest), plus agent identity, decision, reviewer, and timestamp. When the agent needs current state, it re-fetches from the Figma REST API rather than trusting a cached copy. Dock holds the persistent interpretive layer that survives across sessions and handoffs. This is the same pattern we use across the Dock-for-Design pillar.
The brief table
A Design Brief surface in Dock typically looks like this:
| brief_id | component | figma_file_key | figma_node_id | variations_generated | agent | reviewer | status | decision_at |
|---|---|---|---|---|---|---|---|---|
| BR-204 | Pricing hero | aBc12FxK8 | 142:8801 | 4 | Lyra (design agent) | jordan@studio | approved_v3 | 2026-05-28 14:02 |
| BR-205 | Onboarding empty state | aBc12FxK8 | 198:2244 | 3 | Lyra | priya@studio | revision_requested | 2026-05-29 09:41 |
| BR-206 | Checkout button family | dEf99PpL3 | 56:1190 | 6 | Lyra | jordan@studio | awaiting_review | 2026-05-30 08:15 |
Each row holds the brief text in a doc column, the rationale per variation in a child thread, and a link back to the exact Figma node. No screenshots get pasted into Slack. No decision lives only in a reviewer's head.
A worked workflow
A product manager files BR-206 by writing the brief into a Dock row. Lyra, the design agent, reads the row, fetches the existing checkout component from Figma using figma_file_key and figma_node_id, and produces six variations on a working branch. For each variation, Lyra writes a rationale paragraph into the row: contrast ratio, motion budget, the component-library token used, the accessibility tradeoff considered. Jordan opens the row, scans the rationales, comments inline on variations 2 and 4, and marks variation 3 as approved. The approval flips a status field. A downstream automation hands the approved variation to the production queue, where the Webflow publishing surface picks it up for the marketing site, gated by a two-key handshake before the page goes live.
The brief, the rationales, the comments, the verdict, the timestamp, and the actor identity all sit on one row. The Figma file is never modified by Dock. Dock holds the interpretation.
Why it matters
Attribution is the first reason. When a component decision goes sideways three months later, you need to know who proposed it, who approved it, what alternatives were considered, and which brief it answered. Dock rows preserve that chain. The same audit pattern shows up across agent audit and compliance work: the canvas tool is rarely the right place for a permanent decision log.
Handoff is the second. Design agents run in sessions. The session ends, the context evaporates, and the next agent or the next human walks in cold. A persistent brief table plus rationale thread means the next session starts oriented. The agent reads the open rows, fetches current Figma state via the API, and resumes. This is the same handoff pattern we describe in agent identity lifecycle.
The third reason is daily-driver experience. Designers do not want to leave Figma to file a brief, and they do not want to leave Figma to review a variation. Dock surfaces embed where the work happens. The interpretive layer sits next to the canvas without replacing it, and the component library surface stays the single source of truth for tokens.
Spin up a Design Brief surface in the Dock-for-Design pillar and connect a Figma file in under ten minutes.
FAQ
Does Dock store Figma files or duplicate the canvas?
No. Dock stores pointers (figma_file_key, figma_node_id) and interpretive content: briefs, rationales, reviews, approvals. The Figma file remains the source of record, and the agent re-fetches via the Figma REST API when it needs current state.
How does the agent know which Figma node a brief refers to?
The brief row carries the figma_node_id. The agent reads the row, calls the Figma API for that node, and works against the current canvas state rather than a cached snapshot.
Who has authority to approve a variation? The reviewer column on the brief row, which is checked against the workspace's reviewer policy. Approval flips the status field and triggers any downstream publish gate, including the two-key handshake for irreversible operations.
Can this connect to the broader design ops conversation happening at events like Figma Config? Yes. The interpretive-layer pattern is meant to slot under existing design-ops practice: briefs, reviews, component governance. Dock is the substrate, not a replacement for the canvas or the design system itself.