Sustainable Design Systems
decoupling purpose from outputs
What are Systems?
Note: This article references several concepts from systems thinking, most of which are derived from Thinking in Systems: A Primer by Donella H. Meadows. If you’d like to learn more about systems thinking, I would highly recommend it.
We can think of any system as a collection of interconnected elements that serve a purpose or function. Let’s use a campfire as an example. We have elements: wood (fuel), oxygen, and heat. And those elements are interconnected. If you deprive the fire of fuel or oxygen, it decreases the heat. And if you increase the heat, you deplete oxygen and fuel more quickly. This system also has outputs: heat, light, smoke, and sound. Sometimes the outputs are the purpose, but usually they serve a larger purpose. In the context of a campfire, light, smoke, and heat are not the purpose of the system. It’s likely we started this campfire to provide warmth and comfort, or to prepare food, or to have a nice place for conversation. We’ll revisit this later, but hopefully that’s an approachable system analogy.
How does this relate to design systems? We can break down a design system into the same parts. It has elements: components, docs, tools, designers, engineers, product owners, and the organization it supports (to name a few). Those elements have interconnections. Often the organization provides the context and parameters for the system, and the designers, engineers, and product owners use tools to build the implementation. As you might have guessed, with a system this complex, there are subsystems within the system. For example, the design team is a smaller system, with its own elements, interconnections, and purpose. The same is true of the engineering and product teams. All of these interconnected sub-systems create complex behaviors which drive the overarching purpose and function of the design system. It’s important to note that a system’s stated purpose might not be its actual purpose. You can structure a system with the one intended purpose, but it might serve a completely different purpose in the end. But with that said, what should be our intended purpose for a design system? Why are design systems valuable?
Advocates for design systems often mention:
- increased UI consistency across teams
- faster development time
- fewer bugs
- increased focus on higher-level concerns (app performance, UX, etc)
Those are all great benefits and valuable metrics. They’re tangible selling points that are easily explained regardless of someone’s familiarity with design systems.
The problem with over-emphasizing these qualities is that they are essentially outputs of the system, not its purpose.
Decoupling Purpose from Outputs
If the purpose of my campfire is producing light, smoke, and heat, I’m only focused on making the flames bigger. I can add an accelerant (gas, alcohol, etc) to the flame and see a sudden burst of output. But I can’t easily control or sustain the output with my input. The accelerant causes the flame to consume more oxygen and increase in temperature. But when my accelerant is exhausted, the flame can’t be sustained. Hopefully the system can bounce back, but the system might have become too imbalanced to recover.
Similarly, it’s very challenging to optimize your inputs to achieve the outputs of a design system. It’s too complex, and as a maintainer, there are too many variables that are out of your hands. If you try to over-optimize for UI consistency, you’ll end up with a system that is too rigid or can’t adapt to consumer needs. If you over-emphasize development speed, you’ll likely sacrifice quality.
Instead, we should optimize for resilience and adaptability.
Optimizing for Sustainability
Any successful system is able to adapt to change and bounce back, and this is the real value of a design system. UI changes rapidly, and you have no idea what your applications will look like in six months to a year. For example, I’ve been at SendGrid for nine months at the time of writing this. Our team has completely rewritten the same application twice already, and we will likely rewrite it again in the next year. I could guess what it will look like, but I honestly have no idea. And if you’ve been working in software long enough, you’ve probably had a similar experience. If you’re optimizing for your outputs, you’re likely building for the UI you have today, but that likely won’t help you sustain your system. You’re throwing accelerant on the fire without thinking about how to make the system sustainable.
A design system is a large investment, and the only way it becomes a net win for your organization is if it can help you manage change over time. It needs to be adaptable enough to evolve with you as your needs change. And when your processes are disrupted, it needs to be resilient enough to bounce back and recover. Consistency, performance, and fewer recurring issues are all valuable outputs, and those metrics should be a part of your feedback loop. Who cares if your design system is resilient if it doesn’t help ensure consistency or improve development speed? But when structured properly, those outputs feed the sustainability of your system as a reinforcement loop. As engineers experience faster development, product owners see fewer bugs, and designers see more consistency, they become more invested in building a sustainable system. In short, track your outputs for metrics, but be careful not make them your purpose.
Thanks For Reading!
You can find me on Twitter and GitHub. If you enjoyed this, you should also subscribe to my newsletter! https://tinyletter.com/alanbsmith
