🌌 Design Systems and Systems Thinking (#61)
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 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 industries:
- design assets
- design tools
- component libraries
- 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.
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.
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.
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.
Do you want design systems tips and tricks sent to your inbox?