[Design System] Constructing a components library is a process of… grouping and classifying

May Nguyên Huỳnh
4 min readFeb 22, 2024

In our previous post, we covered considerations for planning a design system. Now, let’s delve into the process of implementing one.

Realistically, crafting a design system is both an art and a quantifiable scientific endeavor, encompassing phases of discovery, definition, development, and delivery.

Discovery

Thoroughly collecting existing design components within the product aids in providing an overview of the current state, highlighting technical issues as well as process and workflow obstacles. By replicating the entirety of existing interfaces through work on Master files, we are able to:

  • Assess the overall state of the product interface: ensuring design consistency
  • Identify existing issues of branding style, component variables, and component usage…
Reproducing current production screens (Master files)

Definition

Subsequently, identifying the unified and interconnected similarities, as well as the unique characteristics, among product variables (such as statistic web app, operation app, and service app platforms). This allows us to categorize library components into 3 layers:

  • Foundation: Determining the elements that require synchronization to express the product’s persona across variations. These may include color, font, elevators, dividers, etc.
Example of Foundation’s elements
  • Core library: Identifying the fundamental components that necessitate synchronization and can be utilized across all variations. Examples include buttons, icons, toasts, panels, tooltips, input fields, etc.
Example of Core library’s elements
  • Product library: Recognizing components specific to a particular variant, either derived from the Core library components or uniquely created for that variant. Examples encompass models, headers, footers, sidebars, empty states, etc.
Example of Product library’s elements

The rationale here lies in the hierarchical relationship between components: alterations in components at higher layers inevitably impact those below, fostering uniformity across product variations (the same logic with atomic design).

Library Development

Given the interplay between libraries, careful consideration of components within each layer is imperative to ensure:

  • Elements in the Foundation layer are broad-ranging (used across platforms) and and limit changes as much as possible. This will be explained more clearly in the Creating color tokens post.
  • Components in the Core Library are comprehensive and applicable to numerous scenarios (used across platforms), with changes restricted due to their impact on Product Library components.
  • Components in the Product library are tailored to the nature of the variant (used in a specific platform), exclusively applicable to that variant, with changes not affecting other variants within the system.

Drawing from available use cases by gathering current design patterns through Master files, we can know:

  • The diversity of current component variations, facilitating decisions on merging or removing inappropriate components and creating new ones where necessary.
  • Adjustments for aging components based on their usage and shared patterns.
  • Formulation of a set of usage guidelines grounded in these use cases.

Library Delivery

The evolution and innovation of the design system continue throughout the application of the new component set, catering to the diverse needs of users (designers and developers).

Together with designers, in parallel with the development of a new set of components, the existing components currently in use also need to be updated and innovated accordingly. This process verifies the flexibility of the new system, ensuring it accommodates various designers without compromising functionality. It also evaluates whether the system can be applied across different scenarios without creating new tokens or components:

  • How easy it is to find components when needed, based on their arrangements and names?
  • Are there any use cases that are not complete and need to be added to the new system?
Illustrates the implementation of components by searching for components within the library

Together with developers, ensuring alignment with engineers in implementing the new system is paramount. Objectives when integrating the design system into products include:

  • Establishing links between tokens and components to minimize the impact of future adjustments or implementation time.
  • Ensuring formal and semantic consistency of components throughout the product.
  • Building a repository of reusable components.

Moreover, engineers prioritize the feasibility of implementation when applying a new design system. Collaboration with engineers is essential, facilitating necessary adjustments throughout the transition process. The good news is that because of the way it is built and the connection between components, changes will have less impact on designers and engineers if we have the right direction.

Adjustment of the shadow box based on the developer’s feedback

I hope that throughout these posts, you’ll discover that the design system isn’t as daunting as it may seem. It can provide you with a basic guideline on where and how to begin building one. Of course, there’s always more to learn and share, and I remain humbled by the things I’ve learned while delving into this field, as they are never enough.

--

--