📈 Designs systems isn't a trend (#37)

Hey! Happy Wednesday.

Like any innovative endeavor, there’s some backlash against design systems in the industry. Design systems is often called a “buzzword,” and there are constantly hot takes making fun of if on Twitter. I don’t think “design systems” is a trend. I think it’s just the way that we will build for the web moving forward. It’s a mindset shift, just like agile or responsive design was.

It’s true that large-scale design systems initiatives aren’t a fit for every company. Not every single company needs to build Material Design — that would be impractical.

But I think that just about every company (with the potential exception of very early stage startups) could benefit from applying design systems thinking to their design and engineering efforts.

I think a lot of this criticism comes down to a misunderstanding of what design systems actually is. In my (controversial) opinion, all of these examples anything can qualify as design systems as long as it intends to:

• improve design consistency within a single or between multiple applications,
• increase the speed of design and development within an organization,
• improve the collaboration between designers and developers, and/or
• reduce the amount of effort applied to achieve some level of compliance (legal, accessibility, web performance)

I know, I know — this sounds odd. I can explain myself, but it’s going to involve a brief detour into systems theory.

A Brief Introduction to Systems Theory

Donella Meadows, the author of Thinking in Systems: A Primer defines a system as “an interconnected set of elements that is coherently organized in a way that achieves something.” All systems consist of three parts: elements, interconnections, and a function or purpose.

Elements

Elements are discrete entities that make up a system. Meadows uses a tree as an example: “the elements that make up a tree are roots, trunk branches, and leaves. If you look more closely, you see specialized cells: vessels carrying fluid up and down, chloroplasts, and so on.”

A tree contains certain things that make the tree system work — but a tree system isn’t defined by the fact that it has roots. It’s just one aspect of the system.

Let’s apply this to design systems! I’ve defined some common elements that we find in design systems across the industry:

• design assets
• consumers
• implementers
• design tools
• component libraries
• documentation
• release strategy
• design tokens

Each of these elements may or may not be present in a design system. Some design systems contain all of these elements and more, while others only contain one or two. But we can’t determine whether something is a design system only by naming the elements it contains. A collection of elements is not a system –– we still need to define the system’s interconnections and purpose.

Interconnections

Meadows defines interconnections as the “relationships that hold the elements together.” She returns to the tree system to exemplify how elements are interconnected in a system:

The interconnections in the tree system are the physical flows and chemical reactions that govern the tree’s metabolic processes––the signals that allow one part to respond to what is happening in another part. For example, as the leaves lose water on a sunny day, a drop in pressure in the water-carrying vessels allows the roots to take in more water.

To define a tree system works, we can’t just know that a tree has leaves. We also need to understand how leaves interact with other aspects in the system — for example how the leaves help the tree to manage its water intake.

Design systems work in the same way. For example, a design system isn’t defined by having design assets. We also need to understand how the assets interact with other aspects of the system.

There is an infinite number of possible interconnections in a design system; I’ve listed some below:

• design constraints
• the feedback loop between implementers and consumers
• the cadence at which implementers update documentation
• the amount of money the company invests in the design system
• the way that components references design tokens
• the project management process that shepherds components through design and development

Not all design systems contain the same interconnections. We can’t define a design system based on the elements or the interconnections; we can only define it based on its intended purpose.

Purpose

The function (for systems not designed by humans) or purpose (for systems designed by humans) can be determined by how the system behaves. To return to the tree example once more, one function of a tree is to consume carbon dioxide and release oxygen into the ecosystem.

Meadows writes:

A system’s function or purpose is not necessarily spoken, written, or expressed explicitly, except through the operation of the system. The best way to deduce the system’s purpose is to watch for a while to see how the system behaves.

The only way to accurately understand a system’s purpose is by watching its behavior.

We cannot dictate how a system behaves, or what its purpose is. We can only try to adjust the elements and interconnections of a system to impact the system’s behavior. This information is relevant to those of us working on design systems who find that what we’ve created isn’t achieving its intended purpose, but it doesn’t help us to define design systems.

Defining “design systems”

The only way to define a design system is by its intended purpose(s). With that in mind, I’ve settled on the following definition of design systems.

A design system is an interconnected set of elements intended to:

• improve design consistency within a single or between multiple applications,
• increase the speed of design and development within an organization,
• improve the collaboration between designers and developers, and/or
• reduce the amount of effort applied to achieve some level of compliance (legal, accessibility, web performance)

Anything, whether it’s a component library, whether it’s a collection of design assets, whether it’s as robust as Material Design, can be considered a design system as long as it meets one or more of the intended purposes in that definition.

What do you think? Is design systems just trendy right now, or do you think it represents a larger shift in the industry? Reply to this email and let me know (or just say hi, I’d love to hear from you).

Talk soon,

Mae