Design System Guide. Chapter 2. Principles and governance

A design system does not start with components, tokens, or documentation.
It starts with decisions about which principles underpin the interface and how those decisions are made and sustained over time.

Without fixed principles, a design system quickly turns into a collection of artifacts: a component library or a UI Kit that looks consistent only at first glance. As the product grows, such systems lose coherence, and decisions begin to contradict one another.

Principles and governance define not how the interface looks, but why it is designed the way it is.

Principles in a design system are not abstract statements.
They function as decision-making rules that reduce the number of choices that need to be made repeatedly.

For example, the principle “the interface should be forgiving of errors” translates into concrete decisions:

• destructive actions require confirmation
  
• critical actions can be undone
  
• the system responds predictably to repeated or imprecise actions
  

If this principle is not fixed, each team resolves it differently. As a result, identical actions behave differently across the product, and users lose confidence.

Consistency is rarely broken intentionally.
More often, it erodes due to local optimizations.

A typical example is the order of actions:

• on one screen, the primary action is placed on the right
  
• on another, on the left, because “it fits the scenario better”
  

Each decision makes sense locally.
But without a principle that defines action order, the interface becomes unpredictable.

A principle such as
“the order of actions is determined by the type of action, not by screen context”
must be established before components and templates are introduced. Otherwise, the system starts to diverge at the level of basic patterns.

Principles do not work without governance.

Governance answers the question:
what happens when a principle needs an exception.

For example:

• the design system defines a minimum interactive area size
  
• a product team proposes reducing it “on one specific screen”
  

Without governance:

• the decision is made locally
  
• the exception is not recorded
  
• similar deviations begin to appear elsewhere
  

With governance:

• the request is explicitly documented
  
• the rationale is recorded
  
• An informed decision is made, to allow, reject, or revise the principle.
  

Governance does not prevent change.
It prevents the uncontrolled accumulation of exceptions, which silently erodes the system.

Components and tokens are often perceived as the starting point of a design system.
In reality, they merely materialize decisions that were made earlier.

For example, the existence of a color-danger token implies that the system has already defined:

• error states
  
• destructive actions
  
• critical warnings
  

as distinct semantic categories.

If this decision is not fixed:

• one designer uses red for errors
  
• another for warnings
  
• a third for destructive actions
  

Visually, the system may still appear coherent, but semantically it breaks.

Before components, tokens, and documentation appear, a design system must fix a set of foundational decisions.
These decisions define the boundaries within which the system evolves.

Priorities and trade-offs

Example:

• is it acceptable to reduce contrast for brand expression
  
• what matters more: information density or readability
  

Without these decisions, reviews turn into debates, and outcomes depend on who is present.

System boundaries

Example:

• the design system is mandatory for core features
  
• marketing pages are allowed to deviate
  

If boundaries are not fixed, the system is perceived as an imposed constraint and begins to be bypassed.

Allowed variability

One of the key questions is where a component variant ends and a new component begins.

This most often appears with buttons:

• different visual styles
  
• sizes
  
• presence of an icon
  

If variability is not constrained by principles, the UI Kit quickly grows, and elements with the same role begin to behave differently.

The criterion here is not appearance, but:

• the role of the element
  
• its behavior
  
• interaction rules
  

This decision must be made before the UI Kit is formed.

Approach to exceptions

Example:

• a temporary solution for an A/B test
  
• a platform with technical limitations
  

The system must define in advance how such cases are documented and revisited.
Otherwise, temporary solutions become permanent.

Responsibility for decisions

Example:

• who approves a new pattern
  
• who is allowed to change tokens
  
• who decides that a rule is obsolete
  

Without clear responsibility, decisions are made retroactively, and the system loses authority.

Principles allow different roles to work with the same decisions.

For the system designer, a principle defines system boundaries.
For the product or interface designer, it defines allowed variants.
For the developer, it acts as a contract that must be reproducible in code.

The principle itself does not change.
Only the level at which it is applied does.

This allows the system to remain coherent as more roles become involved and as the product scales.

Accessibility requirements are often determined by the legislation of the region in which the product is used.

In some jurisdictions, compliance with
WCAG 2.2
is a legal requirement. In others, it is advisory.

This means that, at the level of design system principles, it must be clearly defined: which level of accessibility is mandatory and which is recommended.

If WCAG compliance is legally required, the design system must enforce it system-wide, through principles, parameters, components, and validation processes.

Even where there is no legal obligation, many WCAG criteria directly affect interface quality:

• Minimum target sizes
  2.5.8 Target Size Minimum

• Predictability of navigation and identification
  3.2.3 Consistent Navigation
  3.2.4 Consistent Identification

• Text and element contrast
  1.4.3 Contrast Minimum

That is why accessibility must be part of principles and governance, not a final checklist.

Principles and governance are the level at which a design system becomes a system rather than a collection of artifacts.

This is where decisions are made that determine:

• which trade-offs are acceptable
  
• where system boundaries lie
  
• how exceptions are handled
  
• who is responsible for change
  

These decisions are made before components, tokens, and documentation appear, yet they define what those artifacts will become.

Accessibility and inclusion are not separate layers in this context.
They emerge as a result of systemic decisions about sizes, spacing, language, scenarios, and assumptions the system treats as normal.

When these decisions are fixed at the level of principles and supported by governance, the interface remains:

• predictable
  
• resilient to growth
  
• understandable for different users and roles
  

Without this foundation, a design system preserves its form but loses its substance.

The following chapters will show how these foundational agreements manifest in concrete layers of the system, from accessibility requirements to components, tokens, and maintenance processes.