An Introduction to Design Systems and How They Improve the Digital Customer Experience

We look into the basics of design systems and how to determine if you need one to improve your digital customer experience.

By now, most people that work in the web development industry have heard the term design system, but if you haven’t created or used one yet, this post is for you.

In this post, I’ll detail the basics of design systems, when — and when not — to use it, and how to get started.

What is a Design System?

A design system is a well-documented set of design rules for how components on a website should look and interact to provide the best digital customer experience. A good design system will include documentation for:

• colors
• iconography
• typography (fonts)
• photography or images
• reusable components like tables, grids, download buttons, calls to actions
• brand voice and tone
• code samples or how to implement a component.

Up until I mentioned brand voice and tone, developers reading these probably thought this looked like a stylesheet, and marketers probably still wonder how it’s any different than a brand standards document.

Differences Between Stylesheets and Design Systems

A design system will contain stylesheets, and the more reusable these are, the better, but a design system is the bigger picture. It will contain details you can’t show in stylesheets, including when and how to use particular styles. For example, looking at a stylesheet won’t tell you the use cases for primary vs. secondary buttons, or the differences between a mobile app version of an icon set, or when to include an icon in a button and which ones to use if for some reason you have multiple.

For larger organizations with omnichannel environments, you should use design systems to define and document different components on web, mobile (iOS and Android) and distinct microsites. You should have code examples and usage examples for each, likely in separate languages. For these reasons, a design system should live outside of the web application itself.

Differences Between Designs Systems and Brand Standards

Brand standards or brand guidelines serve a specific purpose. The usual purpose is documenting brand details like brand voice, logo usage (and alternative versions), iconography, typography, and so on. Once you document these, you then provide your standards to new designers, writers, agency partners and anyone else who creatively represents your company to make sure they consistently apply the brand and designs to the proper channels.

What brand guidelines don’t do is tell you how interactions should work for web or mobile applications to provide the best digital customer experience. They don’t provide code samples or when to use certain reusable components.

When to Use a Design System for the Best Digital Customer Experience

As much as I love and advocate for design systems, I don’t believe all websites need a design system. If you are using a purchased or off-the-shelf theme for a content-only website, a brand standard is usually enough. However, if you are creating a custom application (web or mobile), I think a design system greatly reduces the development time and effort and ensures consistency.

When to use a design system:

1. When you create a custom mobile web, mobile or omnichannel application
2. When you have multiple developers responsible for front-end
3. When you separate design teams from UI developers or use contractors.

Let’s take a look at each of these.

1. When You Create a Custom Web, Mobile or Omnichannel Application

With custom application development, you need to make sure your design system is well-documented.

Each of these types of applications have complex interactions that require a design system. You should document each system in a way that keeps developers from guessing which components to use in which situation. For example:

• When to use specific layouts, specific table formatting, when to use call to action buttons.
• Like a scripted playbook, better consistency (look and interaction), brand adherence, when to use modals, when not to. Extend the brand beyond.
• Work more efficiently when working from the ground up.

2. When You Have Multiple Developers Responsible for Front-End Controls or Components

The key to building customer loyalty is consistency. A single, standout experience may grab attention, but it doesn’t always lead to increased loyalty. According to research from Forrester, 95 percent of customers use three or more channels to connect with a company in a single service interaction with 62 percent using more than one device. The critical part of this scenario is consistency.

It’s not uncommon for individual developer style preferences to creep into app development. A design system can eliminate a Frankenstein approach to building digital applications where apps look as though they’ve been pulled together through various unrelated parts. Not only does individual developer style result in inconsistency within or across applications, but it also results in CSS bloat. People invest too much time and energy defining styles when they don’t need to. A design system provides access to designs that already exist.

3. When You Separate Design Teams from UI Developers or Use Contractors

If the product owner isn’t the one who created the design vision, then the team handing off the project needs to make sure they effectively document the design, and developers aren’t the ones choosing how to implement it.

Think about building a house. A detailed blueprint gives precise guidance to the various contractors on the dimensions of the foundation, framing, electrical, plumbing, HVAC, and more. Leave it solely to previous examples, conversations or individual contractor preferences, and there is no telling what the house will look like nor how it will function when completed.

A design system creates design and development efficiency, especially for organizations that have or are planning to create multiple applications for its employees and customers.

Summary

Design systems are essential tools that help define brand interactions and promote consistent digital customer experiences. They are far more comprehensive than code comments or flat layout files.

As a prelude to a future blog, I’ll mention that Bootstrap, Foundation and Material are not design systems. They’re design frameworks. These systems still require someone to define common interactions, the brand voice and tone, and how the app should be architected from a design pattern standpoint.