Less rigid design systems

In The Design Systems We Swim In, Ethan Marcotte asked a thoughtful question about design systems:

Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?

Ethan makes the case that many design systems promise consistency, but perhaps at a cost. The article urges us to collectively consider the implications and suggests we figure this out sooner rather than later:

I don’t know if there is a design system operating at scale that empowers its designers and developers to use situational judgment, that “allows free, playful application.” If there isn’t, then we’ll collectively need to figure out what that looks like. Very soon.

What would it take to start swinging the pendulum back towards less rigid design systems that enable experimentation, while at the same time promoting consistency?

I don’t claim to have the answer, but here are a few ideas that I thought I’d contribute to the conversation:

Inform the consumers of your design system that they are encouraged to experiment with new ideas. If no one is explicitly communicating to designers and developers that they are free to experiment with approved patterns, then how can we expect contributors to be comfortable with “breaking the rules”?

Many style guides include “do and don’t” guidelines. They provide clear examples of what is allowed and what is not. With regards to promoting experimentation, try to identify patterns in your system where contributors will benefit from clear boundaries defining where creative applications are welcome and when they should be avoided.

Does your system include a place for contributors to prototype, experiment and play? In Encouraging Play in Design Systems, my teammate Tyler mentions:

…a design system without a clear and approachable strategy for free-form, collaborative contributions can accidentally discourage innovation.

Additionally, monthly in-person meetings, a dedicated Slack channel, or newsletter might further encourage a welcoming environment and help promote experimentation. Robin Rendle has shared his experiences with starting a newsletter and how it benefited their team’s system.

Incorporating a well-thought-out set of utility classes in your system might also encourage some of the playful, situational control we’re seeking. Utility classes provide immutable one-off CSS classes that are intended to perform singular tasks, such as controlling spacing or assigning color to an element.

This can provide opportunities for expedient, inferential decision-making in various stages of the design process by empowering creators to rapidly experiment without writing new CSS. Other techniques, such as scoped CSS within single file components, could accomplish similar results.

Not everyone with interest in contributing to your design system will be comfortable navigating your tech stack or running a sophisticated build system. Make sure that your method of collecting contributions is welcoming to static mock-ups, screenshots, and even text-only suggestions.

Furthermore, design tokens might provide another way to help elevate collaboration.

…design tokens improve collaboration by empowering non-developers to engage with code thanks to a more human-readable language

Sound interesting? Then I recommend Thibault Mahé’s post on how design tokens can further bolster collaboration.

It’s unlikely you’ll reap the benefits of any of these ideas without a clear path for standardizing the best experiments. Consider formalizing a process for reviewing and incorporating worthy additions (or departures) from your existing patterns.

I hope that the systems we create can support and help inform our decisions, not control them. If our design systems control our decisions too much, I’m afraid we’ll find our websites may look increasingly similar once again.