Challenges of multi-brand design systems
Your management needs to know about complexity, limitations, and time before you start
Multi-brand design systems are a hot topic right now. And don’t get me wrong, they are great, but they come with some challenges. I want to share some honest insights on what you should discuss with your stakeholders before you dive into the madness.
Why a multi-brand design system?
Before we look at the challenges, let’s see why you might need it:
Develop once. Use for multiple brands.
Doesn’t that sound amazing? You develop a design system once, and you can reuse it for many other brands in your organization. The main aspects that speak for a multi-brand design system are, of course, efficiency and reusability.
Those two points don’t differ too much from a mono-brand design system. However, they can be scaled up quite quickly. Imagine your design team has created the perfect component, done all the research, tested accessibility, and the engineering team has coded the ideal component. Why should another team do the same work when they could copy it more or less?
Truly multi-brand?
There are several ways to set up a multi-brand design system. We chose to use a one-source-of-truth system. This means we have one code base adapted to our brands’ needs via tokens (If you are new to this: A beginner’s guide to Design Tokens).
Any brand variation that cannot be controlled via tokens or component variations does not belong in the design system. Teams can still build their own custom things; however, we have an agreement that this is a sporadic use case. I will probably write more about this in a separate article.
#1 Complexity in multi-brand design systems
Complexity reaches a new level when you have more than one brand to consider. You try to fit all the unique personalities into one structure. Therefore, you need to know at least what is going on in each brand and what they will need.
Dependencies of brands
Of our ten brands, we started with a medium-complex one, which had a high priority and was the first to be launched. One would say to now build the MVP version for that first brand and hit the ground running. Others, including me, would say to create the maximum amount of variations from the beginning if you don’t want to refactor everything every time you add a new brand. This, of course, requires that you look at all brands all the time.
A particular challenge for us was that the second brand was a b2e brand used for internal customer and product management. This brand needed more complex components, and the whole look and feel was much more condensed and information-heavy.
Complex brands set the rules.
If you want to build the mentioned truly multi-brand design system, you only want one structure that works for all your brands. This adds complexity to all brands in every single aspect of your system. Let’s look at a few examples.
Complexity in colors
We work with a quite generic color scale from 50 to 900–10 shades in total. On top of that, we’ve also implemented some pretty cool logic for accessibility. We used a tool called accessible palette from Eugene Fedorenko for this.
All brands running in our system must follow the same color logic for our token concepts to work further up the chain. However, this means that brands like brand A, which only had six shades, and brand B, which only had two, now get four or eight additional shades — and to be clear, they didn’t ask for this. They were pretty happy with the colors they had… This required some rounds of explanation.
Complexity in components
Another good example is a complex component like our table. For b2e, we needed a whole set of features like sorting and filtering, multiple text and icon slots, components within cells, and dynamic expanding cells. Everyone loves tables, right?
However, our b2c brands only need a simple table that can’t do much. So we were faced with deciding whether to give our b2c brands a spaceship, even though they only need a paper plane, or to separate the components after all.
We decided to offer the same table to all brands because we assume that some more functionality will be needed over time, and we don’t want to maintain two tables.
#2 Limitations in multi-brand design systems
Let’s take a look at the second challenge: limitations. It may seem trivial, but multi-brand design systems have some limitations compared to mono-brand.
I’m assuming that if you’ve dug this deep into an article about design systems, you’ve heard of the atomic design idea from Brad Frost. In short, it’s the concept of building more complex elements of a digital product with the smallest defined bits.
Like many other design systems teams, we got to a point where we would spend hours discussing what a molecule or an organism was, so we decided to simplify our structure. We separated into components and patterns.
Can you cover patterns?
People expected us to provide complex patterns like product cards in the design system. This was also a result of the way our project was planned. It is a white-label solution with reusable parts and journeys of the product.
Enable teams to create the patterns they need
Take a look at these product cards: A few things can be controlled via tokens, of course (e.g., border radius, typography, etc.). However, changing the order or showing and hiding things creates unique patterns. Even for a mono-brand, it is quite a challenge to cover complex patterns in a design system (and I think this is why most design system teams choose not to).
This component, in particular, is subject to constant change: Marketing offers, A/B testing, new products, etc. And keeping up with all the unique brand requirements would quickly become a nightmare.
#3 Time in multi-brand design systems
Now to the most fun part: time. Every design system team knows there is never enough time, especially at the beginning of a project when you have one million tasks on your to-do list.
The foundation and discovery phase is even more critical than in a mono-brand design system. If you build your house on a shaky foundation now, you ensure that sooner or later, everything will collapse.
Of course, that takes time. I’ll give you an overview of how long it took us to plan this multi-brand project. Mainly because you find so little about it, and I was looking for such input at the beginning.
“The design system is a blocker. I thought it should speed things up?”
Expectation management
Yes, we were quite a blocker at the beginning. The design system team was brought onto the project pretty late, and the design and development teams needed our components urgently. Expectations varied from 4 weeks to 24 months to “completion” — another topic is that a design system is never finished anyway.
When some stakeholders wanted to see results after two months, we discussed token naming conventions. And that’s just about right. Teams should be given enough time for the set-up phase, as it pays off in the end. We’ll get to that in a moment.
Timeline in our multi-brand design system
How much time do you actually need? Well, that certainly depends on your brands, your team’s skills, the overall structure, and your stakeholders. If all brands are willing to compromise for multi-brand, the whole thing can be pretty efficient. Of course, it multiplies if every variation is discussed for weeks and brands don’t want to or can’t fit in. This makes it even more critical to get everyone 100% on board.
Ramp up phase
We worked on strategy, technical proof of concepts, design infrastructure (moving from sketch to Figma), and the foundation. We did a comprehensive inventory and component audit to get an overview of all brands. This step is crucial to understand the full scope of the project.
Branding & tokens
We then defined the token structure and created the initial tokens for our first brand. Don’t worry; you’ll still be far from perfect at this point. That’s okay. I see teams get lost in this step. Just start with something that feels right at this point. You will definitely come back to your tokens — multiple times.
Components & Documentation
We defined some test components to learn about with the development team and then worked through the backlog. At this point, we were under a lot of pressure as teams were desperately waiting for our components.
This initially led to very superficial documentation, which we later revised. I would not recommend this way of working — but I see this is very often the case due to lack of time.
Time spent on multi-brand components
Let’s look at how long it takes in detail, using our work on components as an example. For our project, I can say that working on a multi-brand component takes about 2–3 times as long as working on a mono-brand component. Why is that? Because the complexity mentioned above and the amount of people involved can not be neglected. I cannot emphasize this fact enough.
Multi-brand components take much longer — for each component.
Those who rush here will pay the price in the end. I strongly advise communicating this early and clearly.
Pay-off time on multi-brand design systems
Why would you still decide on a multi-brand design system with all the challenges? Let’s get to management’s favorite chart — why we are doing all this. We can save a lot of time when adding a new brand.
From my experience on this project, it depends on the brand and the people involved.
Overall, you can say that we only need about 10–20% of the time for a new brand compared to the first brand.
So you can see that, ultimately, it’s a calculation. Of course, we should not forget that the maintenance cost is also reduced. A significant advantage of a multi-brand project is that such a project can’t be done by a single designer and developer besides their daily tasks and that there has to be a dedicated design system team — which is always a good idea for the health and quality of a service or product.
Conclusion
Multi-brand design systems can be great.
When done and planned right and with the right expectations.
- Complexity: Look at the maximum amount of requirements in the beginning and account for all cases in setup.
- Limitations: Understand that multi-brand has limits regarding reusable patterns inside the design system.
- Time: multi-brand saves a considerable amount of time when new brands are added. However, the time spent to get there is much higher than for a mono-brand.
This article was originally a talk in front of 200 design system friends at the Intodesignsystems meet-up in Munich.
