Figma Make design system: define context and verify generated UI

The official Figma material frozen on August 6, 2026 presents Make as a prompt-driven tool for producing and iterating on code-backed interfaces. The dedicated Make page names several ways design context may enter the workflow, including Make kits, npm packages, attached frames or PDFs, codebases, and design assets. This supports a context-governance workflow. It doesn't establish that every source has the same authority, maps to the same generated properties, or remains synchronized after generation.

Feature status needs the same caution. The captured Make material labels a local-codebase workflow as coming soon, so don't write a project plan that treats the route as already available. Before running a real project, check Figma's current documentation and interface for plan requirements, controls, supported inputs, and release status.

A useful context record answers a simple forensic question: what did Make actually receive for this generation? List the artifact itself, not a vague category such as "our design system." Give it an owner and a version. State which decisions it may make, and mark every missing decision explicitly.

Create separate entries for separate artifacts. A frame may demonstrate composition, while a package may expose components or tokens. A PDF may explain intent. A codebase may contain the current implementation. None should silently inherit authority from another simply because both were attached to the same project.

Context package ID: FM-DS-2026-08-06-01
Generation ID or link: [record after creation]
Prepared by: [name]
Prepared at: [date and time]

Source item: [Make kit | npm package | frame | PDF | codebase | design asset]
Name: [exact artifact name]
Owner: [person or team]
Version or immutable reference: [version, revision, commit, or dated snapshot]
Authority: [authoritative | derived | reference-only]
Intended use: [tokens, components, composition, behavior, imagery, or guidance]
Decisions it may override: [explicit list or none]
Known omissions: [explicit list]
Evidence status: [documented | supplied | mapped | observed | unresolved]

Conflict rule: [which source wins and who decides]
Project-local exceptions: [IDs or none]
Protected surfaces: [surfaces generation must not change]

Consistency problems become expensive when a team patches the visible screen before locating the decision that produced it. Five layers keep cause and symptom separate. One layer may supply evidence about another, but that doesn't automatically make it authoritative.

Set a fixed precedence rule for disagreements between layers. An explicit approved exception may override the general source within its named scope. Everywhere else, the authoritative design decision wins. Generated output and rendered appearance don't become policy merely because they exist.

The context register records what Make received. The context contract defines what the generation must preserve. Write both before generation so a plausible first screen can't redefine success after the fact.

• Allowed components and variants, including whether new components may be invented.
• Semantic color roles for backgrounds, text, controls, borders, focus, status, and data display in each required mode.
• Typography families, roles, available weights, scale, line-height rules, and prohibited treatments.
• Spacing and layout constraints, including density, container behavior, alignment, and responsive priorities.
• Required interaction states such as default, hover, focus, disabled, loading, empty, and error.
• Protected surfaces that must remain unchanged during the generation or revision.
• Approved local exceptions, each with scope, reason, owner, and review condition.
• Non-goals, including features, redesigns, data changes, or visual directions outside this generation.
• Evidence owner and the conditions for accept, revise, or block.

Context contract ID: FM-CONTRACT-01
Authoritative source: [name and version]

Allowed components: [list]
Allowed variants: [list]
Semantic roles and modes: [reference or bounded list]
Typography contract: [families, roles, weights, scale]
Spacing and layout: [constraints]
Required states: [list]
Responsive conditions: [representative widths and expected adaptations]
Protected surfaces: [list]
Approved exceptions: [IDs or none]
Non-goals: [list]

Accept when: [observable conditions]
Revise when: [correctable failures with known owner]
Block when: [missing authority, critical task failure, or unsafe unresolved change]
Evidence owner: [name]
Decision owner: [name]

Ambient Sage is a concrete example of what the source side can contain. Its public kit page records DESIGN.md guidance, semantic light and dark roles, typography, layout direction, motifs, and implementation exports. The published typography assigns Plus Jakarta Sans to heading and body roles and JetBrains Mono to technical strings. Its visual direction uses warm sage surfaces, restrained saturated yellow, generous rounding, and a compact product-oriented type scale.

For this example, a bounded source entry can identify Ambient Sage version 1 as authoritative for the proposed visual direction and note that its public artifacts are available for inspection. Every Make-specific field stays unresolved until someone runs and records the workflow.

Source item: Identity Forge Ambient Sage
Version: v1, public page updated July 30, 2026
Authority: proposed upstream design direction
Documented contents: DESIGN.md guidance; semantic light and dark roles; typography; spacing and layout direction; motifs; implementation exports

Figma Make ingestion: unresolved
Destination mapping: unresolved
Component compatibility: unresolved
Mode propagation: unresolved
Synchronization after change: unresolved
Generated-code quality: unresolved
Rendered parity: unresolved

After generation, freeze the output under review. Record its generation identifier, time, input package, prompt or instruction revision, and any manual edits. If someone changes a button color, responsive rule, or component afterward, put that change in the exception record. It shouldn't quietly rewrite the context contract.

Keep each exception narrowly scoped. "Mobile is different" is too vague to review. "Checkout summary uses a stacked layout at the agreed compact viewport because the price breakdown cannot fit without truncation" names a testable difference. Record who approved it and which general rule it overrides.

Exception ID: EX-04
Surface: [screen and component]
Condition: [state, mode, viewport, or product condition]
General rule overridden: [contract reference]
Replacement decision: [exact behavior or visual rule]
Reason: [project-specific need]
Approved by: [owner]
Evidence required: [observation]
Status: [proposed | approved | rejected | superseded]

Don't review every screen with equal depth, but don't approve the system from one polished default state either. Select representatives that expose different failure types: a dense screen, a form, a navigation surface, a destructive or high-risk action, a narrow layout, and any screen where light and dark behavior diverge.

For every cell you inspect, record an observation rather than a judgment alone. "Looks inconsistent" is difficult to route. "Compact checkout uses a raw gray value for secondary text instead of the registered muted text role" identifies the surface, condition, observed value, expected rule, and likely ownership layer.

Observation ID: OBS-12
Screen or flow: [name]
Component or region: [name]
State: [default, hover, focus, disabled, loading, empty, error]
Mode: [light or dark]
Viewport condition: [wide, intermediate, compact, or exact width]
Expected source rule: [contract reference]
Observed result: [specific result]
Evidence: [screenshot, recording, code reference, or test result]
Protected surface affected: [yes or no]
Likely owning layer: [1, 2, 3, or 4]
Correction owner: [name]
Disposition: [pass | revise | block]

Start diagnosis at the earliest layer capable of producing the symptom. If the authoritative source never defines an error state, another prompt can't reliably repair the policy gap. If the source is clear but the context package omitted the rule, fix the package. If Make received the rule and generated a conflicting local value, correct or regenerate the output. When an approved exception applies, update the evidence and keep its scope narrow.

The final disposition applies to the frozen output and evidence set. It isn't a permanent judgment about Figma Make or the design system. A later generation, source revision, or exception creates a new review subject.

• Accept when the in-scope tasks work, required states and modes have representative evidence, observed results trace to the declared source or approved exceptions, and protected surfaces remain unchanged.
• Revise when the failure is material but bounded, the correction owner and layer are known, and the artifact can be rechecked without redefining the contract.
• Block when authority is missing, a critical task or required mode fails, protected surfaces changed unexpectedly, the reviewed artifact cannot be tied to its inputs, or a material inconsistency has no owner.

Decision record ID: FM-DECISION-01
Reviewed output: [immutable generation or artifact reference]
Context package: [ID and version]
Context contract: [ID and version]
Evidence set: [observation IDs]
Approved exceptions: [IDs or none]
Unresolved material findings: [IDs or none]
Protected-surface result: [unchanged | changed | not verified]

Disposition: [ACCEPT | REVISE | BLOCK]
Reason: [specific evidence-backed statement]
Required corrections: [finding, layer, owner]
Recheck scope: [screens, states, modes, viewports, protected surfaces]
Decision owner: [name]
Decision date: [date]

For the first real run, choose one representative flow and complete every record from source to decision. Don't begin by expanding the prompt. First name the authoritative source, freeze the supplied context, and define the evidence required to accept the result.

• Figma Make: Create with AI-Powered Design Tools: The captured official page presents Figma Make as a prompt-driven, code-backed generation and iteration surface. It also names several forms of design context, including Make kits, packages, frames, documents, codebases, and design assets.
• Figma: The collaborative canvas for design, code, and AI: Figma's captured homepage connects shared design context with consistent building across design, code, and AI workflows.
• What is Figma?: The official help article places Figma Make within the broader Figma product family and describes its role in creating functional prototypes, web apps, and interactive interfaces.
• Figma Design: The captured official Design page establishes Figma Design as an upstream surface for interface design, prototyping, design-system work, collaboration, and handoff.
• Figma UI design tool: The captured official UI-design page describes interface design, prototyping, libraries, collaboration, and handoff as relevant parts of the wider workflow.
• Ambient Sage Design Kit: The public Ambient Sage page documents a free kit with DESIGN.md guidance, Plus Jakarta Sans and JetBrains Mono roles, a 31-color palette, and 28 semantic light and dark tokens.