Building a design system

To keep a stable environment for design and development teams, it makes sense to make somewhat a short-term commitment by investing in the process of designing and building a Design System.

The process of creating a design system may not have a list of definitive standards to follow, but in this book we share with you our insights on how to create such systems by providing you with steps and guidelines to follow towards building a well-thought design system with proper structure and documentation.

Step1: Address the need for a system

• "Do we actually need a Design System?"
  
• "Why go through all the trouble?"
  
• "Do we have the time for that?"
  

Such questions will arise when you first introduce the idea of building a design system to your team as well as any potential stakeholders -if you're building it for a client-, people may doubt the whole thing and see it as too much and unnecessary work.

And they could be true to some extent. Maybe the team is sticking to only Bootstrap for every project that comes in, and they ship projects efficiently that also satisfy the customer base.

So when could a design system be needed?

If the process of product design seems to be messy and inconsistent, and development as well as maintenance of code takes much more time than it should, even for issues and features that may not require that much work and time, then most likely a design system is needed to address these issues.

It's necessary to have a solid proof as to why a design system needs to be built. After all, when team members truly believe in what it's worth to have a design system of their own, and how much it could impact the internal process of design and development, they will be enjoying their tasks while working on creating the system -and they really need to enjoy them because creating a design system can take long-, and management also needs to approve such decisions; since the decision of dedicating the man power and time for such a project is not usually easy to make, and they would need to determine the ROI of having a design system.

As for stakeholders, it's also necessary to get their agreement on such a process, because it will inevitably delay the initial delivery time for their project. That is if if the design system is going to be created specifically for a certain business. But in return, future updates and maintenance of the project will be much more agile than when built without a design system. And even the initial delivery should be a consistent outcome that lives up to the needs of the business and creates a solid impact on both stakeholders and the audience.

The best way to go about this step would be to check the benefits listed in Chapter 3, and communicate them to both the team and stakeholders, along with the personalized benefits to be gained based on the current state of things for both the team and the business.

Step2: Starting with the UI Inventory

The first thing to do is to check the current state of UI assets the team has access to.

This step starts with gathering every single digital asset that the designers as well as front-end developer have come across. Whether these visual elements exist in products the team is working on, or in some sort of library that the team usually refers to.

Every visual element of interest should be gathered to construct a complete inventory of elements that will be evaluated and reviewed to determine the inconsistencies as well as what's needed to have a collection of refined components library.

The bigger portion of elements that need to be looked at includes:

• UI elements and patterns
  
• Icons
  
• Typography
  
• Colors and themes
  
• Graphics and illustrations
  
• Logos
  
• Voice and tone of content
  
• Photography and photo galleries
  

Since the process of building the UI inventory takes a decent amount of time, the team could focus on the above list for starters. These elements are the most vital and any design system should address them appropriately.

The collection process can start with Patterns, by taking screenshots of these visual assets as well as importing any graphics into a single directory.

By assembling these elements and categorizing them into a single place, there will be a solid reference for future actions and it will serve as a foundation for the system assets.

The same can be done for colors, as having varying colors is one the main signs of design inconsistency.

The team should make sure to collect all the colors used in design as well as in CSS files, preferably with the frequency of each color used to be documented along with each color.

After colors, the team can switch to Typography by collecting all the different text styles and fonts being used across the projects. Then comes icons, which also serve as a major factor for a more consistent and predictable user interface.

It's also worthy to observe any written content and identify the voice and tone that is being communicated, as well as the logos being used.

If the team is just starting, as if there's no previous assets to go through, the UI inventory can be made up using external resources that are the closest to what should constitute the design system to match the target brand and business criteria.

Step 3: The presentation

After addressing the issues with the current design and development environment and process in step 1, as well as collecting as much data as possible in step 2, this information can be used to present the main idea to the team and stakeholders.

This step is a lot similar to the very first step, but this time the goal of presenting the idea of creating a design system is clear. It's to take a solid "Yes" from management, team members and stakeholders.

The inconsistencies should be crystal clear based on the visual inventory assembled in step 2, and you should now have a better view of the underlying issues and problems of the current process, highlighted by the data gathered as well as the state of the current assets that the team has access to.

Explaining how each category of the UI inventory can be improved or replaced, and mentioning the frequency at which different elements are being used.

Step4: Assembling the team

The process of designing, building, and maintaining a design system requires collaborated efforts of different specialties and abilities.

The design system team will require individuals to work on different aspects of the system to make sure that every inconsistency is addressed appropriately.

Members working on the design system may not be assigned the task of building the system as their full time task. Since building and maintaining a design system is an on-going process, it should be noted that partial time can be allocated for working on the system.

The following are the highlights of core areas of expertise that should be present in a Design System team:

Visual Design

Visual designers will be responsible for creating and defining visual elements and components, as well as deciding on the different UI patterns that should exist in the system.

User Experience

Responsible for laying out the different experience guidelines in the system. Making sure the system carries proper interaction, logical flow, and proper motion practices are some of the responsibilities of UX engineers working on the system.

Front-end Development

Front-end Developers will implement the UI components as instructed by the visual designers and user experience engineers. They will turn these elements into coded modular components to be present in the system for future use.

Accessibility

Accessibility is a true matter of concern for proper system design that complies to web standards of accessibility like WCAG. So it's necessary to implement different accessibility practices across the system for people with disabilities and such.

Content Strategy

Communicating clear messages via the design system is one of the main purposes of building a system. Content Strategists define the voice and tone of communication, and they make sure to provide consistent content that is Aligned with the brand goals.

Management and Leadership

Organizing the process of building a design system ensures efficiency along the road. It's necessary to make sure that the final product is aligned with target customers needs. Individuals in charge will also decide on the priorities of each task and feature in the system.

Step5: Establishing the color palette

Colors will be present in every part of the design systems as well as the products they are created with. They contribute greatly to the overall identity, look and feel of the system.

Colors convey emotions and are integral part of the communication channel adopted by the design system, and having numerous different colors that are either duplicated or redundant impedes the effectiveness of relaying messages to the users.

So a good place to start working on the color palette would be the visual inventory. Revisiting all the collected colors, spotting what's unnecessary or duplicated, and getting that of the way is a fine first step to take.

Making sure that the colors in the palette are not too many yet sufficient is key to a successful color palette.

Then comes deciding the colors to be included in the system, that is the primary colors as well as accent colors. Starting with primary colors, those should be the most commonly used colors in the user interface. The selection of these colors is mainly based on the brand assets that the system is built for, or some neutral colors for other more general systems that are less restricted by brand guidelines.

Accent colors are then derived from the primary ones, either by manually deciding on these colors by going through each one and finding its appropriate accents, or by using automatic generators that are available in most pre-processors. For example, one can use the darken and lighten functions available in Stlyus language to generate the different shades and tints of the primary colors.

Then comes the process of naming the colors in the design system. The names should  be easy to understand and memorize among developers and designers.

Team members working on accessibility also need to make sure that the colors present in the system work well together, and that they are safe to use on the web.

There are different ways to go about naming colors, we go for clear naming like follows:

$color-primary, $color-secondary, $color-danger, $color-success

Frontend developers will also implement the primary colors as well as accent colors in the design system code base, using the agreed on naming of color variables.

Be careful when choosing the colors, because even if they may complement the brand colors, they could still pose accessibility problems. The chosen colors need to have proper contrast in different situations, in order to be WCAG compliant.

The palette should be finally tested and documented into the design systems guidelines and made available for both designers and developers to use.

Step6: Setting up Typography

Typography also has a great role in achieving an effective design system and it's one of the things that could make or break the design of the system, since it's an integral part of the final product and its user experience.

Text makes a decent portion of any user interface and is crucial for guiding users through products as they take different actions and browse a design.

Choosing the right font has a great impact on how customers will view the brand, so they need to have high legibility to be able to deliver their primary goal of enabling users to clearly recognize and understand written content.

Deciding on a font that is both readable and familiar to users is the first step towards having proper Typography in the design system.

The approved typeface doesn't have to be anything crazy like decorative fonts as users are more familiar with common system fonts like Verdana or Times New Roman.

Custom web fonts can still be used to add a personalized flavor to the brand if customization is done in moderation to avoid visual and performance drops.

After selecting the typeface to work with, type scale can be addressed to determine the different sizes to be present in the system.

Sizes will depend to a great extent on the type of the chosen font. A thinner font will require a size set on the larger side to maintain legibility.

Type scale should be decided with attention to different screen sizes so it can adapt well on mobile devices without being too large or too small.

A consistent type scale is a combination of font sizes, weights and line heights set in harmony and properly tested to ensure having a scale that communicates well with the user interface.

All the agreed on properties of typography are then documented in the design system and also implemented by developers in the appropriate manner for future use, by setting variables or mixins in the code base of the system.

Step7: Implementing the icons library

Icons are another primary contributor to an engaging visual language that offers its users quick mental shortcuts to the wide range of actions they will come across, especially the primary and most common ones.

Icons have become a staple of modern design and they serve to reduce the cognitive load off users by providing clear and expressive visual cues to guide users through the interface while communicating well certain ideas.

A well thought icons library should contain icons that are readable on different scales of design, as well as expressive and understandable by the users.

Icons should follow a certain style, like being outlined as strokes, to deliver a feeling of consistency to the end users. An alternative style could still exist for certain use cases.

There are different ways to go about implementing and using an icon set in the code base of the design system. Each will have a different level of impact on the performance of the final product, since each method will have its own load time.

Choosing a method that is also both designer and developer friendly is a factor to consider when implementing an icons library in the design system, while maintaining performance, accessibility and flexibility.

One of the best methods that incorporates a good combination of the previously mentioned principles is rendering inline SVG icons using modular components of modern frameworks like React or Vue.

Developers would build components that take in an imported SVG file in the form of inline SVG, by using an inline SVG loader, as props and the components would render the icons as inline SVG along with other properties, like color or size.

Using this well-performing method, title and description tags can also be set for better accessibility, as well as size and color through component props for flexibility.

In case no JavaScript framework is to be used with the design system, opting for inline SVGs in data URLs can be the best option in such case.

After all, the implemented method has to be tested and assessed by team members to establish an icons library that fits well into the design system environment.

Step8: The pattern library

After making sure that the different elements of the design systems are properly addressed and are in place, it's time to start working on the pattern library.

It's going to be an on-going process of building a collection of patterns to be used consistently in the design of user interfaces. Patterns are the main building blocks of the design system that encapsulate every aspect of the design system in the shape of reusable components.

Patterns should be well categorized and documented in a friendly manner that is easy to grasp for every one that is part of the design system or is going to be using it.

Each pattern has to be built with the proper visual properties in mind, like colors, fonts and icons. They should be easy to use in any part of the target product and compatible with other patterns in the system.

Created patterns should be reviewed by developers, designers and changes will be made as necessary until a pattern is approved and finalized.