On the Design Systems Between Us

Ethan Marcotte just gave a fabulous remote talk at SydCSS on the nature of design systems and the challenges of creating and maintaining them over time. Ethan managed to comprise so many of the things I’ve been hearing, noticing, and thinking about in such a concise and clear way I could never articulate it. If you are working with or planning to build a design system – and who doesn’t, these days – I can’t recommend this talk enough.

Four of the things Ethan talked about stood out to me. They often get overlooked yet are so important to get right if you want to make the best of your design system.


Design systems and pattern libraries are a blessing in that they enable us to design modular systems. We can look at single components and design patterns individually and improve them over time. But very often, this design process happens in a vacuum. We focus a lot on the initial design of a pattern but it is difficult to say where and how the pattern is actually used in the wild by different teams and as time goes by. By making visible what the actual impact and real-world applications of a design system look like, it can be far better adjusted to the reality and needs of the organization. And for designers, it is easier to see everything that’s broken.


One way to increase visibility is to look at design patterns in context. No pattern exists in isolation. It always shapes and is shaped by its environment. And on today’s Web, the number of possible contexts is endless. A component can be used on different pages and products, on different screens, in different browsers, with different content, or also be used by people with different abilities or cultural backgrounds. The more we respect this reality of varying contexts, be more robust but also flexible our system will become.

Prescriptiveness vs Flexibility and Exploration

Design systems are built to improve consistency and efficiency across teams and products. But while the focus on modularity and implementation is indeed improving consistency, this consistency comes at a price. Once established, design patterns seem to be cast in stone. This is because our components are mostly documented in a prescriptive way. This is how the component looks and behaves. And this is how it has to be used. It’s sink or swim. As Ethan notes, this prescriptiveness limits our design systems because it stifles creativity. What we should be looking for instead is to create systems that put design principles over specification and allow for exploration and the playful application of patterns within useful constraints.

As a strictly designed grammar, the system allows free, playful application. This is comparable to ball games or chess, where fixed elements and an agreed set of rules allow playful freedom.

Otl Aicher

Process and People

But regardless of how well-conceived our design system is, it is important to remember that it is a tool that is primarily meant to support people in making better work together. Ideally, a design system can foster collaboration and create a shared language. This will only work, however, if the system fits the processes of the organization and the way people work – and if we recognize that humans and the interactions between them are a core component of every design system. As Ethan emphasizes, it is only then that we can design systems that support the work that we want to do.


This is the 61st post of my 100 days of writing series. You can find a list of all posts here.


6 Webmentions

Photo of Ethan Marcotte
Ethan Marcotte
That is an *impossibly* kind write-up, Matthias. Thank you.
Photo of Matthias Ott
Matthias Ott
I have to thank you, Ethan! Your talk was a delight to watch (and rewatch). So many insightful, well-articulated thoughts and a great delivery as well. It was obvious that a lot of thought and care went into this talk. 🙌;
Photo of Ethan Marcotte
Ethan Marcotte
(If it’s of interest, I mentioned a few of the folks whose work informed the talk: ethanmarcotte.com/wrote/before-d…)