A Design System Architecture: What You Need to Know

Delivering design solutions to production is one of the key challenges for designers. Successful interface solutions necessitate reusability from both design and development angles. They should be based on common patterns.

The design system emerges as a centralized repository, consolidating descriptions and technical implementations for each solution. It stands as a singular knowledge hub where all solutions are intricately documented and already implemented in some way.

I'd like to share some ideas on a design system structure that can serve as the foundation for frontend architecture in various cases from a single solution to a range of customizable products within an ecosystem.

Basis of Architecture

An architectural approach is essential for any sophisticated system, and the design system is no exception. The architecture of the design system should play a pivotal role in shaping the frontend's architecture and determining its implementation approach.

As with any architecture structure, it should be founded on the principles of organizing the system, encompassing its elements and their interrelationships, as well as their interactions with the environment. The architectural principles also guide the system's design and evolution over time.

The Core Principle

Any interface can be expressed through combinations of simple elements.

Organization and Interrelationships

Viewing the variative array of interface elements from an organizational perspective, the entire system can be categorized into four levels. The combination of these levels can be employed to construct any interface, with each level intricately connected to one another.

• Theme

• Content

• Patterns

• Layout

  
  

Let's break down these levels in more detail.

Theme

The initial and broadest level is the theme. As shown in the illustration above, it affects all other levels. A theme comprises the most basic elements and their associated values, manipulated through variables or design tokens, including:

• Typography

• Color

• Shapes

• Shadows

• Border weight and radius

• Layout sizes and gap

• Animations

• Layout settings

  
  

Theme level mostly affects the visual language of the interface. Altering any of these parameters results in a transformation in the product's visual appearance.

Variables As a Unified Language

Design is only a minor part of the frontend. For later implementation in code, you need to align the approaches between design and development.

A design system serves as a cohesive language bridging the gap between design and front-end development. It instructs us to communicate using a shared language and adhere to the same set of rules.

The optimal method for implementing this approach is through unified variables, often termed as design tokens. Design tokens offer the flexibility to move away from specific values and seamlessly integrate with development.

For example, consider a corporate color with the HEX code #FF005B. Assigning it a token, and naming it as a color-brand, means referencing it by name instead of the code, streamlining implementation and changes across the system.

Additionally, the use of variables provides the following advantages:

Simplified Interaction with Development

A shared language expedites communication between development and design.

Ease of Modifications

Variables eliminate the need for changing values in multiple places, adjusting it in one location automatically updates it system-wide due to concrete semantic naming.

Reduced Error Probability

Design tokens alleviate the risk of outdated or erroneous manually entered values and shared responsibilities between designers and developers.

Scalable Design System

Describing core system variables, such as colors, margins, and typography, through tokens enables seamless extension to diverse platforms and technologies.

Customization Capabilities

The variable approach is crucial for customized interfaces. Modifying more than half of the variables results in a new visual language with a distinct look and feel.

Semantics of Variables

Given the potential multitude of elements at the initial level, it also requires structured and uniform treatment. This is where semantics, with its grouping capabilities, becomes invaluable.

1. Semantics facilitates a shift from abstract names to semantic names, imbuing meaning into all elements. For instance, the color blue is not merely HEX 3D46F5 or Blue 400. It represents an accent or an action.

   
   

2. Semantics plays a crucial role in grouping elements based on their roles and establishing a hierarchy. For instance, grouping colors semantically by their roles is essential for comprehending the significance of each color. This categorization might encompass fundamental groups such as Primary colors, Secondary colors, Accent colors, Neutral colors, etc.

   
   

Clear and concise names facilitate collaboration within a large team, ensuring scalability at both the product and team levels in the design system.

Content

Moving to the second level, we focus on content. At this stage, we allocate:

• Text

• Controls or basic elements - buttons, input fields, checkboxes, etc.

• Icons - small simple icons

• Graphics - logos of other brands, flags of countries, etc.

Combining the theme with the content layer results in the styling of controls and other fundamental components. This process gives content its unique look and feel.

Following semantics in the theme, the design system introduces a hierarchy of typography, encompassing headings of various levels, subheadings, main text, and more. Semantic grouping also brings forth color parents, such as primary colors, secondary colors, accent colors, and others.

Patterns

Transitioning to the next level, we encounter patterns — components responsible for visually representing more complex information than controls and content.

An elementary yet widespread pattern is an icon paired with text.

Another prevalent pattern is a card, particularly popular in mobile interfaces. Examining a card's example illustrates how a change in the theme alters the appearance of the entire component.

Patterns can manifest as forms, tables, lists of elements, menus, and various other elements.

These patterns may have modifiers, enabling the creation of diverse yet consistent interfaces. For instance, modifying a payment methods list item can yield distinct components like a Payment Methods List, a Saved Card Widget, or a Settings Menu.

Layout

In the last level, the layout, patterns, and themed content come together to shape the final interface. This layer consists of several distinct groups.

Sections

By default, the layout spans a single section covering the entire screen width. However, it can be divided into multiple sections in varying proportions based on specific requirements. Within each section, the width of the content area and the establishment of safe margins are defined.

Grid

Moreover, a grid can be incorporated into the content area, subject to modification based on several parameters:

• Number of columns

• Indents between columns

  
  

The grid serves the purpose of defining component widths and organizing them within the space. In the theme, you establish the width of the content area and indents within the grid.

Breakpoints

Another significant group is Breakpoints. These represent specific screen widths at which the interface's appearance and behavior undergo changes. Breakpoints play a crucial role in adaptive layout, ensuring proper content display across various devices and screen resolutions.

These parameters are also configured at the theme level.

A theme extends across all levels, enabling flexible changes to the interface.

Scaling to Product Ecosystem

A similar architectural approach, as seen in the system design architecture, can be applied both within a single product and to establish an ecosystem. Various methodologies exist for creating a cohesive ecosystem.

Base and Product Library

In scenarios involving multiple products, a sensible strategy is to transfer the content level with the simplest elements to the Base library. Patterns level with product-specific components, on the other hand, should be housed in the Product library.

This approach facilitates the reuse of basic components across different products, preserving the simplicity and convenience of the foundational library. To maintain order and expedite work on specific products, it is advisable to consolidate all patterns into a distinct product library.

Themes

When dealing with themes, it is optimal to align them with the visual style of the products. If the products exhibit distinct looks and feels, it is advisable to create separate themes for each.

However, if the products share the same visual language, a single theme can be employed for consistency.

Unified Semantic Structure for Themes

The ease of creating and scaling themes to different interfaces lies in a unified template for the semantic structure of tokens. This template maintains consistent names while accommodating different token values, simplifying theme creation, and allowing for various customization options.

Summary

In simple words:

• Theme level provides structure and look and feel.

• The content level includes fundamental elements.

• The Pattern Level introduces complex elements and their modifications.

• The layout incorporates various elements into the space, offering flexibility and adaptability.

  
  

This approach, comprising Theme, Content, Patterns, and Layout, provides principles and interrelationships within a design system that are required for any architecture.

This architecture ensures consistency, streamlines collaboration, and allows easy modifications, serving as a robust foundation for cohesive interfaces across products and platforms.