Insights
Design Systems as a Process
Close your eyes. What do you see when you hear the words Design Systems?
If a flock of components, guidelines, and UI elements is parading in front of your eyes right now, don’t worry, we see them too. Chances are high that you also see some names next to those components: perhaps Google, Airbnb, Atlassian, IBM, Shopify... It is because the conversation around the topic of Design Systems is mostly shaped by established product companies like these.
However, not all those who create digital products work for product companies. What about design agencies? You would hardly read about Design Systems at agencies. Nevertheless, a lot is happening there too.
Design Systems superpowers
A commonly agreed definition of a Design System is ‘a library of design patterns, rules, and UX guidelines that enables companies to ship and maintain consistent products at scale.’ When we look at it from this angle, we define Design Systems as a product, an outcome. The biggest value it brings to a company is to establish a single source of truth that everyone can point to while growing the product.
At Edenspiekermann, we don’t build and grow one product. We build many. Our projects are fast-paced, with varying lengths and team setups. Sometimes clients come to us with the challenge of setting up a Design System — we created one for the biggest hospital chain in Germany that fuels now over 300 websites and one for an electric sports car in California. More often, we are called to relaunch a product or build its very first version: we start creating a new design language and proceed all the way to defining its USP, positioning, and offering. In those projects, it means that we simply don’t have the resources and time to create a Design System too.
Or so we thought.
Solutions that become problems
In the first phases of a project, when we don’t have components to reuse nor an existing language to build upon, we have to invest a lot of time talking and aligning to ensure that all designs are created consistently. While essential, this part of team communication is often inefficient and very time-consuming — and time is our most guarded asset. We choose speed over documentation and end up being slowed down to compensate for that very lack of documentation.
We realized we needed a solution that would improve our communication to maintain speed without sacrificing design consistency. We needed a way to communicate our decisions more efficiently than calling yet another meeting.
Let’s step back for a second. What is a design system, really?
In its essence, a design system is a collection of codified decisions
In its essence, a design system is a collection of codified decisions. These most commonly manifest themselves as guidelines and reusable components — hence the monolithic pattern libraries we mentioned before — but they are not the only way to codify a decision. We stripped down design systems to their smallest part — Design tokens — and rethought our thinking starting from them. We started looking at design systems as the process, not the outcome. And magic happened.
From options to decisions with design tokens
Design tokens embody a design decision that a team can swiftly establish and reuse. Simply put, they are the evolution of generic styles (H1, red-500, blue-300) into decisions (Page headline, error, primary action). Styles provide team members with options to choose from, Tokens offer guidance on how to use such options.
Tokens fill the sweet spot between investing in a lot of communication (no system at all) and creating a lot of documentation (a comprehensive component library). They enable designers to work simultaneously and build on top of each other’s decisions in real-time, resulting in a lesser need for alignment and greater consistency.
The key is to make tokens part of the design process, rather than an outcome of its own:
- First, we define a visual language, therefore a set of primitives that will constitute our options (colors, typography, spacing system, etc.)
- We explore different design solutions until we identify the best fitting one (at this stage, styles and tokens are not important. We focus on functionalities and interaction patterns.)
- If tokens haven’t already been determined for the use case, we ‘extract’ new ones from our defined solution. If they have been specified, we apply the existing ones (e.g., if I’m designing a link and a color for primary actions is available as a token already, I will use it too.)
- We document our decisions to make sure changes are available and accessible to everyone on the team — designers and developers. For this purpose, we create a Design System overview page/file to keep track of our growing system.
- Once the proposed solution has been approved by the team and the client, we create the specs and hand them over to the developers.
Naturally, as the project grows, fewer new tokens will be created, and more often designers will reuse previously defined ones, making it fast and efficient to ship consistent designs.
Good things come in threes
All in all, what are the benefits of using Design Systems as a process? We see three main advantages.
Designers won’t need telepathic superpowers
When two designers are asked to explore a new design, having been given a handful of colors and typefaces, only superhuman powers would allow them to create consistent outcomes without talking to one another. Well, design tokens give you that superpower as they enable all team members to be updated in real-time, without much need of talking. Moreover, when new team members join the project, it is easier to onboard them as the design explains itself.
Designers and developers speak the same language
If optimizing the communication between designers wasn’t enough, tokens also empower them to collaborate with developers. Tokens are defined by designers first, but they’re ultimately applied by developers. Each token is represented 1:1 in code, making it possible for the whole team to share a vocabulary and a mutual understanding. Tokens lower the barrier of complexity for designers that are not familiar with code and bring developers into the design-choices conversation early on — two birds with a stone.
Ultimately, you’re planting the seed for a bigger system
Anyone who experiences the pain of cleaning up a design file to find a system where it was never planned for, wishes that someone would have thought of it from the start. With tokens, a system is accounted for just by default. This means that whenever the team (or the client) decides to evolve the Design System into a product too, it will be much simpler to accomplish as the design is already neatly documented and allowed fewer exceptions. In other words, by using design tokens, you’re doing a favor to your future self. And it’s a big one.
To ken, or not To ken, that is the Question
Even after having experienced the perks of such a systematic approach, the question ‘should we use Tokens in this project?’ always gets asked. As often, the answer is, ‘it depends.’ The team constellation, the expected lifecycle of the product, its complexity, and the client’s design maturity are all factors that have to be evaluated before kicking off a new project. Rather than asking if we should use tokens or not, we should ask how we could use them. There are many complexity and specificity levels we can decide on to find the right ‘scale’ of Design Systems for each project. Every project is different and requires thoughtful decisions. Nevertheless, setting standards and best practices for working more orderly and efficiently can never be overestimated.
How to get going with tokens and Design Systems
- Start small and talk about it
At Edenspiekermann, Design Systems and tokens are an ongoing conversation. We continuously iterate on the approach and make sure we reflect together on our learnings. Through these conversations — which are woven into our rituals and exchange formats — we improve and create a shared knowledge base throughout the organization.
- Create and share templates
Templates are the antidote for Blank Page Syndrome. We’ve created a series of them to help our teams get started faster and with more confidence. Our starter kit is public on Figma Community. Take a look and start exploring design tokens too!
- Open up to the community
Sharing learnings inside our organization is important. Sharing them with the whole community is essential. We had the chance to discuss our experience at Figma’s virtual conference Config Europe. In doing so, not only we collected insights and feedback from fresh new perspectives, but we also took the opportunity to look at our approach with a critical eye.
Learning how to use Design Systems as a process is a process of its own. It won’t happen overnight, and it will require a lot of commitment and patience. However, once it clicks, it pays back. Tokens build a bridge between design and development and help teams create better products faster, making space for those cool features that inevitably slip to the bottom of the backlog. It’s worth the try — you can take our word on this.