Design System: the product inside of the product

Published in

Platea Design Community Kyiv

8 min readSep 7, 2022

Design systems are often associated with some UI kit or style guide and that is it. But this concept is much broader and more comprehensive then this.

And if we would dive into its nature, it is safe to say that the design system is a kind of separate product that exists within your product ecosystem, coexisting and interacting with many other factors.

As you can see in this infographic style guide and some UI kits are only the most basic elements of the design system, but they should for sure include a pattern library, documentation, and guidelines as well.

One of the most representative examples of the design system is the Polaris design system by Shopify. It includes all the above-mentioned components with a detailed description. This can be considered a perfect example of a design system.

Pros and cons of design system implementation

Like any other design tool, the design system would not always be a good idea for your project.

Pros: If you need to maintain visual consistency across business products, unify communications between different teams, create a single point of truth, and have the ability to quickly rebuild and develop your product — then you should go for it!

Cons: In case your project is short-term or static and you are not ready to dedicate much time and resources to developing and maintaining such a complex system, teach people how to use it in the future — it is better to end up with a UI kit and style guide.

Design system types

In terms of usage and maintenance, design systems can be divided by flexibility, distribution model, and components structure approaches.

Flexibility. The more strict the design system is the more detailed documentation and rules that can not be broken or neglected.

Main benefit of strict system is that the design and developer’s team are fully synchronized and there is no room for inaccuracies. Among other benefits of this approach is the presence of clear processes and principles of interacting with the system and the availability of many corner cases within the system. But of course, this type requires a lot of effort, and work on it and has a lot of bureaucracy in processes

On the other hand, a loose type of system implies a set of rules that can be experimented with, and the general documentation describes only high-level processes. There is not tons of documentation and details for these sorts of systems but it affects the consistency and organization of the system.

Distribution model. There are also centralized and distributed design systems.

A centralized design system is maintained by a single person or team which guarantees stability, a clear single vision, but could become a bottleneck if the responsible person/team cannot cope with the workload.
A distributed model allows several people or teams to be in charge of the design system. In this scenario, all the processes are quicker because everyone is involved, but it may cause system failure or error because of a lack of a single vision. This model also still requires a supervisor who can support the overall vision of the system.

Component approaches. There are two fundamental types: integrated and modular.

The integrated components approach focuses on one unique context of the component’s usage. Every component has its unique purpose and in most cases can’t be reused. This approach dominated before the boom of a number of devices with different screen resolutions and different contexts of usage and interaction. Systems of this kind have lost their relevance due to low potential for adaptability and scalability and have been replaced by a modular approach, for which these characteristics are one of the keys.

The modular component approach involves creating components that are interchangeable and reusable, so these systems are flexible, but they are quite expensive to develop. The most popular modular components approach is atomic design.

Component approaches

Atomic design. The first and well-known component approach is the Atomic design. This approach was fundamentally created and described by Brad Frost in ‘Atomic Design’.

General idea is to divide your interface components into the smallest parts — atoms and from them gather bigger components — molecules, organisms, templates, and whole pages.

Also while creating components you should consider semantically right naming for them. It should be generalized and there are several approaches for that, one of them is presented in the image. The same with styles: colors should have semantic, not literal names, for example ‘warning’ instead of ‘orange’.

BEM. Second approach which is less popular, but still widely used is BEM. It stands for Block, Element and Modifier.

This approach was designed by Yandex and is an analog of atomic in terms of packing components (from small to biggest). The only difference is in structuring whole DS: you would rather store your components inside bigger component than storing it all in a separate page.

This approach is very friendly to developers, because they reuse components like we do in atomic, but attach unique names for it. That’s what BEM is doing. Useful outcome of it is object-oriented database with set of components, which is connected to each other by meaning.
To be more on top of things, check out BEM’s official website.

Users and creators of design systems

On this Euler diagram you can see that users and makers often intersect with each other.

Users usually are the entire organisation in which this DS is used, external users of DS is public, developers or junior specialists as an onboarding guideline. As for makers they are usually dedicated design team or senior-level staff or third-parties.

As for users and makers dispersion there is a dependency with the size of organisation. Obviously, in small companies makers and users are practically the same people. The bigger company the broadly desperation is.

Implementation approaches

According to Nielsen Normal Group there are 3 approaches of implementation DS:

Adopt — means take another’s existing DS (for example Material Design, Carbon, etc) and change according it to your needs.
Adapt — update your old DS.
Create — make new DS from scratch.

Talking about dependencies: while creation, there are a lot of opportunities for customization, and high brand differentiation, but of course, it has high cost and is resource-intensive.

On the other side, we have adoption of another’s DS which is low-cost but has less customization and low brand differentiation.

Implementation roadmaps

Creation of Design system from scratch. Ok, it has been decided to create DS from scratch. So, the first step will be:

Step 1. Define team and roles

Assign responsible designers
Assign responsible developers
Others: Content strategists, product managers, project managers, executives
Define roles between each team

Step 2. Choose approach and principles

Choose a structured approach for a design system
Write down the principles of an approach
Create a definition of done (when DS can be considered ready and be launched)

Step 3. Grid and spacing methods

Define devices that the design system will support, set breakpoints
Define layout approach
Create base unit
Create baseline grids, key lines, incremental spacing

Step 4. Typography

Create a typographic scale for 1 device
Adapt to different devices
Create name convention for tokens

Step 5. Color palette

Create palette according to brand identity
Add special colors: warning/error/success state, neutrals for the background
Create name convention for tokens

Step 6. Icon library

Create / add icons
Standardize the implementation (unify boundaries)
Adapt to different devices
Create name convention

Step 7. Patterns & Components

Create responsive components according to devices DS maintains, wrap in variants
Add component description
Create a name convention (according to the selected DS approach)
Connect styles
Connect code implementation

Step 8. Guideline / documentation creation

Design guideline
Editorial guideline
Accessibility documentation
Platform guidance

As for adapting design system possible steps will be:

As for Adapting design system possible steps will be:

Step 1. Define team and roles

Responsible designers
Responsible developers
Others: Content strategists, product managers, project managers, executives
Define roles between each team

Step 2. Interface audit

Existing interface audit (gather all elements of DS in one place)
Create a list that should be added to the new DS (what elements weren’t in the previous one)

Step 3. Troubleshooting

Define problems of old DS
Use Vanilla framework to value components
Create backlog for DS updates

https://atomicdesign.bradfrost.com/chapter-5/#making-changes-to-patterns

Step 4. Make change request

Make a list of changes that will be implemented to the new DS (from backlog)
Agree on changes
Set priorities

Step 5. Modify DS components

Modify elements according to agreements

Step 6. Changes implementation

Implement changes to the live product
Communicate changes to the team. Notify responsible teammates

Step 7. Create a change history list

Create a history list to include all edits
Create a backlog for future improvements

And last approach — Adopting DS:

Step 1. Define team and roles

Responsible designers
Responsible developers
Others: Content strategists, product managers, project managers, executives
Define roles between each team

Step 2. Understanding needs and requirements

Define target audience and users of DS
Define purposes, goals, and requirements for the future design system
Definition of done

Step 3. Interface audit

Product interface audit (all the components, design patterns, and interface features of an existing product)

Step 4. Research of suitable DS

Research of existing DS you will adopt, comparison to defined requirements
Recollect DS elements and decide which is necessary for your work

Step 5. Adopt process

Adjust the style guide of DS according to your brand identity
Adjust components of DS according to your needs
Adjust documentation considering your business-specific and edits that were implemented in DS

Step 6. Create guidelines for future DS improvements

Create guidelines for future adaptation

Step 7. Create an adaptation history list

Create a history list to include all edits

Summary

A design system is not a style guide or some set of reusable components but rather an ecosystem, a separate product with corresponding product owner, creators and users.

There are several approaches to run a design system as well as components creation and organization.

There are 3 main ways to implement a design system: adapt, adopt and create a new one.

Thanks for reading!

Article authors:
Anastasiia Rishko
Iryna Franko

Useful materials:

Most popular design systems:

Checklists for DS creation:

from scratch: https://bit.ly/3r0JZx8
adapt old DS to new one: https://bit.ly/3uOF6IJ
adopt third-party DS: https://bit.ly/3J5sLVA

Design System: the product inside of the product

Written by Anastasia Rishko