Building a Design System: Styles and Shared Libraries

Figma

Chapter 6 · Building a Design System: Styles and Shared Libraries

Chapter 5's own tip box pointed here directly: a design system is essentially an organized library of components, plus shared colors and text styles, reused consistently across an entire product rather than confined to a single file. This chapter covers exactly that — styles and libraries, the pieces that turn a single file's own components into something a whole team can share.

What a Design System Actually Is

A design system is a shared collection of styles and components — colors, typography, buttons, cards, navigation elements — used consistently across every screen and every file a team works on, so a product looks and behaves cohesively no matter which designer is working on which part of it.

Color Styles: Naming and Reusing Colors Consistently

A color style saves a specific color under a memorable name — "Primary Brand Blue," "Error Red," "Neutral Gray 400" — so it can be applied consistently by name rather than by re-entering a hex value each time. Updating a color style's own underlying value updates every element using that style throughout the file, the same propagation behavior Chapter 5's own components already established for shape and layout, applied here to color instead.

Text Styles: Consistent Typography Across a File

A text style bundles font, size, weight, and line height together under one named style — "Heading 1," "Body Text," "Caption" — applied consistently wherever that kind of text appears. This keeps typography visually consistent across many screens without needing to manually match font settings by eye each time a new text element is created.

Shared Libraries: Publishing Components Across Multiple Files

A library publishes a file's own components and styles so other files — other screens of the same product, or entirely separate projects — can use them too, staying live-linked back to that shared source the same way an instance stays linked to its own main component. A team's design system typically lives in one dedicated library file, published for every actual product file to draw from.

Keeping a Library Updated: Publishing New Versions

Updating a component or style inside the library file and publishing a new version pushes that update out to every file using the library, the same propagation Chapter 5 already described for a single file's own components — just extended across an entire team's worth of files rather than staying confined to one.

Design Systems in Penpot: Shared Libraries

Penpot supports the same shared-library model — publishing components and styles from one file for other files to draw from — under closely matching terminology, another instance of Penpot's own deliberate similarity to Figma making the underlying concept transfer directly.

Scope	What it covers
Local styles/components	Reusable within one single file only
Published library	Reusable across every file a team has access to
Color/text style update	Propagates to every use of that style, in every file using the library
Component update	Propagates to every instance, in every file using the library

These same styles feed developer handoff later

Chapter 9's own Dev Mode reads a design's actual color and text style values directly, translating them into the design tokens and code snippets a developer actually needs — which only works cleanly if the design was built from consistent, named styles in the first place, not one-off, unnamed values scattered throughout.

Having a design system doesn't prevent style drift on its own

It's tempting to assume that once color styles, text styles, and a shared library exist, consistency is automatically guaranteed from that point forward. A designer working quickly can still pick an unnamed, one-off color or manually set font properties instead of reaching for the established style — a small shortcut that, repeated across a team over time, quietly reintroduces the same inconsistency a design system was built to prevent. The tools enable consistency; keeping to them, chapter after chapter and file after file, is what actually delivers it.

Hands-On Exercises

Exercise 1

A company's brand color needs to shift slightly across every screen in a 20-file product. Using this chapter's own material, explain the correct way to make this change once rather than editing each file individually.

📄 View solution

Exercise 2

Over several months, a team notices that despite having a published color and text style library, several screens have started using slightly different, unnamed shades of the brand's own primary color. Using this chapter's own warning box, explain how this likely happened.

📄 View solution

Exercise 3

Explain, using this chapter's own material, why a color style update and a component update both "propagate," and how that behavior in a shared library differs in scope from the same propagation described for a single file in Chapter 5.

📄 View solution

Chapter 6 Quick Reference

A design system is a shared collection of colors, text styles, and components used consistently across a whole product
Color styles and text styles bundle values under a memorable name, propagating updates everywhere they're used
A published library extends this reuse and propagation across every file a team has access to, not just one
Design system values feed directly into Chapter 9's Dev Mode handoff — consistency here pays off downstream too
Having the tools available doesn't prevent style drift — consistency still requires actually using them every time