This is the first entry in a two-part series covering various strategic and functional aspects of design systems.

The challenges discussed in this entry are specifically relevant to individuals that have roles in design leadership, product ownership, and user interface design.

A Design-gineer Walks Into A Bar

Depending on my current mood on any given day I either describe myself as a designer who codes, or a coder that designs. Ultimately, I am passionate about building user experiences and believe designers and developers need to continuously collaborate in order to succeed.

In the post-2016 era of web apps, the professional chasm between designers and developers has grown to be untenably large. I have noticed this individually in the more acute nature of the roles I have performed, and more broadly as an observer of how modern engineering organizations are hiring into and structuring their teams.

This phenomenon has created significant downstream externalities for user experience outcomes (to be discussed at length in the second post in this series). There is a silver lining to be found, however, in the absolute explosion of discourse on how to resolve, and subsequently systematize, the complex relationship between designers and developers ranging from handoff to implementation to iteration.

This brings me to design systems.

Design Systems. Design Systems. Design Systems.

How many times have I heard, spoken, or read this term in the past few years? I'd estimate somewhere in the low thousands. Additionally, if we include professional engagements with roles in both design and engineering capacities, I have personally contributed to approximately two dozen design systems across teams varying in both size and ambition.

I’ve seen things you people wouldn't believe.

And what I have seen is an extremely high and predictable rate of failure that appears to be entirely independent of any flavor of design tooling or programming technology. These failures are not attributed to poorly designed or implemented components but rather a very specific combination of strategic ambitions (scope and governance).

The third post in this series will share some simple rules for teams to consider in hopes of avoiding these pitfalls, but to get started we will cover some necessary context.

Let’s Define A Handful Of Terms

There are two primary dimensions that determine the strategy undertaken by any given design system:

1. Scope; or how ambitious you intend to be regarding what tokens, patterns, utilities, layouts, and components you aim to include in your design system.
2. Governance; or how aggressive you intend to be in restricting product teams to designing and developing user interfaces strictly within the boundaries of design system.

Additionally, there are two primary dimensions used to quantify the success or failure of any given design system:

1. Adoption; or how many teams actively use the design system, and what percentage of the design system scope they are implementing in practice.
2. Velocity; or the degree to which product teams are able to achieve better outcomes faster as a result of having the design system at their disposal.

Visualizing Strategic Risk

Behold, a two dimensional strategic plotting of the design systems I have personally contributed to with their corresponding success or failure:

The data, albeit anecdotal and incomplete, speaks volumes. Let’s unpack what it is telling us.

1. Starting from a position of minimum possible scope and governance, which is essentially a state of endorsed chaos, teams have non-existent adoption and poor velocity.
2. As scope and governance increase the rate of adoption and return in velocity will begin to manifest in product teams across an organization.
3. Once scope and governance cross murky and ill-defined thresholds, we see something far worse than diminishing returns. We see a return to non-existent adoption and poor velocity.

And Now For A Rorschach Test

To help bring the strategic risk out of the abstract, included below is a screenshot from a real world example I am working on right now.

There is little to debate here regarding what basic tokens and components will emerge from the above design. Find me any ten designers, and they will all deliver something roughly similar to this:

Piece of cake…right?

Why am I even writing this blog?

Because Scope and Governance

Once we move past the obvious tokens (color, radius, font family/size/weight) and elements that compose them (button, input, label), we quickly arrive at a variety of judgements made by the product designer that are up for debate as to whether or not they should be systematized.

1. Should the font tokens become a scaled and generated type system with unit conversions?
2. How do we accommodate developer discretion on the appropriate semantic element in various typographical circumstances?
3. Should the form layout become a grid system?
4. What are the minimum/maximum elements per row?
5. Where should the responsive break points be?
6. Do the user agents broadly support CSS Grid?
7. Should the margin between two adjacent child elements be standardized?
8. How many form elements mandate toggling visibility of advanced controls?

Even for the simplest of examples, we see how the list of all potential considerations will likely grow into the dozens. And what I have found with great regularity is that teams specifically tasked with creating a design system rapidly devolve into creating the design system.

Look at the strategy deployed by Google’s Material Design. They created a type system so complex that you need to be a physicist in order to grok it, and yet without rational justification they decided to reinvent the label-input-placeholder behavior in their own image which inevitably failed usability testing.

Alternatively, look at the strategy deployed by Facebook for their recent design overhaul. They so desperately wanted to systematize margin that they actually resorted to jamming spacer divs between adjacent children of a parent.

These are industry leading technology companies with design and development teams that are not exercising appropriate and necessary caution, yet advertise their efforts as though they were aspirational.

These teams aspire to build the perfect system, in their own image, platform and product be damned.

The Bottom Line

Here is the bottom line that you have been patiently waiting for:

1. Creating an all-encompassing design system requires a scope so broad that it provides answers to all questions.
2. If the design system aims to answer all questions, to achieve an adequate return on this monumental effort would require near universal adoption.
3. Aiming to achieve universal adoption will incentivize pursuing the most aggressive governance model.
4. As the governance increases, it overrides any conflicting judgement from product teams that might better understand how to serve their users’ needs.

At this point, product teams that inevitably expose a deficiency in the design system have to choose between two undesirable options:

1. Give design system feedback and patiently wait for future integration. This destroys velocity.
2. Circumvent the governance model and pursue a custom solution. This destroys adoption.

And this is how design systems fail again and again and again and again.

What’s Up Next…

The second post in this series will be a heavily technical discussion on how a design system with an unimpeachable strategic approach can still go haywire on account of over-engineering.

Until then!