Figma

Workflow

1. Build all reusable UI elements as components with variants before designing any screensDesigning screens with one-off frames means every global change - brand color update, button radius change - requires manual edits across every screen; components propagate changes from the main component to all instances automatically
2. Apply Auto Layout to every frame that contains text or variable-length contentFrames with absolute positioning do not adapt to content length; Auto Layout frames behave like CSS Flexbox and produce handoff specs that engineers can implement without guessing how the layout should respond to dynamic content
3. Define all colors, spacing, and radius as Variables before applying them to any componentHardcoded hex values in components require find-and-replace across every instance to update; Variables update everywhere from one edit and enable dark mode via variable modes without duplicating the entire design
4. Publish components from a dedicated shared library file, separate from project design filesComponents defined in a project file are only visible within that file; a library file shares components and auto-updates across all subscriber files - updates to the main component propagate to every product team's design file
5. Prototype key user flows in Figma and validate with a usability session before handing off to engineeringNavigation assumptions that feel obvious in static designs frequently need revision once tested on a clickable prototype; finding these before engineering starts costs hours, not sprint weeks
6. Add DO/DON'T usage notes inline in each component's description before publishing the libraryUndocumented components accumulate incorrect usage over time; inline documentation stays with the component and does not fall out of sync with a separate Notion page or design spec

Output Format

A production-ready component has: a meaningful layer name, Auto Layout with explicit gap and padding values, Variable-referenced colors and spacing, a complete variant set covering all states, and a component description with usage notes and DO/DON'T examples.

Component: Button/Primary
Auto Layout: horizontal, gap=8, padding=12 16, hug x hug
Variants: State [Default | Hover | Pressed | Disabled | Loading]
Variables: --color-primary (fill), --radius-md (corner), --space-md (padding)
Description: Use for the single primary action per screen. DON'T use two primary buttons side by side.

Examples

Edge Cases & Gotchas

• Component detached from the main - once detached, edits to the main component no longer propagate to that instance. Fix: right-click the instance and choose Restore main component to re-attach; detaching is permanent if the restore is not done before other edits
• Variables not included in library publish - Variables are not shared by default when publishing a library. Fix: in the Publish Library dialog, enable Include Variables; subscribers will not see the variables otherwise even if components use them
• Auto Layout overrides reset on main component update - instance-level padding or gap overrides are lost when the main component is updated in a way that resets those properties. Fix: use component properties for values that should vary per instance rather than overriding Auto Layout directly
• Frame vs Group vs Section confusion - Groups do not have fill or Auto Layout; Sections are for canvas organization only; Frames are the correct container for UI layout. Fix: audit with Layers panel - all layout containers should be Frames

When to Break These Rules

• Use absolute positioning for overlapping UI elements - badges on avatar images, tooltip anchors, modal overlays - where Auto Layout cannot express the layering relationship without a workaround
• Skip variants for one-off components used in a single place with a single state - the variant overhead is only worth it for components with 2+ states or 2+ usage sites

Reference Files

• src/data/skills/index.js - add skill entries here
• src/components/Skills/DocRenderer.js - renders this doc format