Interrelationships in design systems
While talking about design systems, I recognized that we are mostly talking about pattern libraries. A functioning design system not also consists of the building blocks themselves but also has a set of rules that form the glue between components and people.
I was involved in the creation of the design system for a car manufacturer’s new global digital design working for the agency SinnerSchrader. In this playbook I collected our successes, failures and other learnings from my research around this topic. This article is about the greatest essence of my learnings: Interrelationships in design systems.
What is a system?
First of all, I would like to make an excursion into systems theory. In this lecture Donella Meadows offers a really simple introduction to her definition of systems:
“System = a set of interrelated elements organized to serve a particular function or to seek a particular goal”
She describes the different parts of her definition in this way:
- Elements: This is the stuff you can count, measure, and see. For example the people, a factory, or physical things.
- Interrelationships: They’re the rules of the game like punishments, prizes, or information signals. The elements won’t change a system, the interrelationships do. If you change the players of a basketball team, the game is still basketball. If you change all students and teachers of the University of Michigan, it’s still the University of Michigan.
- Function/goal: This is what the system produces. It is not what we want the system to do, it is what the system is actually producing. The goal of the economic system is growth.
Her definition shifts the mindset from thinking about the building blocks to thinking about the connections. Let’s see in the following article what these three categories could mean for a design system.
Elements
As I have already mentioned, I believe that enough has already been written about the elements of design systems. Therefore, I will only give an overview which elements can be important in a design system:
Interrelationships (of people)
Donella Meadows emphasizes that it is not the elements that change a system, but the interrelationships. In the following I have collected what kind of interrelationships occur in a design system. Since the topic is very broad, I will divide it into “interrelationships of people” and “interrelationships of components”. My question behind this is: What can we do to connect the elements?
Team setup
“A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.”
— Nathan Curtis
According to this article by Nathan Curtis there are three different team setups possible: Solitary, centralized and federated. Each setup has its advantages and disadvantages. As he states in this tweet a mix of a centralized and federated approach combines the best of both worlds.
What we learned at SinnerSchrader is:
- You really need a dedicated team, which is working on the design system. Our design system was a project (instead of a product). And that meant we had no official contact person, no official team, no backlog and no time to do things right. Without the elements of a product team, it is not possible to meet important factors of a design system to build trust and increase the acceptance.
- A centralized design system person can also be a huge bottleneck. Knowledge should not be stored in people, but in processes (→“transparency”).
- If you don’t include the perspectives of the product teams they can easily deny the design system and no one wins. If the product teams are expected to contribute to achieve overall consistency, then this goal must be defined with authority and the teams need dedicated time for that (→“goal”).
Infrastructure
“Be ready to accept help.”
— Inayaili de León
We often couldn’t accept help because we didn’t have the infrastructure to do so. If someone offered four hours of their time, it would have been too much effort to explain to them in person what could be done. We had no ticket board and no getting started documentation for these kind of helpers. To avoid this, Inayaili de León recommends to tag issues on the ticket board with the label good first issue, so that helpers can start immediately working.
Another infrastructure can also be a physical space for discussions. For this workshop, I printed out the entire website on which the product teams worked on, to offer a holistic overview. This way we could see everything at a glance to understand the relationships across the pages. Alla Kholmatova writes in this article about how they also use a physical space for language conversations.
Meetings
For this topic I can really recommend this article by Magera Moon, which offers a lot of good collaboration concepts like these:
- Design systems council: The design system council is a group of representatives (product-area, subject-matter, or platform experts) who meet every two weeks. They talk about updates and make decisions. The representatives rotate every six months. This concept is the answer for the centralized & federated team setup!
- Design bug rotation: Every two weeks some designers meet to have a look a design bugs (which are collected on a ticket board). Design bugs are things which are not bad for the functionality of the site but still bad for the experience.
- New hire boot camp: This boot camp is made for new design colleagues, who have the possibility to join the design systems team for 2–3 weeks. In this time they learn how to use the design system and become strong advocates of it. For the Design Systems team this also offers fresh input. Win win!
- Design systems yearly rotations: It is also possible to spend two weeks in the design systems team if you are not a new colleague. In this way everyone has the possibility to gain a holistic overview of the product and to shape the design system for their own needs.
I can really recommend the bootcamp concept. We have visited several markets in other countries who use the design system. We were on site for a week and offered introductions and working sessions. Because the participants could give immediate feedback, we knew exactly where further documentation was needed and could prepare that back home.
Transparency
“Missing information flows is one of the most common causes of system malfunction.”
– Donella Meadows
Nothing can be taken for granted. In my opinion, accessibility even starts in the own team with documenting abbreviations and conventions. Not only quiet people benefit from this kind of documentation, but also people who work remotely. Documentation sets expectations really clear and lowers the barrier to collaborate. To create transparency, you can:
- Document everything: Hayley Hughes describes in her article how documentation offers context. This is needed in order to understand or challenge a decision. If the context changes someday, future teams can use the documentation to evaluate existing components.
- Share your beta states: This is not just about transparency, this is also about letting the community do the work for you. Nick Colley explains in this talk how they publish new components with the label
experimentalto invite the community to start researching and sharing that result. - Use a changelog: A changelog enforces people to think about the impact of the work and changes they’ve done.
Feedback loop
“The design system should not inform the product design. The product design should inform the design system.”
– Dan Mall
Setting up a design system is one step, but another one is answering to the real usage. Close the loop with offering a feedback channel. This is the truest and most courageous step to prove interest in a really good and functioning system. If users are able to collaborate, they become advocates.
- Component check-ins: Bethany Sonefeld explains in her talk that at IBM they use bi-weekly component check-ins as an open consultation hour (→“meetings”). These meetings are not to approve, deny or decide on other peoples work. These meetings are meant to learn from real use cases. In this way they give the users of the design system a chance to communicate.
- Listen to the quiet ones: Inayaili de León states here how important it is to allow quiet people to have the same impact as loud people. This can be achieved with using a living agenda in a meeting and with documenting decisions (→“transparency”).
- Measure time and happiness: Alex Skougarevskaya explains how Atlassian is measuring the time their designers need to accomplish a task. In this way they found out, that one of the most time consuming tasks is creating tables. That’s why they’ve built a Figma table plugin to support the designers. Atlassian also measures the happiness of their design system users. If the satisfaction is trending up, and they’re also saving time, they pursue a healthy way of growing.
- Showcase: Brand Estonia shows here how their design system is applied on different touchpoints. This kind of documentation allows the users to learn how the design system expresses when it is used correctly. Users who are just starting to design something can benefit from already finished products – this closes the loop.
Interrelationships (of components)
In this chapter, I will focus on how the interrelationships between the components can be achieved.
Patterns
“You can’t start with individual components in isolation. Successful design patterns don’t exist in a vacuum. Successful design systems start with content and people.”
– Yesenia Perez-Cruz
Patterns are one of the invisible building blocks that hold a design system together and make it valuable. Patterns are precomposed combinations of components, content, interactions, sections or zones. They help your design system users to combine components in the right way.
I personally believe that the field of “how to combine predefined components in the sense of the design system” has not yet been fully explored. A step in this direction could be to use “interaction flows”. An interaction flow describes in which direction the user uses a component composition. It is made up of a header, a body and a footer. For example this login screen will be used from the top to the bottom:
There are of course a lot of interaction flows imaginable. Here are some examples:
A small set of applied interaction flows offer conformity with user expectations. Because the user always knows where to expect the next step. Interaction flows also help to think in an abstract way about the user’s interaction instead of just starting to combine components.
Meta patterns
GOV.UK created something that I would call meta patterns. These meta patterns don’t need components to exist. I like this way of thinking about an interaction concept itself instead about the combination of components only. Here are two examples:
- Pattern with components: ask users for payment card details
- Pattern without components: help users to create a username
Principles
The design taste of our design system was basically defined upon editorial screens. Because we missed to define some functional screens, our base for the font sizes and spacings was completely biased. We just didn’t had the functional parts of the website in our mind.
This talk of Yesenia Perez-Cruz and her explanation of “big levers & small dials” was really a revelation for me. Her concept shows that it is a fallacy to believe that you can define an entire design system using the exact same set of principles.
The “big levers” treat principles as a range:
Although both of these pages can be from the same company, they look totally different because they have different functions. You can use these “big levers” to define a rough direction for the respective pages. In the second step, the “small dials” (specific values) such as font sizes are derived from the big levers. This process helps to transform a design taste into a comprehensible construction manual.
Many designers feel restricted in their creativity while applying a design system. If you define ranges for your principles, you can also define in an easy way where variation of your system is allowed:
And while you have created principles as a range you also lay the foundation for future products that you don’t know yet.
Nomenclature
An overarching nomenclature can help navigate the design system. For all elements, which have different sizes or gradients, we use an overall numbering system. A lower number always stands for small or light. A higher number always stands for large or dark. The number of a name has intentionally nothing to do with an actual value of e.g. the size. If you name a headline with 12px size headline12, you can’t change the value of 12px afterwards, because it is linked to the name. If you name the style headline100 instead you could easily increase the value to 14px without breaking a rule.
Architecture
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
– Melvin E. Conway (1967)
Our design system was made for the touchpoint web. It offers the common ground for the different product teams with approx. 30 components. The product teams also have the freedom to derive their own systems from the core system. The system web itself was derived from the digital stream, in which the web and in-car are also located. This creates additional coordination effort, as all these touchpoints use the same foundation, which also has to be documented. The clearer and more comprehensible these exact dependencies, nestings and hierarchies are communicated, the easier it will be for your users to find their way around the set of rules and thus apply them correctly. It really makes sense to think about these political dependencies beforehand. As Melvin Conway proves in the quote above, there is anyway no way of getting rid of them.
Spotify uses a similar approach with nested design systems, which you can find out in this talk of Shaun Bent.
Goal
The last big topic, that is rarely talked about, is the goal of a design system. It only became clear to me through Donella Meadows’ definition of systems. It showed me the weight that the goal has for a system. In this article, I mention this point at the end but actually it has to be defined at first.
“When you have a well curated set of principles, you can make design and development decisions, which are aligned.”
– Farai Madzima
Mostly people say that the benefit of a design system is “consistency”. That’s also what we thought in the beginning. I am no longer sure if this is just a phrase, as I have not observed that a design system ends up being measured or checked by it. If you want to achieve the goal “consistency”, this means additional work for the product teams. This additional work is only legitimate if it contributes to the overall goal that everyone has agreed upon. Product Owners only will share their resources if they have to. Therefore, this additional work must be planned in advance. If you do not define a goal for the design system, the design system will simply run in any direction that cannot be controlled in the end.
In all the resources I have consumed, I have only heard of five design system goals:
- Vox Media: Tell better stories, faster.
- Deliveroo: Speed of design and development
- Auth0: Consistency (short term goal),
Quality + Productivity (long therm goal) - Farfetch: Build higher quality products more efficiently
Design seed 🌱
The design part of your design system has also to serve an overall goal. It has to be based on something. Don’t just start designing components. If you do so, you will reach a point where you can’t make decisions anymore. Because what is the basis for your design decisions? In the beginning, decisions can be made on the base of taste. In a project with more and more people involved, that doesn’t work for long. You need a design seed that you can always fall back on. As soon as this design seed exists, other people can also fall back on it and you enable people to evolve the system on the same base (→“transparency”).
We offered the first version of our design system without any goal or design seed (which was later defined as “contrast”). That made it for some people really hard to understand and reproduce the underlying concept of the design taste without this guideline.
A design seed also contributes to the concept of “big levers”. And these are after all the valuable rules that we urgently need to support the users in the right combination of components.
Conclusion
Donella Meadows was right. It’s not the elements, but the interrelationships that can change a system. But of course, it’s not just about changing a system, it’s also about respecting the user with making it understandable and usable. To truly invite the user is important because the user applies the system and only an applied system is a living system. That is exactly why our focus should expand from the elements to the interrelationships of a system. I am curious how we can explore the field of “how to combine predefined components in the sense of the design system” further.
If you want to learn more in detail about these topics, you can take a look at my playbook on design systems at www.how-to-design-system.com or say hi. This article is personal and does not necessarily represent SinnerSchrader’s positions, strategies or opinions.
