Design System Guide. Chapter 1. Introduction

Design systems did not appear suddenly, nor were they the result of a trend toward scaling or corporate processes. They emerged as a logical continuation of the evolution of tools that teams used to maintain interface consistency.

Early digital products relied on Style Guides, UI Kits, and sets of visual rules. These approaches worked well while interfaces remained relatively compact and the number of screens, states, and scenarios was limited. A Style Guide described the visual language, a UI Kit enabled the reuse of elements, and the rules remained manageable within small teams.

As products and teams grew, the situation began to change. The number of screens increased, scenarios became more complex, and interfaces evolved in multiple directions at once. Style Guides and UI Kits still existed, but they no longer covered all the decisions being made. More and more questions moved beyond visual appearance and into behavior, states, and interactions.

At this point, the design system became the natural next step. It brought together UI Kits, Style Guides, and their associated rules, enriching them with principles, constraints, and decision-making processes.

The design system did not emerge as an attempt to standardize visual appearance, but as a way to capture and connect decisions that had previously existed in isolation.

A design system does not exist on its own and does not belong to a single role.
It is used, interpreted, and evolved by different participants in the process, each viewing it from their own perspective.

One common mistake is to look at a design system only from the perspective of visual design or only from the perspective of implementation. As a result, the system becomes either declarative or overly technical.

For a design system to remain resilient, each of its parts must be considered through the lens of the roles that work with it.

In practice, a single project most often involves three key roles:

• system designer
  
• product (or interface) designer
  
• developer
  

In more mature systems, additional participants are involved. Below is an overview of the roles that may take part and what each of them is responsible for.

System Designer

The system designer is responsible for the integrity and logic of the system.

Their focus is not on individual screens or even specific components, but on:

• the system’s principles and constraints
  
• decision-making rules
  
• the sustainability of decisions as the system scales
  

The system designer defines the boundaries:

• which patterns are allowed
  
• where the limits of variability lie
  
• which decisions are considered exceptions and which are part of the system
  

They work at the level of abstractions: tokens, principles, component architecture, and the relationships between system layers.
For them, it is essential that the system can evolve without losing predictability.

Product / Interface Designer

The product designer works with the design system as a tool for solving problems.

Their focus includes:

• assembling interfaces from existing components
  
• choosing allowed variants and states
  
• following system rules in real-world scenarios
  

For this role, the design system:

• speeds up work
  
• reduces the number of decisions made from scratch
  
• helps avoid accidental deviations
  

The product designer is the first to encounter the system’s constraints in real cases. Through their work, it becomes clear:

• where the system is overly rigid
  
• where components or states are missing
  
• where rules are unclear
  

They are an important source of feedback for the evolution of the system.

Developer

The developer perceives the design system as a contract between design and code, but their role is not limited to implementing components.

In addition to using ready-made solutions, the developer is responsible for how the design system is translated into the code environment.

Their focus includes:

• predictability and repeatability of decisions
  
• alignment between design and implementation
  
• scalability and system maintenance
  
• transformation of design tokens from Figma into code
  

The developer participates in defining:

• token formats (JSON, CSS Variables)
  
• naming conventions and structure
  
• build and transformation stages
  
• the mapping between semantic tokens and their technical implementation
  

At this stage, decisions are made about:

• which tokens are the source of truth
  
• which transformations are allowed
  
• how themes, modes, and platform differences are handled
  

If this layer is designed incorrectly, the design system loses cohesion: design and code begin to diverge even if visual consistency is preserved.

With a well-structured process, the developer:

• minimizes manual adjustments
  
• reduces the risk of mismatches between Figma and code
  
• ensures system resilience during changes and scaling
  

Thus, the developer works not only with components, but also with the infrastructure of the design system, ensuring its reproducibility and long-term support.

Additional Roles

As the system grows, other roles may also become involved:

Design Ops / Design System Manager
Responsible for processes, documentation, versioning, and system adoption across teams.

Product Manager
Views the system through the lens of development speed, risks, and impact on product metrics.

QA / Accessibility Specialist
Evaluates the system in terms of reproducibility, accessibility, and correctness of states.

Content Designer / UX Writer
Works with textual patterns, tone of voice, and communication consistency.

Why Roles Matter

The same part of a design system can look different depending on the role:

• a principle, as a constraint
• a component, as a tool
• a token, as a technical abstraction
  

If a system is described from only one perspective, it inevitably loses value for others.

That is why each part of a design system should be considered in terms of:

• who makes decisions
  
• who uses the result
  
• who is responsible for maintenance and change
  

A design system is not a single artifact, but a shared space of agreements between roles.

The clearer these roles and expectations are, the more resilient the system becomes in the long term.

When a product expands, it is not only the number of screens that changes. The nature of decisions changes as well.

The same questions begin to be answered differently:

• what is considered a primary action versus a secondary one
  
• what an interactive element looks like
  
• how users interpret loading and error states
  
• where the boundary lies between visual style and functional behavior
  

Without a system, these decisions are made locally, within a specific screen, feature, or team. As a result, the interface may look visually similar but becomes less predictable.

For users, this happens gradually. The interface feels familiar but requires more attention: elements behave differently, identical actions look different, and states become harder to recognize.

Consistency is not about identical buttons and colors.
It is about the stability of rules that users can rely on.

A design system does not fix interface elements, but agreements:

• which decisions are allowed
  
• which patterns are repeated
  
• which differences are considered meaningful
  

It turns scattered decisions into a system of constraints that helps the interface remain understandable and resilient as it grows.

It is important to note that a design system by itself does not make an interface usable or accessible. It creates the conditions under which these qualities can be maintained consistently rather than by chance.

That is why design systems are closely connected to accessibility, as both address human limitations—attention, perception, motor skills, and memory.

This series views the design system as a multi-layered structure of decisions.
Each chapter focuses on a specific part of the system and the problem it solves.

Below is an overview of the topics covered next.

Design System Guide. Chapter 2. Principles and Governance

This section focuses on the foundational level, covering the principles and governance of the design system.

It examines the decisions that must be fixed before components, tokens, and documentation appear. Principles define system boundaries, acceptable trade-offs, and responsibility for decisions.

Design System Guide. Chapter 3. Accessibility

This section considers accessibility as a mandatory system requirement.

It explains how a design system must be structured to comply with WCAG 2.2, including legal and regulatory requirements. Accessibility is treated not as an additional check, but as a baseline condition that must be ensured at the level of principles, components, and interaction patterns.

Design System Guide. Chapter 4. Composition and Structure

This section covers the core building blocks of the design system:

• color
  
• typography
  
• spacing
  
• grid and layout
  
• iconography
  
• motion
  

It shows how these elements shape visual and interactive behavior within the design system.

Design System Guide. Chapter 5. UI Kit

This section focuses on interface components and patterns within the design system.

It explores the atomic approach as a way to manage complexity, as well as the role of repetition and composition in creating predictable interfaces.

Design System Guide. Chapter 6. Tokens

This section focuses on how design tokens connect Figma and code into a unified design system.

It shows how tokens enable deep integration between design and implementation, from global styles to individual components. It also explains how changes in Figma can be safely and consistently propagated into code, enabling updates to themes, styles, and components without losing consistency and predictability.

Design System Guide. Chapter 7. Documentation and Tools

This section focuses on the practical use of the design system.

It covers documentation structure, navigation approaches, and tools that help teams apply and validate design system decisions in their daily work.

Design System Guide. Chapter 8. Maintenance and Evolution

This section describes the lifecycle of a design system.

It covers change processes, versioning, feedback, and team involvement required for long-term sustainability.

Design System Guide. Chapter 9. AI

The final section focuses on the impact of automation and AI on design systems.

It examines how AI amplifies existing solutions, accelerates processes, and why it does not replace human principles and responsibility in the evolution of design systems.

A design system is not about visual order or speeding up teams.
It is a way to keep interaction rules stable as interfaces grow and become more complex.

This series is dedicated to the decisions that form the foundation of this stability and why they matter for accessible interface perception.