August 18, 2021newsletter
Today you’re in for a treat — we have this newsletter’s first ever guest post, written by Dmitry Belyaev. Dmitry is a front-end engineer with 10+ years of experience in design systems. He is a creator of arcade.design and is currently working at Booking.com, leading their design system and tooling development.
by Dmitry Belyaev
When we talk about design systems in the industry, there are a couple of topics we repeatedly discuss. We know we must define design tokens, build and structure components, and write documentation. We want our systems to be themable, to support dark mode, to be accessible, and to work with translations and support RTL.
The list of tasks a design systems team could complete feels endless. And even the most advanced, well-funded design systems teams in the area spend a lot of time researching the discipline and trying to figure out the best standards
What happens to the teams of one or two people trying to bootstrap a design system while also completing their product work? How can they prioritize which areas to focus in when building a design system? And how do design systems scale over time?
1-20 developers and designers
A small team with one product is the typical early setup for most startups. This team usually focuses on defining the foundations for the system. Their main goal is to improve the quality of the code and the design assets and increase the speed at which product designers and engineers can build new experiences.
There are some common patterns across design systems built by a small team to support a single product:
Define and implement design tokens and the most common components. Not all of the product’s UI should be a part of the system. Instead, try to frequently use these small pieces of the system in the product.
1-20 developers and designers
It changes a little when there are multiple products in development. This would usually mean there are multiple design files and multiple repositories that depend on the same design system assets. That’s where we start extracting your system into standalone libraries.
Storing a design system separately naturally helps to separate concerns. Because your company supports multiple products, you can’t be sure that all of the products are always using the latest version of the system. Therefore you start to spend additional time preparing releases and testing them only in an isolated environment before making them available for general use.
Depending on the team’s size, it’s a good idea to have 1-2 people responsible for the design system implementation, even if that’s not their full-time responsibility. That will help the team keep the components’ implementation detached from specific product features and avoid future system complexity.
Stable release process and quality testing. You likely can’t test the system changes in all projects before releasing them, so it’s even better if you automate at least some parts of this process.
20-50 designers and developers
Growing your product development and design team introduces a new challenge. The more you grow – the harder it is to get everyone in the same room and just share the updates or ask for a favor. This is where communication becomes crucial. You’re either building multiple projects or your project is big enough that it gets harder to be aware of all of the changes.
At this point, the design system team needs to become its own standalone entity. This is exactly the moment at which most of the companies start struggling with getting leadership buy-in. There are challenges on the table, there is a willingness to solve them and they have to be translated into business value to meet the budgeting requirements.
50+ designers and developers
Now’s when the real system scaling starts. As the number of product teams grows, the more a design system will look like an open-source project with its own community, even if everything you do is not public. This is where most of the larger scale companies are. At this stage, a design system starts to differ based on a company’s design and development culture.
At this stage, people expect that the design system already covers the priorities from the previous sections. If it doesn’t, the team will feel overwhelmed by the missing parts. Resolve them as soon as possible.
What differentiates a larger design system is how organized the processes should be in order to move forward. Most likely the team’s not changing the design or code of your components every day. If a component must be modified, it must be done in an incredibly stable and safe way.
Since the design system team operates as a service team at this stage, it needs longer-term planning. Product teams need to know when the next important release is coming and when the team plans to release a breaking change to which they will have to spend some time migrating.
Further scaling of the system is where most of the high-end design system teams are right now. There is no clear path to go from here and we all rely more on trying out new approaches and knowledge sharing. A lot of work turns into longer research and exploration of the principles that are yet to become standards in the future.
Let’s remember that all design systems started from the very first phase one day and it’s always a tough path to get to the last never-ending phase. Our UI development requirements have grown a lot in the past decade and it’s no longer a quick thing to create if you are truly aiming to build a product that your customers enjoy using.
If you like this newsletter it would really help me if you shared the link https://maecapozzi.com/newsletter/ with your friends. Tweet about it, post on LinkedIn, and share in slack channels. Building this community can lead all of us to more job opportunities, guest posts, and connections.
If you liked this post, please consider sharing it!
Sign up for the Design Systems Newsletter today!