Design System Frictions

Creating a design system to serve an organization’s digital products is a delicate dance of decision-making, compromise, and balance. There are some intrinsic frictions that every organization creating and maintaining has to address.

There’s no shortage of eternal battles in the web design and development world.

All of these tool and technology decisions are perfectly valid. There’s no wrong answer to these questions, but many of these tool and technology decisions have real implications on both the final user experience and the team’s workflow.

When no constraints are imposed, every individual making digital products has total freedom to choose whichever tools and technologies they please. The resulting experiences and workflows look a little something like this:

Complete chaos obviously isn’t ideal. OK, so let’s impose strict rules to limit what can and can’t be used to make digital experiences:

Extreme rigidity! While imposing strict restrictions can certainly create more efficient workflows and more consistent products, it can also be super oppressive as well. In this kind of environment, flexibility and creativity may be quashed in the name of coloring inside the lines.

Both are these extremes aren’t desirable, so what’s a team to do? It’s important to find the place on this spectrum that imposes enough constraints to avoid complete chaos, but also provides teams enough flexibility to be creative and effectively solve problems for users.

This spectrum between complete chaos and extreme rigidity is just one of the intrinsic frictions design systems teams regularly encounter. There are lots more. Here’s a few:

  • A design system’s ingredients need to scale across products, but also needs to effectively serve the specific needs of individual products.
  • A design system needs to provide a comprehensive set of components for teams to build products, but not so many that will overwhelm everyone, bog down performance, and make the system unwieldy.
  • A design system’s components needs to provide a flexible set of variations to address most use cases, but not so many that the components become overloaded with unnecessary features and bloat.
  • A design system needs to be implementable via specific tools and technologies, but it also needs to be bigger than any specific tool or technolgy implementation.
  • A design system’s style guide needs to serve as a watering hole for everyone involved in the success of digital products at an organization, but it also needs to serve the needs of core users extremely well.
  • A design system team needs to represent the needs of many perspectives within the company, but it also must avoid a too-many-cooks situation that paralyzes progress.
  • A design system needs to evolve and remain fresh, but also needs to avoid bogging down product teams with endless updates.
  • A design system team needs to be open to contributions and improvements from people across the company, but it also can’t be so wide open that it gets flooded with arbitrary additions that erodes the integrity of the system.
  • A design system’s style guide documentation needs to be thorough, but not be so verbose or dense that it overwhelms people.

There are no doubt plenty of other design system frictions every team has to face. I think it’s important to recognize that there are no right or wrong answers here; it’s up to the team to plot these options on a spectrum and then find the sweet spot on each spectrum that will lead to great user experiences and efficient workflows.