Systems, math and explosions (in no particular order)
Any sufficiently complex system is indistinguishable from chaos1. Systems are complex at baseline because they’re not just about collections of things, they’re also about connections of things. And connections add up fast. Take the following three collections of connected dots.
The first collection of three dots has three connections. Obvious. The second collection has nine dots, but now there are 36 connections. The last collection of dots has 27 dots, but the connections have ballooned to 351. This phenomenon is called a combinatorial explosion. It appears exponential in nature, but for the math nerds, it’s actually polynomial. Honestly, for the sake of this article, it doesn’t matter.
Combinatorial explosions are complexity explosions
Those who work on any kind of system know what combinatorial explosions are even if they haven’t heard the term. As pieces in a system increase linearly, its connections increase much, much faster. Consequentially, the system’s complexity grows much, much faster. Spoiler: That’s bad.
Let’s take the “Hello world” of complexity explosions for design systems—color palettes. The best color palette I made for a design system had seven colors. Was it constraining? Absolutely. But it was also manageable from a systems standpoint and highly approachable/understandable for those who used it. However, most systems have a hundred colors or more. Below is a visualization of all the 2-color combos in 7, 25 and 50 color palettes.
| Colors | 2-color combos |
|---|---|
| 7 | 21 |
| 25 | 300 |
| 50 | 1,225 |
| 190 2 | 17,955 |
I threw in Material’s 190 color palette in the table above to show how complex this can get in actual reality. The more complex the combinations become, the more large color palettes become essentially incomprehensible. How many 7-color combinations does a 7 color palette have? One. How many does a 190 color palette have? 1,585,940,245,560.
Piles of stuff are unpredictable
A system is a system because its connections work together. As a system grows, it becomes increasingly difficult to understand how everything works—or if it works at all. This rears its head in general unintelligibility, brittleness and unpredictability. At which point the system has officially devolved into a pile of stuff.
Unpredictability in particular is scary. Because unpredictability, is well, unpredictable. Unpredictable can result in good, bad, or horrible. It can be a combination of the three one minute, then none of the above the next. Which is chaos. And chaos is bad.
The ways we avoid complexity can also create complexity
But have no fear! People have honed plenty of tools to stave off complexity. The bad news is that the cure can be worse than the disease. That’s not to say these tools are inherently bad, but they have limitations which are often summarily ignored. Below are a few:
Compartmentalization obfuscates complexity
Compartmentalization is the go to when trying to simplify systems. It’s a great tool to turn one big, monolithic system into a system of smaller, more manageable sub-systems.
Compartmentalization is your basic org chart. The org chart is the quintessential definition of breaking a huge system of things (people) into smaller, more digestible sub-systems (teams). Some may question whether the org chart is a good example given their challenges. That’s the point.
One problem with org charts is they can create artificial barriers between people which make it harder for them to work together. These partitions don’t really exist in people’s day-to-day work, but are created anyway in the goal of simplification. Teams become siloed, overly focused on their own goals and lose visibility of the greater direction.
That’s the rub of compartmentalization. It can be difficult to create “clean cuts” where all important connections remain intact. This can lead to a disjointed system where elements don’t feel like they’re working together—because they aren’t.
Reducing connections moves complexity around
Just because two pieces in a system can connect, doesn’t mean they should. Explicitly paring down connections between pieces is another clear cut way to reduce complexity.
This can be achieved by restricting component APIs to only accept a subset of options. A system may provide 100 colors, but that doesn’t mean all of them should be available for every component. This significantly reduces permutations in a system.
On the downside, there’s added cognitive load to understand which pieces connect, and how. This load increases by how unique each set of options are for each component. Another downside is that rules can get complicated fast. One rule of thumb is to avoid rules with clauses. Once design systems start having rules like, “Do ____ except when ____ unless ____” you should just assume someone out there is losing their mind trying to understand or already gave up.
It also begs the question, “Why have 100 colors in the first place if 90 of them can’t be used half the time?” Which is a good question.
Abstraction creates layers of complexity
Another approach is to just make a subset of the system available to use. A simple, approachable public system is made available to all—driven by a bigger, gnarlier private one. This could also be seen as an extreme level of compartmentalization.
This approach creates less cognitive load—especially for beginners. The user benefits from a robust system under the hood, but with far less options to get themselves into trouble.
But of course there are downsides. First off, a public and private system means more systems to deal with. Secondly, abstraction risks long-term confusion as people begin to see that they aren’t provided all the options. That will beg the questions, “What are all those other options not available to me?”, “Why can’t I use them?” and, “Why does the system get to play by a different set of rules than me?” Which are all good questions.
Reduction is the only real way to reduce complexity
The tools outlined can be effective when well-employed. But math is math. Linearly remove pieces in a system and the connections decrease much, much faster. Treating the symptoms of complexity often just redistributes it. In short, the best way to avoid the pitfalls of complexity is to avoid complexity altogether.
But make no mistake, reduction ain’t no walk in the park…
Stifling order or cataclysmic chaos
Robin Rendle mentioned that design systems are hyperobjects. For the uninitiated (which included myself until a few weeks ago), hyperobjects are things so big that it’s beyond human understanding. I don’t think all systems are hyperobjects, but plenty are. I don’t think it’s interesting whether systems can by hyperobjects as much as how quickly they can become one. One second, you’re fine. The next, chaos.
I don’t know many people who find chaos appealing. Why then is it so prevalent? Here’s my theory: we’re willing to accept the mess because it’s comfortable.
Avoiding chaos seeks out conflict. Complexity explosions are fueled on “Yes” and starved by “No”. “No” brings dispute. It’s painful, exclusionary, stifling. It won’t make you the life of the party. And it typically takes incredible discipline to sustain.
Uncomfortable as “No” may be, it’s ultimately the simplest way to keep an explosion from becoming an explosion.