Figma: Local vs. Published Library Assets

WHY IT EXISTS To solve the problem of design inconsistency across large projects and teams. Without a shared, published source of truth, every file becomes a slightly different version of the design, leading to chaos in development and a fragmented user experience. Publishing creates a single, maintainable source for all design assets.

THE MENTAL MODEL An asset in Figma—like a component, style, or variable—starts its life as a 'local' asset, like a private draft. It only exists and can be used within the file where it was created. Publishing an asset is like moving it from your private sketchbook to a public, version-controlled gallery. Other designers can then 'subscribe' to this gallery, and you can push updates to them, which they can choose to accept.

HOW IT WORKS You create components, color styles, or variables in a designated 'library' file. Initially, they are local. From the Assets panel, you choose to publish the file as a library. Figma presents a list of all new or modified assets. You select which ones to include in the update and add a description of the changes. Once published, anyone with access can use these assets in their own files. When you later change a published asset, you must repeat the publishing process to release the update.

WHEN TO USE IT Use this for any element that needs to be consistent across multiple files or projects. This is the foundation of a design system. It's essential for core UI elements like buttons, icons, form fields, and global values like brand colors, spacing units, and corner radii (managed as variables).

WHEN NOT TO USE IT Don't publish assets that are highly specific to a single file or are purely experimental. If you're just exploring a concept in a scratchpad file, there's no need to publish its components. Publishing creates maintenance overhead; only publish what needs to be shared and standardized. You can also explicitly hide certain assets from being published if they are helper components meant only for internal use within the library file itself.

ONE CANONICAL EXAMPLE A team creates a file named 'Core UI Library'. Inside, they define a primary button component and a color style called 'brand-blue'. They publish the file as a library. A designer working on a new feature in a separate file can now access and use that exact button and color. Later, the system team updates the button's corner radius in the library file. They publish the update with the note 'Updated button radius to 8px'. The designer working on the feature gets a notification and can instantly apply the update to all instances of that button in their file.