Challenges of multi-brand design systems

Your management needs to know about complexity, limitations, and time before you start

Infographic of dependencies of mulitple brands in our multi-brand design system project.

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.

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?

Infographic: Blueprint button styled via tokens and adapted to multiple brands
Button styled via tokens in our multi-brand design system

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.

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.

Infographic that shows the dependencies of brands in a Multibrand Design System
Simplified map of dependencies of our brands

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.

color palette in the multi-brand design system compared to two initial brands
The color palette in our system compared to current brand colors

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.

Complex b2e table component compared to simple b2c table component
Complex table component for b2e compared to simple one in b2c.

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.

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.

Infographic: Simplified structure based on “atomic design” concept by Brad Frost
Our simplified structure based on “atomic design” concept by Brad Frost

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.

Two product cards of two brands next to each other.
Generic product card for two individual brands

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.

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.

Tag Cloud of first tasks in the design system set up
Some of our first tasks

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.

Infographic: Comparing small expectation against huge estimation

“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.

Infographic: Steps in Design System: Onboarding, Ramp up phase, Branding & Tokens, Components & Documentation
Phases in the project

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.

Timeline and roadmap of a Multibrand Design System
Roadmap of the first month in the multi-brand design system project

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.

Infographic: Time spent on mulit-brand components compared to mono-brand
Time spent on components: multi-brand components take 2–3 times the 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.

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.

Infographic: Time saved when initial brand set up is compared to a newly added brand
We saved up to 80–90% of the time on 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.

Multi-brand design systems can be great.

When done and planned right and with the right expectations.

  1. Complexity: Look at the maximum amount of requirements in the beginning and account for all cases in setup.
  2. Limitations: Understand that multi-brand has limits regarding reusable patterns inside the design system.
  3. 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.

Read the full article here

Leave a Reply

Your email address will not be published.

JavaScript APIs You Don’t Know About

JavaScript APIs You Don’t Know About

Table of Contents Hide Page Visibility APIUse CasesHow To Use It?

Understanding learners on their journey of acquiring skills outside academics — UX Research case…

Understanding learners on their journey of acquiring skills outside academics — UX Research case…

Table of Contents Hide UX Research Case StudyIn this article, I’ll walk you

You May Also Like