How would you structure Figma files for a new design system?

WHAT THIS TESTS: This question tests three things that senior designers and design engineers get wrong constantly. First, do you understand Figma's memory model? Figma loads the entire file into RAM on open, so a monolithic file with thousands of components crushes performance for consumers and contributors alike. Second, do you understand library publishing and governance? Figma's shared libraries are file-level, meaning access control, versioning, and updates happen per file, not per component. Third, do you scale for team growth? A structure that works for three designers breaks at thirty.

A GOOD ANSWER COVERS: A strong answer proposes a multi-file architecture. One file for foundations: color styles, text styles, effect styles, and spacing primitives. A second file for icons and assets, because icon sets grow fast and are often maintained by a different team. A third file for components, sometimes split further by platform or domain if the system is large. Each file is published as a shared library. The rationale is explicit: Figma loads whole files into memory, so splitting limits what a consumer loads. Separate files also enable parallel ownership, granular version history, and targeted permissions. You might mention a dedicated documentation or playground file that consumes all libraries but publishes none, so designers see components in context without bloating the source files. If the system is tiny, a monolithic file is acceptable as a temporary starting point, but the answer must frame it as technical debt with a migration plan.

COMMON WRONG ANSWERS: The biggest red flag is a single monolithic file with no mention of memory limits or library publishing. Another red flag is splitting arbitrarily by page instead of by file, which does not solve memory or governance issues. Candidates who say it depends but cannot name the specific trade-offs—memory, load time, update granularity, permissions—sound vague. Also wrong: suggesting multiple files but publishing everything from one library, which defeats the purpose.

LIKELY FOLLOW-UPS: How would you handle cross-file dependencies, like a button component that uses a color style from the foundations file? How do you version and communicate breaking changes when libraries are separate? What happens when a designer opens a file that uses five different libraries—how do you manage library updates without notification fatigue? How would you structure this if you had native mobile and web components with shared tokens?

ONE CONCRETE EXAMPLE: At a mid-size SaaS company with eight product teams, you might create four files. Foundations: 40 color tokens, 12 type scales, 8 spacing values. Icons: 300 SVG icons as components. Web components: buttons, inputs, navigation. Native components: iOS and Android variants. Each file is published independently. A product designer working on the web app enables only the Foundations, Icons, and Web Components libraries, keeping memory low. When the native team updates a tab bar, web designers are not forced to accept irrelevant updates.