Skip to content
tezvyn:
Menu

How would you architect a Figma-to-code icon system?

MediumHow cards are made

Tests design-to-code systems thinking. Strong answers cover Figma variables as source of truth, automated API exports into transformed versioned packages, and strict naming taxonomy. Red flag: manual SVG exports and developers editing assets by hand.

What's really being asked

Cross-functional systems thinking between design and engineering. It evaluates whether you can treat visual assets as infrastructure rather than static files, establishing a source-of-truth pipeline that enforces constraints in Figma and automatically distributes clean, versioned assets to developers. Senior interviewers want to see knowledge of design tokens, component architecture, CI/CD for assets, and the socio-technical boundary between design teams and frontend code.

The full answer

First, Figma structure: use a dedicated library file with atomic icon components built from vector primitives tied to published styles and variables for stroke weight, corner radius, and color so that a single token change propagates globally. Second, naming conventions and metadata: enforce a strict taxonomy like category-size-variant so assets map directly to code imports. Third, automation pipeline: use the Figma REST API or a plugin to pull SVG or JSON on every design-system release, transform them via SVGO or a custom script to strip presentational attributes and apply currentColor, then commit to a versioned package in a monorepo or npm registry. Fourth, code consumption: developers import from a single icons package where React or Vue components are generated programmatically, ensuring the API surface matches the Figma taxonomy. Fifth, governance: establish a design-system council or PR checklist so new icons pass both design review and automated visual regression before publishing.

The mistakes people make

Treating Figma as a static asset dump where designers manually export PNGs or SVGs into Slack channels. Proposing to store raw SVGs directly in the product repo without a transformation step, which leads to bloat and inconsistent attributes. Suggesting developers manually tweak stroke weights in CSS after import, which breaks the source-of-truth contract. Ignoring the versioning problem by saying the design team will just tell engineers when things change.

What usually comes next

How do you handle responsive sizing when Figma frames are fixed? What is your rollback strategy if a batch of exported icons breaks rendering in Safari? How do you prevent designers from detaching instances and violating the stroke constraints? How do you handle animations if these illustrations need to be interactive?

A concrete example

Describe a pipeline where Figma variables define a 1.5 pixel stroke and 2 pixel corner radius. A scheduled GitHub Action calls the Figma API weekly, downloads all components tagged icon or illustration, runs them through an SVGO pipeline that enforces currentColor and removes hardcoded fills, then opens a pull request against the icons npm package. The frontend imports IconArrowRight16 from the company icons scope, which renders an SVG with CSS custom properties mapping back to the same design tokens used in Figma. When the design team updates the stroke variable to 2 pixels, the next pipeline run regenerates all assets and bumps the package minor version, and consuming apps update via automation.

Interview question

Which architectural decision best preserves the source-of-truth relationship between a Figma icon library and its frontend implementation?

  • a.Mapping Figma style variables to programmatically generated components that consume identical design tokensCorrect
  • b.Allowing developers to override stroke weights in CSS to handle one-off UI edge cases
  • c.Storing raw SVG files in the product repository so developers can edit paths by hand when requirements change
  • d.Having designers manually export PNG assets to a shared channel before every release
Why?

This keeps color, stroke, and radius values governed by Figma variables and propagated automatically into code. Option B is tempting because it solves local UI issues, but it explicitly breaks the source-of-truth contract by letting production code diverge from the design system.

Just read this? Test yourself on what you have been reading.

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on figma — each one lists the topics its interview covers.

See open roles