Design Systems, Libraries, and Tokens

Introduction

A polished interface is not created by placing attractive screens side by side. It is created by establishing a coherent visual and interaction language that can be applied repeatedly across screens, products, platforms, and teams. In Figma, this language is supported by styles, variables, components, component libraries, design tokens, naming conventions, documentation, and contribution rules.

A design system is therefore more than a collection of reusable buttons. It is an organised system of decisions, assets, rules, and practices that helps people design and build consistent experiences. For a certificate-level practitioner, the central skill is not merely knowing where to click in Figma. It is understanding how to structure design information so that changes can be made safely, efficiently, and collaboratively.

This chapter explains how to organise a small but scalable design system in Figma. It also considers governance, accessibility, versioning, documentation, and the practical limitations of systematisation.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish design systems, pattern libraries, component libraries, and style guides;
• organise Figma styles, variables, components, and component sets;
• explain the purpose of design tokens and token tiers;
• apply clear naming conventions;
• create a maintainable library structure;
• document component behaviour, states, and accessibility requirements;
• establish contribution and review rules; and
• evaluate the benefits and limitations of a design system in a practical project.

1. What Is a Design System?

A design system is a shared system of reusable design decisions and implementation guidance. It commonly contains:

1. Foundations: colour, typography, spacing, grids, elevation, iconography, and motion principles.
2. Tokens and variables: named values that represent design decisions.
3. Components: reusable interface objects such as buttons, inputs, dialogs, and navigation bars.
4. Patterns: combinations of components used to solve recurring problems.
5. Templates and examples: page-level arrangements and realistic use cases.
6. Documentation and governance: explanations, ownership, review processes, and change rules.

A style guide usually describes visual standards. A pattern library presents reusable interface patterns. A component library provides reusable assets in a design tool or code repository. A design system includes these elements but also connects them to principles, processes, and product decisions.

The distinction matters because simply publishing components does not guarantee consistency. A component without usage guidance can be misused; a token without a clear name can be misunderstood; and a library without ownership can become outdated.

2. Foundations in Figma

2.1 Styles

Figma styles store reusable visual properties. Common style types include:

• colour styles;
• text styles;
• effect styles, such as shadows and blurs;
• grid styles; and
• in some workflows, shared media or documentation references.

A style is useful when the same property is applied in many locations. If a brand colour changes, updating the shared style can update all dependent objects. However, styles alone are limited when a product requires themes, modes, or context-sensitive values.

A practical style name might be:

Colour / Brand / Primary

or:

Typography / Body / Medium

Names should describe meaning and hierarchy rather than the location where the style happens to be used.

2.2 Variables

Variables are named values that can be reused and changed according to context. They are especially useful for:

• light and dark themes;
• responsive or density modes;
• semantic colour roles;
• spacing and sizing values;
• Boolean settings; and
• content that changes across contexts.

For example, a semantic variable named color.background.surface may refer to a light value in one mode and a dark value in another. Components can use the semantic variable rather than directly using a raw colour value.

Variables should be selected according to the design tool’s supported data types and project needs. A colour variable stores colour; a number variable stores a numeric value such as spacing; a string variable stores text; and a Boolean variable stores a true-or-false state. A variable is not automatically a design token merely because it has a name. It becomes part of a token system when its purpose, naming, relationships, and governance are defined.

2.3 Components and Component Sets

A component is a reusable object with defined structure and behaviour. Examples include a button, checkbox, card, or navigation item. A component set groups related variants into a manageable system.

A button component may include properties such as:

• Type: primary, secondary, or tertiary;
• Size: small, medium, or large;
• State: default, hover, focus, disabled, or loading;
• Icon: none, leading, or trailing; and
• Label: editable text.

Variants should represent meaningful differences rather than every possible combination. Excessive variants create what is sometimes called a variant explosion, in which maintenance becomes difficult and users cannot easily select the correct option.

A well-constructed component generally has:

• a clear minimum and maximum use case;
• Auto Layout where appropriate;
• sensible resizing behaviour;
• accessible contrast and focus states;
• meaningful property names;
• predictable component dimensions; and
• documentation explaining when it should and should not be used.

3. Design Tokens

3.1 Definition and Purpose

A design token is a named representation of a design decision. Instead of recording only the value #2563EB, a token records a meaningful role such as color.action.primary. This separates the value from its purpose.

Tokens support consistency because they:

• reduce repeated manual decisions;
• make global changes safer;
• support themes and modes;
• connect design and code terminology; and
• make design decisions easier to audit.

A token can represent colour, typography, spacing, radius, border width, elevation, motion duration, or another controlled property. The token should have a defined type, owner, intended use, and status.

3.2 Token Tiers

A useful token structure contains three levels.

Primitive tokens are useful for maintaining a palette, but components should normally consume semantic tokens. If a button directly uses blue-600, changing the meaning of blue becomes difficult. If it uses color.action.primary, the underlying value can change without changing the component’s conceptual role.

Token relationships can be represented as:

For example:

button.primary.background → color.action.primary → blue-600 → #2563EB

This is not a mathematical equation; the arrows describe a dependency relationship. If the actual value changes, dependent references can be updated systematically.

3.3 Token Naming

A good token name is:

• descriptive rather than purely visual;
• consistent in word order;
• stable when the underlying value changes;
• easy to search; and
• understandable to both designers and developers.

Prefer color.text.secondary to gray-500 when the value represents secondary text. Prefer space.4 or space.md according to the project’s naming policy, but do not mix systems without a reason.

A naming grammar might follow this pattern:

category.role.variant.state

Examples include:

• color.text.primary;
• color.action.primary.hover;
• space.3;
• radius.card; and
• type.body.medium.

Names should not encode temporary implementation details such as a particular page name or the designer who created the token.

4. Organising a Figma Library

A small library may be organised into pages such as:

1. Read Me: purpose, ownership, release status, and contribution instructions.
2. Foundations: colour, type, spacing, grids, icons, and elevation.
3. Components: published components and component sets.
4. Patterns: common compositions such as forms or search controls.
5. Examples: realistic usage and edge cases.
6. Archive: deprecated material retained for migration reference.

The precise page structure may vary, but the structure should be predictable. Designers should not have to inspect every page to discover whether a component already exists.

Local and Published Libraries

A local component is available only in its current Figma file. A published library makes selected assets available to other files. Publishing should be treated as a controlled release, not as an automatic action.

Before publishing, check:

• component names and descriptions;
• variant and property names;
• Auto Layout and resizing;
• variable and style references;
• accessibility states;
• detached or accidental layers;
• deprecated components;
• documentation links; and
• change impact on existing files.

The goal is to publish stable, understandable assets rather than unfinished experiments.

5. Component Architecture and Composition

A component should be designed at the level at which a team can reuse and govern it effectively. Very small components, such as icons or labels, may be combined into larger components. Larger components should expose only the properties users need to change.

Component Anatomy

Consider a form field. Its structure may include:

• label;
• input container;
• placeholder or entered value;
• leading or trailing icon;
• helper text; and
• error or success message.

The component should model meaningful states, including empty, filled, focused, disabled, and invalid. A form field that displays only its default appearance is incomplete because it does not communicate how it behaves in use.

Composition Versus Duplication

Composition means building a larger pattern from smaller components. For example, a dialog may contain a heading, body text, buttons, and an icon. Duplication occurs when designers copy a component and independently edit each copy. Duplication may be appropriate for genuinely unique content, but it weakens consistency when it replaces a reusable component.

A practical rule is: create a component when the object has repeated structure, repeated behaviour, or a decision that should be governed centrally.

6. Documentation as an Operational Tool

Documentation should answer practical questions, not merely describe appearance. For each important component, document:

• purpose;
• appropriate use;
• inappropriate use;
• anatomy;
• properties and variants;
• states and interaction behaviour;
• content guidance;
• accessibility requirements;
• responsive behaviour;
• related components; and
• ownership and status.

Documentation can be placed in Figma descriptions, a dedicated documentation page, a team wiki, or a separate design-system website. The location matters less than discoverability and maintenance.

Good documentation uses examples. For a button, it should explain when a primary action is appropriate, whether labels should use sentence case, how long labels should be, and what happens during loading. It should also show disabled and focus states rather than presenting only the default state.

Documentation must be version-aware. If a component is changed from Input v1 to Input v2, the team needs migration information, not simply a new visual sample.

7. Naming Conventions and File Hygiene

Naming conventions reduce search time and ambiguity. A consistent scheme should apply to:

• files;
• pages;
• frames;
• components;
• variants;
• properties;
• styles;
• variables; and
• documentation headings.

Use a consistent case convention, such as sentence case for human-facing labels and lowercase dot notation for tokens. Avoid unexplained abbreviations. Names such as Btn_Prim_2 may be short but are difficult to interpret and search.

File hygiene also includes:

• removing unused drafts from published pages;
• grouping related objects logically;
• avoiding unnecessary nesting;
• identifying experimental work clearly; and
• maintaining a visible archive for deprecated assets.

Clean organisation is not cosmetic. It reduces selection errors, supports onboarding, and lowers the risk of publishing an incorrect asset.

8. Contribution and Governance Rules

A design system requires governance because every addition creates a maintenance obligation. Governance need not be bureaucratic, but it should clarify who may propose, review, publish, deprecate, and remove assets.

A lightweight contribution process is:

1. Identify the problem: explain the user or product need.
2. Search existing assets: demonstrate that an existing component cannot solve the problem.
3. Propose the change: include visual examples, behaviour, states, and accessibility considerations.
4. Review: obtain design, product, accessibility, and—where relevant—engineering feedback.
5. Build and test: create the component and test it in realistic contexts.
6. Document: add usage guidance and migration information.
7. Release: publish with a clear status and change description.
8. Monitor: observe adoption, defects, and requests for revision.

A contribution rule should define when to use an existing component, when to extend it, and when to create a new one. Teams should avoid creating near-duplicates merely because a component has a minor visual difference.

Status and Versioning

Useful statuses include:

• Draft: under development and not approved for production;
• Ready for review: awaiting formal feedback;
• Ready: approved for use;
• Deprecated: still available temporarily but should not be used for new work; and
• Retired: removed or unavailable.

A change is usually minor when it improves documentation or adds a backward-compatible option. It is more significant when it changes structure, removes a property, changes meaning, or may break existing designs. The exact versioning scheme may differ, but the principle is stable: communicate changes according to their likely impact.

9. Accessibility and Ethical Responsibilities

A design system can improve accessibility by making accessible decisions reusable. It can provide sufficient colour contrast, visible focus indicators, error messaging patterns, touch-target guidance, and semantic interaction states.

However, a library does not guarantee accessibility. Designers must still assess context, content, motion, reading order, keyboard behaviour, and assistive-technology requirements. A colour token that passes a contrast check for large text may not pass for small text. Therefore, usage rules should specify the conditions under which a token is valid.

Ethical responsibilities include:

• avoiding exclusionary defaults;
• supporting localisation and varied reading directions where required;
• not hiding important limitations behind polished visuals;
• documenting accessibility defects honestly; and
• ensuring that governance includes diverse user perspectives.

Design systems also influence organisational power. If only one team can change the system, other teams may be unable to address legitimate user needs. Governance should therefore balance consistency with responsible local adaptation.

10. Technology, Automation, and AI

Design tokens can support handoff between Figma and code through documented mappings or token exchange workflows. Automation may help identify inconsistent values, generate documentation, detect unused assets, or compare library versions. These tools are useful when their outputs are reviewed by people.

AI can assist with naming suggestions, component inventories, documentation drafts, and audits for repeated patterns. It should not be treated as an authority on accessibility, brand appropriateness, user research, or legal compliance. AI-generated changes require human review, especially when they affect colour meaning, content, personal data, or inclusive design.

Automation also introduces risks. A script that replaces a colour globally may alter a warning state, brand element, and decorative object inappropriately. Before automating a change, establish scope, dependencies, rollback procedures, and review criteria.

11. Illustrative Case: The Northstar Learning Portal

The following is a fictional illustrative case.

Background

Northstar Learning Portal is a small education service with three designers. Over eighteen months, the team produced inconsistent buttons, form fields, spacing, and alert messages across student and administrator interfaces.

Problem

The same primary action appeared in four colours. Designers used different names for similar text styles, and developers received screenshots rather than shared decisions. A change to the brand colour required editing many screens manually.

Analysis

An inventory identified 37 button-like objects, 12 text treatments, and 9 alert variations. Many differences were accidental rather than intentional. The team decided not to standardise every visual detail immediately. It prioritised actions, form fields, alerts, typography, colour roles, and spacing.

Approach

The team created:

• primitive colour variables for the approved palette;
• semantic variables such as color.action.primary and color.feedback.error;
• a small spacing scale;
• a button component set with type, size, state, and icon properties;
• a form-field component with validation states;
• a Read Me page and contribution template; and
• a monthly review session with design and engineering representatives.

They deprecated duplicate buttons rather than deleting them immediately. Existing files were migrated in stages, and each release included examples and known limitations.

Outcome

New screens used a smaller set of approved components, and brand-colour updates could be made through controlled variable changes. Designers spent less time rebuilding common controls. However, the team discovered that some administrator workflows required denser layouts than student workflows. The system therefore introduced a documented density mode instead of forcing one universal spacing arrangement.

Learning Points

The case demonstrates that a design system should begin with high-value repeated problems, not an attempt to model every interface possibility. It also shows that consistency is not identical to uniformity. A governed exception may be better than an unsuitable universal rule.

12. Challenges and Limitations

Design systems create value, but they also create costs.

Maintenance Cost

Every component requires review, documentation, testing, and support. An unused component is not evidence of maturity; it may be evidence of unnecessary complexity.

Over-standardisation

A system can restrict exploration if designers treat existing components as the only permitted solutions. Early concepts may require temporary alternatives. The team should distinguish exploration from production and provide a safe route for proposing new patterns.

Local Context

Different products, cultures, platforms, and user groups may require different interaction patterns. A shared foundation can support consistency while allowing contextual variation.

Technical Drift

Figma assets and production code may diverge. A design library is not automatically the source of truth for implementation. Teams should define how discrepancies are reported, prioritised, and resolved.

Adoption Problems

People may bypass a library if it is difficult to find, slow to use, poorly documented, or unable to meet real needs. Adoption should be improved through education, quality, searchability, and responsive governance—not through enforcement alone.

Best-Practice Checklist

Before publishing a library update, confirm that:

• the change solves a defined problem;
• existing assets were reviewed first;
• names follow the agreed grammar;
• values use the correct styles or variables;
• variants represent meaningful states;
• components resize predictably;
• accessibility requirements are addressed;
• documentation includes correct and incorrect use;
• deprecated assets have migration guidance; and
• an owner and review date are recorded.

Chapter Summary

A design system is a coordinated set of foundations, tokens, components, patterns, documentation, and governance practices. Figma styles provide reusable visual properties, while variables support contextual values and modes. Design tokens give names and meaning to design decisions, especially when semantic tokens are separated from primitive values.

Reusable components should expose meaningful properties, model realistic states, and use composition rather than unnecessary duplication. Libraries require clear organisation, naming conventions, documentation, versioning, and contribution rules. Accessibility must be built into the system but still evaluated in context. Automation and AI can support inventory, documentation, and auditing, but human review remains essential.

The most effective design systems are neither uncontrolled collections of assets nor rigid rulebooks. They are maintained products that balance consistency, flexibility, accessibility, and the needs of the people who use them.

Key Terms

Design system: A coordinated system of design decisions, assets, guidance, and governance.

Style guide: Documentation of visual and sometimes interaction standards.

Pattern library: A collection of reusable interface patterns.

Component library: A shared collection of reusable design components.

Component: A reusable interface object with defined structure and behaviour.

Component set: A group of related component variants.

Variant: A controlled version of a component representing a meaningful difference.

Variable: A named value that can change according to context or mode.

Design token: A named representation of a design decision.

Primitive token: A token containing a foundational or raw value.

Semantic token: A token describing the functional meaning of a value.

Alias: A reference from one token or variable to another.

Auto Layout: A Figma layout feature that supports structured resizing and spacing.

Governance: The rules and responsibilities used to manage a design system.

Deprecation: The formal indication that an asset should no longer be used for new work.

Documentation: Guidance explaining an asset’s purpose, behaviour, and use.

Variant explosion: Excessive growth in component combinations that makes maintenance difficult.

Design debt: Accumulated inconsistency or maintenance cost caused by weak design decisions.

Contribution rule: A guideline governing how changes are proposed, reviewed, and released.

Review Questions

Short Answer Questions

1. What is the difference between a component library and a design system?
2. Why are semantic tokens generally preferable to direct primitive-token use in components?
3. Name four properties that may be included in a button component set.
4. What information should component documentation contain?
5. Why should deprecated components not always be deleted immediately?

Long Answer Questions

1. Explain how styles, variables, tokens, and components work together in a Figma design system.
2. Describe a practical structure for organising a Figma library and justify the purpose of each major section.
3. Discuss how naming conventions influence searchability, collaboration, and long-term maintenance.
4. Explain a lightweight contribution and governance process for a small product team.
5. Evaluate the benefits and risks of standardising accessibility decisions in a design system.

Analytical / Application Questions

1. A team has six visually different buttons across three products, but user research shows that only primary, secondary, and destructive actions are needed. Design a migration plan using tokens, component sets, documentation, and deprecation.
2. A dark theme requires different surface and text values, while the component structure remains unchanged. Explain how variables and semantic tokens could support the theme without duplicating every component.
3. A library is technically complete but designers avoid using it because components are difficult to find and do not support realistic edge cases. Analyse the likely causes and propose three governance or design improvements.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a design token?

A. A screenshot used to demonstrate a finished interface

B. A named representation of a design decision

C. A private note written by a developer

D. A frame containing several unrelated components

Correct Answer: B. A named representation of a design decision

Question 2

Which token is most clearly semantic?

A. blue-600

B. gray-100

C. color.action.primary

D. #2563EB

Correct Answer: C. color.action.primary

Question 3

What is the main purpose of a component set in Figma?

A. To store unrelated project files

B. To group related component variants

C. To replace all documentation

D. To prevent components from being reused

Correct Answer: B. To group related component variants

Question 4

Which practice best supports theme switching?

A. Applying raw colours separately to every screen

B. Using semantic variables with different modes

C. Deleting components for each new theme

D. Using screenshots instead of variables

Correct Answer: B. Using semantic variables with different modes

Question 5

Which item is most appropriate for a component’s documentation?

A. The designer’s personal password

B. Only the component’s default colour

C. Purpose, states, properties, and accessibility guidance

D. A list of unrelated project deadlines

Correct Answer: C. Purpose, states, properties, and accessibility guidance

Question 6

What does deprecation normally communicate?

A. The asset is recommended for all new work

B. The asset should no longer be used for new work

C. The asset has never been reviewed

D. The asset must be duplicated immediately

Correct Answer: B. The asset should no longer be used for new work

Question 7

Which problem is associated with variant explosion?

A. The component becomes easier to govern automatically

B. The number of combinations becomes difficult to maintain

C. Documentation becomes unnecessary

D. The library requires fewer decisions

Correct Answer: B. The number of combinations becomes difficult to maintain

Question 8

Which action should normally occur before publishing a library update?

A. Delete all previous components without review

B. Check names, properties, states, dependencies, and documentation

C. Convert every component into a screenshot

D. Remove accessibility states to simplify the library

Correct Answer: B. Check names, properties, states, dependencies, and documentation

Question 9

Why are primitive tokens often separated from semantic tokens?

A. To make raw values impossible to change

B. To separate foundational values from their functional meaning

C. To prevent themes from being created

D. To eliminate the need for component documentation

Correct Answer: B. To separate foundational values from their functional meaning

Question 10

Which statement about accessibility in a design system is most accurate?

A. A published component is automatically accessible in every context

B. Accessibility is relevant only to developers

C. Reusable accessible decisions help, but context still requires evaluation

D. Accessibility can be replaced by attractive visual design

Correct Answer: C. Reusable accessible decisions help, but context still requires evaluation