May 11, 2023

To build a design system...

Yesterday, I kept things pretty simple. Today, let’s dive a bit deeper. Let’s explore the definition I gave yesterday in more depth and review some of the common parts of a design system.

A design system is a set of principles, procedures, and tools used to render the designer’s intended outcome.

First, what is a system? The dictionary defines it as:

A set of things working together as parts of a mechanism or an interconnecting network; a set of principles or procedures according to which something is done; an organized framework or method.

This is a good starting place, because a design system is just that — a system. When I first heard the term “design system,” I pictured a single artifact, a platform, a bunch of code, an application. But a design system isn’t any one of those things. It’s a collection of principles, procedures, and connected tools used to implement a design.

Which brings us to our next question: What is design? My favorite definition comes from Jared Spool:

Design is the rendering of intent. The designer imagines an outcome and puts forth activities to make that outcome real.

This brings us back to yesterday’s email. Stakeholders imagine something a customer might find valuable, designers visualize ways to make that outcome real, and engineers use that as a blueprint for building the digital product.

A design system can help by ensuring that important design decisions make their way into digital products consistently and efficiently. The more digital products you have, the more important this is.

Let’s get more specific about common tools and processes.

(If your company’s design system doesn’t have all of these pieces, it’s okay! I’ll talk about how to decide which parts of a design system makes sense for you in a future email. For now, I just want to lay the groundwork for readers who may be new to design systems.)

Design systems often include:

• UI kits: commonly used styles, libraries and design components that can be shared and reused across multiple design files;
• Shared assets: typefaces, icons, key artwork that need to be used in both design and software tools;
• Component library: a collection of common code components that can be shared and reused across multiple codebases, often with design, state, and behavior built-in;
• Tokens: design decisions in key-value pairs, abstracted so they can easily be used across a wide range of platforms, design and code;
• Documentation: guidelines about brand, aesthetics, usability, accessibility, common patterns, governance, contribution, etc.
• Reference site: a place to showcase your design system’s assets and documentation.

Tomorrow, I’ll go through these in more detail, including what tools are commonly used for each. If you want to take a deeper dive into the topic, I recommend the exhaustive Anatomy of a Design System by Ben Callahan from SparkBox. It's a fantastic resource.

...

Whew.

That was a lot.

Thanks for making it to the end.

Here’s an emoji… 🎉

—
Cheers,

Up Next: The DNA of a design system

← Full Archives