Design system: a democracy or autocracy?

By Pekka Puhakka, Senior Visual Designer

Design systems come in all shapes and sizes. From super coherent ecosystems built around a single service to Frankenstein’s monster of a global product ecosystem stitched up over years of mergers — all while making a monolithic brand. At the end of the day, every design system is a community of diverse expertise, so how should we rule them all?

I argue that:

• Autocratic decision-making scales poorly on a design system of a dispersed global organization
• Sharing the responsibility of contributing to a global scale is good for the relevance of the products
• A design framework aims to keep the design system consistent by evolving throughout the years

I get inspired by design systems for the possibility to build and manage brands in the increasingly digital future. And at the same time, I think that to create a design system is primarily to create the infrastructure for change rather than to build a monolithic brand.

At Idean, we took a holistic look into design systems together with Adobe in a book called “Hack the d̶e̶s̶i̶g̶n̶ system” on which I can’t take much credit for a̶n̶y̶t̶h̶i̶n̶g̶ ̶o̶t̶h̶e̶r̶ ̶t̶h̶a̶n̶ ̶c̶o̶i̶n̶i̶n̶g̶ ̶t̶h̶e̶ ̶b̶o̶o̶k̶ ̶t̶i̶t̶l̶e̶. In this book, we mention the connection between the 1975 NASA brand book and many other design systems.

I am not here to compare new digital services to printed medium created 50 years prior. I see them existing for brand strengthening purposes — just in a different time and context. NASA distributed a beautiful brand book through their organization to help crystallize one of the most trustworthy brands of the ’70s.

Facilitating the change

Working in a core group trying to build a design system for ABB, a conglomerate with over 1,500 digital products across the globe, has left me to understand the enormous, if not impossible, task to grasp every product and service. The knowledge of these products and services should already exist within product teams. It is here where we need collaborating: to build a product portfolio with a consistent look and coherent feel, but still relevant to the end-user.

I approach such collaboration with extreme transparency, promoting equal possibility to contribute but also demanding shared responsibility to carry contributions through the test of time.

The design system’s core group needs to have a facilitating role. The final validation can only happen through testing with actual users in a realistic market context. Design and development require a framework for democratic decision-making. To create, evaluate, and evolve is a collaboration framework that a design system’s core group is responsible for.

Shifting the design work to a cloud environment is one way of doing it as it brings us closer to democratic decision-making by offering transparency. Another key requirement is a shared culture that also takes into account the diversity of team members and the differences in time zones, cultural environments, and weekly/quarterly/yearly calendar routines. Democratic decision-making needs time. Too fast movements and non-holistic choices in design become a mess over time.

I’d also argue that making decisions on the design of the components is not making decisions over the actual components. Regarding the coded components as a single source of truth is a well-recognized approach: an open-source model is already built into the culture of software development — sharing code and software to enable each other to make better products and save time.

Consider design systems as a greater concept than just shared design language or shared and systematically distributed codebase combined. Both design and development need to work closely under a single framework where decisions on design are made and where developers are allowed to experiment on components forked from the main code base on their development sidetracks.

Let’s explore

Begin with standard versioning for minor and major updates and keep a shared change log openly available. Create a hub with a voting mechanism to let the community decide which forked components are merged back into the main codebase. Borrow a social media platform for arguing and counter arguing among the extended community. The expectation is to come prepared and with arguments to back your design decisions. The core group act as moderators and promote positive and constructive critique. Leave the core group the right for a limited veto to ensure the holistic view and ability to nurture small improvements into more significant movements.

This is why I think creating and up keeping the design framework is the main responsibility of the design system’s core group. Facilitating and not ruling. More so if there is not a single clear product DNA behind the ecosystem. Trust expertise but test with real users in a real context. Grant the core group a holistic view over the brand and entire ecosystem but equally value the product team’s in-depth knowledge of the products and services.

Most of all, promote a culture of transparency and constructive behavior in communication to avoid stagnant culture or fear with indecisiveness and over-engineering. Being wrong might not be a virtue, but it’s still better than nothing since, in a changing world, it is most important not to stall. Sometimes trial and error might be the only way out.

Thanks to my colleagues Elisa Pyrhönen and Joe Smallwood, for their editorial assistance and guidance in keeping me relevant while showing empathy towards other designers that are caught in the systems.

Download the book: “Hack the Design System” →