When, Why and How to Use Design Systems?

We have been hearing a lot about design systems these days. All the big shots like Google, Microsoft, IBM, and Mozilla have their own design systems. These companies have changed the way they design digital products. They have built a collection of reusable components and a set of guidelines and standards for those components. Let's understand what design systems are first. 10 years ago, people simply called them pattern libraries. A few years ago, Atomic Design entered the scene and provided extensive grammar around them. Once Google unveiled Material Design in 2014, the concept of design systems had finally matured. I believe you have heard various definitions, so let me start by defining what a Design System isn’t; it is not a Sketch library, no more than a Style guide, or a Pattern Library. It’s all of this and so much more. More simply put, the difference is in the standards and documentation that accompanies the assets and components. A guide on why and how to use them would help the team and people working on the product.

“A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.”

Design System is defined in many other ways, but a definition so broad could be perceived ambiguous. Therefore, don't let a definition dictate your understanding of the design system.

Design Systems bring order to chaos.

They help teams by giving them a more structured and guided way to build their product. Everyone involved in building the product is on the same page, so the entire product remains consistent throughout. The team knows exactly how components should look and work.

Design System exists if it can be used without the creator

Why should you build a Design System?

Design systems enable teams to build better products faster by making design reusable—reusability makes scale possible. The need for Design Systems goes hand in hand with the need for scalability, efficiency, and consistency in Design. So, how do you address these challenges? Scalability: How will you design consistent UIs across platforms (Web, iOS & Android) with a growing design team and organization? Efficiency: How efficient is your design+development workflow? Is the dev handoff road bumpy or a smooth cruise? Consistency: My UI looks to be consistent across platforms. Let the UI audit decide. Assure scalability, efficiency, and consistency with Design System. Imagine that your company has a product that has been building for a long time. It’s likely that many teams working on different parts of the product will create inconsistencies in the product over time. Many businesses are investing in design as they recognize that the customer experience of their products offers a competitive advantage, attracts and retains customers, and reduces support costs. Why is a company investing in a design system?

• To scale design
• Design faster
• To make design reusable
• Make design and engineering talk the same language
• For better operations with a growing design team
• Build consistency across the product
• Clear the design debt
• Iterate confidently with a single source of truth

But should you be using a design system? A design system is better than no design system.

How to build a design system?

There are some prerequisites to building a design system. First, you need to understand the Component-based design. It's used in Sketch, Figma and Adobe XD by designers and directly in the code by developers

"Components are building blocks of your user interface or reusable bits of code within your application or system. They serve the same purpose as a function."

In 1968, at the NATO conference on software engineering, Douglas McIlroy presented component-based development. Component-based development provided a way to speed up programming’s potential by making code reusable, thus making it more efficient and easier to scale. This lowered the effort and increased the speed of software development, allowing software to better utilize the power of modern computers. - excerpt from Invision's Handbook, Introducing design systems The design industry was facing a similar challenge. As the number of devices, browsers, and environments increased at a staggering rate, we were tasked with making more interfaces for different screen sizes and capabilities. Design system methodologies like Atomic Design bring logic and structure into individual screens.

Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner.

There are five stages of atomic design. Source: Invision, Brad Frost's Atomic Design methodology

• Atoms are the basic building blocks of matter. The atoms of our interfaces serve as the foundational building blocks. These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further.
• Molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule.
• Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface.
• Templates are page-level objects that place components into a layout and articulate the design’s underlying content structure.
• Pages are specific instances of templates that show what a UI looks like with real representative content in place.
• I know you are confused between a template and a page because the rest was 6th-grade chemistry. To clear this out, think of templates as a combination of molecules and organisms to form the structure of a page. It's not a page unless this skeleton is fed with content.

Atomic design is less of a process and more of a mental model to help us think of our interfaces as a cohesive whole and a collection of components at the same time. Now, let's build a design system. Hold up. The process of building a design system from scratch is going to vary from building a design system for an existing product, both being equally challenging. Let's start building a system from zero to one first. Simultaneously, we will learn to implement it on an existing product as well.

1. Choose your players

Take a moment to think about the people who are going to be involved. Just because we are building a 'design' system doesn't necessarily mean you're going to need only designers. You'd need designers, front-end developers, product designers/managers, and leaders. Once you identify the people who will be using your system and who should be involved in the process, your next task would be to establish the right team model.

2. Choose your team model

According to Nathan Curtis' Team Models for Scaling a Design System, solitary, centralized & federated models are the 3 popular models used by companies worldwide. A product 'overlord' rules the design system in a solitary model. If you gave even the slightest thought about using this model, you shouldn't be building a design system in the first place. Also, the fact that you're lacking resources for building your design system, you assign one person to build and manage your design system tells that you don't need a design system because the design system is to scale. Hence, say bye to the solitary model. Most of the teams use a combination of the centralized and federated(distributed) model. As the centralized model is said to have a single point of failure and a distributed model facilitates key players to get involved across the product. In this hybrid model, the team comes together to build, manage, and govern the system.

3. Do some research

It's important to do your research. Who will be using your design system and how will they use it? You should be speaking to your potential contributors and consumers to discover the use cases you'll need to satisfy. Ensuring the usability of your system that fits into the workflow of other teams is crucial, with insights from the customer interviews. Once the goals and requirements of the organization are aligned, we can move into the field job of building an inventory, a visual inventory.

4. Conduct a UI audit

This step is important especially for an existing product, whether that's the design of an app, website, or a digital product of some other platform. Use tools like CSS Stats, visualize stylesheet, and generate documentation for your design system. Those who are building their system from ground up should be focusing on creating a visual design language.

5. Create a visual design language

Yes, a stylesheet. This consists of the fundamental elements of a visual design language like colors, typography, sizing & spacing, imagery, motion, and sound. Setting these guidelines according to your brand identity would set a strong base for building your UI library. Working on a live design system is going to be challenging considering the number of iterations it has to go through.

6. Create a UI library

Previously mentioned elements of the visual language will help us create the pieces of UI components. The results of the UI audit will help you visualize the design debt you're in. Take stock of all the interface elements in production to have a record of tasks and components for building the UI library. When building a UI library and product in parallel, you are bound to face some difficulties in managing the library and the product UI file at the same time. To make the job of maintaining the UI screens and library easier, designers working on Sketch are advised to create components/symbols locally on a sketch file first and later deploy it globally to sketch cloud or sketch library on abstract. Library Symbol Replacer plugin comes in handy while migrating your sketch library. The UI screens have to go through multiple revisions until you reach the MVP stage. Until then working on a single file would free you from the hassle of updating library components explicitly. At ProCreator we use abstract to manage component libraries across our team. Create sketch symbols using the Atomic design methodology. Your library should contain organisms and molecules, Wherein individual components could be broken down further into fundamental elements called atoms. Building this inventory along with the product is going to cause some differences between the UI sketch file and the library. Sketch plugins like Symbol Organiser, Symbol Manager, and Symbol Instance Locator handles such discrepancies. Use these plugins to merge, remove, and manage your sketch symbols. Working on a live design system calls for the product managers to ensure consistency. Every component of the design system should exist in the product. Take necessary measures to update the design system in real-time with their product. 7. Documentation Design system without documentation is just a pattern library. Enter front-end developers. In a strict design system, the component only goes into the design system if it's coded. Designers and developers go hand in hand here. For designers, there are some tools like InVision DSM that lets you manage and sync assets and documents. You need a place to document the system, right? There are a lot of SaaS coming up for design system management like Storybook, Lucid, Frontify, and Interplay. Else, go old school and host it on the web. Most design system documentation includes the component’s name, description, example, and code. Others may show metadata, release histories, examples, and more. What matters most is that you show what’s necessary for your team to get complete the work. Congratulations, you have successfully bridged the gap between a designer and a developer. As you have built the design system, it's time to start using it across your organization. Have a look at some of the common design systems to follow-