Skill This
AI Skill Report Card

Prototyping with Figma Make

B70·Sep 22, 2026·Source: Extension-page

Guide the process of taking design intent and turning it into a working, on-brand prototype in Figma Make by maximizing the design context provided before and during generation.

Quick Start12 / 15
  1. Open Figma Make, start a new Make.
  2. Attach context before writing the prompt:
    • Drag in a Figma frame (existing design to base the build on)
    • Attach a PDF (spec, brand guide, or reference doc)
    • Add a Make kit or npm package (design system components)
  3. Write a prompt describing the desired behavior, referencing the attached context explicitly (e.g., "Build this using the attached frame as the layout and the design system kit for components").
  4. Review generated output; iterate by adding more context (screenshots, additional frames) rather than only rephrasing text prompts.
Recommendation▾
Examples are somewhat abstract (describing outcomes narratively) rather than showing concrete prompt text and literal output artifacts (e.g., actual code snippets or specific file/component names) — add a real code diff or component tree output.
Workflow13 / 15

Progress:

  • Step 1: Gather design context (frames, PDFs, kits, packages)
  • Step 2: Attach context to the Make before prompting
  • Step 3: Write a specific, context-referencing prompt
  • Step 4: Generate and review output against design intent
  • Step 5: Iterate using targeted context additions or corrections
  • Step 6: Validate against design system consistency (spacing, tokens, components)

Step 1 — Gather design context Identify what's available: Figma frames (source of truth for layout/visual design), PDFs (specs, brand guidelines, requirements docs), and design system assets (Make kits published from a team library, or npm packages like a component library).

Step 2 — Attach, don't just describe Prefer attaching actual artifacts over describing them in text. A frame attachment gives Figma Make exact layout, spacing, and visual hierarchy; a kit gives it real component APIs and tokens instead of guessed ones.

Step 3 — Prompt with explicit references Reference each attachment by name/role in the prompt: "Use the Header frame for navigation," "Follow the brand PDF for color usage," "Use Button and Card from the design system kit." Vague prompts without pointing to attachments lead to generic output even when context is attached.

Step 4 — Review systematically Check: does layout match the frame? Do components use the kit's actual variants/props? Does copy/tone match the PDF spec? Flag mismatches specifically rather than saying "make it better."

Step 5 — Iterate with more context, not just words If output drifts from intent, add a screenshot of the desired state, attach an additional frame showing the missing detail, or re-attach a more specific PDF section — this resolves ambiguity faster than repeated text-only prompts.

Step 6 — Validate design system consistency Confirm generated components pull from the attached kit/package rather than inventing new styles. Check spacing units, color tokens, and typography match the system, not just visually "close enough."

Recommendation▾
Add more examples covering failure/iteration scenarios (e.g., what a bad generic output looks like vs. corrected output after adding context) to show contrast, since only success cases are given.
Examples10 / 20

Example 1: Input: A Figma frame of a settings page + prompt "Build this page, make the toggle switches functional and save state to local storage." Output: A working settings page matching the frame's layout exactly, with functional toggles wired to local storage, using whatever components were attached (or Figma Make's defaults if no kit was attached).

Example 2: Input: A PDF brand guide + npm package for a component library + prompt "Create a pricing page using our component library and following the brand guide for colors and typography." Output: A pricing page built from the actual imported components (Card, Button, Badge, etc.) with colors/fonts matching the brand guide, not generic placeholder styling.

Recommendation▾
Workflow and best practices/pitfalls sections have some redundancy (e.g., 'attach don't describe' repeated three times) — tighten to reduce overlap and shorten overall length.
Best Practices
  • Always attach source frames when one exists — never re-describe a design that's already been designed.
  • Name attachments explicitly in prompts ("the attached kit," "the brand PDF") so the model knows which artifact governs which decision.
  • Use Make kits/npm packages for anything requiring consistent, reusable components across multiple Makes.
  • Keep PDFs focused (specific spec sections) rather than dumping entire lengthy documents when only one section is relevant.
  • Iterate with visual context (screenshots, added frames) when text-only feedback isn't resolving the issue.
Common Pitfalls
  • Describing a design in prose instead of attaching the actual frame — leads to layout drift.
  • Attaching context but writing a generic prompt that never references it.
  • Assuming one kit attachment persists automatically across unrelated new Makes — reattach per project as needed.
  • Dumping an entire long PDF when only a small section is relevant, diluting focus.
  • Treating "close enough" visual output as done without checking actual token/component usage against the design system.
0
Grade BAI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
12/15
Workflow
13/15
Examples
10/20
Completeness
14/20
Format
14/15
Conciseness
13/15
Save to My Skills