What is a multi-brand application?
How can you create one system for over 18 different brands? This is the challenge we had to face for a project we participated in. Soon, we started calling it a multi-brand application. What exactly does that mean? In a perfect world, it’s a front-end system for all the brands but with different themes. So, that also means a consistent design. Did we manage to achieve that? Nearly. But, like one of our teammates used to say, perfection is not the key to success.
One design system for over 18 different shops with their own styles sounds like a dream come true for every client or maintainer, but it can cause quite a headache among developers. To create such a complex design system, you really have to change your mindset on developing components, starting at the HTML level. I’ll be honest with you. When I heard for the first time that I’ll be responsible for creating such a system, I was quite terrified, but also excited. We had to develop two smaller projects, a design system and working theme application, at the same time. Just like we all expected, this project brought us a lot of lessons learned that I’m glad to share with you today.
Atomic Design
Developer point of view:
Anna Musiał, Front-end Developer, Vue.js
There is no eCommerce without well-conceived design. That’s why we decided to take our chances with Brad Frost’s atomic design, also known as unicorn workflow, and I couldn’t agree more. It just makes designers’ and developers’ lives so much easier. A system like this is fully reusable. Designers need to have the bigger picture in mind when working on each component, and developers’ insights can be especially useful. In my opinion, constant cooperation with the UX team is extremely important for project success. That’s what I loved about our project. We had to dive deep into each component and talk it through to achieve each atom, molecule, and organism.
How about using a UI library instead?
Since the very beginning of the project, we could feel the incoming deadlines. That’s why we decided to go with the Storefront UI library as a project starter with Storybook stories as documentation. At the time, it was the best decision we could make. It was already atomic-based and allowed us to progress with development quicker. All we had to do was to customize already existing components with CSS variables. That worked just fine until, well, multi-branding came to the surface. New components for the incoming brands required a lot of tricks and crappy code to achieve our goals using just Storefront UI. We realized that we need full access to the components’ code and more complex documentation. So, we dropped the idea of using Storefront UI and focused on writing our own components from scratch with proper documentation.
Make documentation great again
Even though Storybook is a powerful tool with multiple add-ons, we knew that good documentation is something more than just playing around with components. We wanted to fire up each page automatically with a description of the properties. Of course, you can write it down manually, but let’s be honest. People tend to forget about updating documentation, especially when time is running out. VitePress, VuePress’s little brother, was a perfect solution. Why?
- It’s lightning fast.
- It uses Vue 3.
- It has a slimmer bundle size.
Descriptive and clean documentation was important not only for developers but mainly for CMS and API providers in the project because they created structures based on front-end components.
Theming with vue and CSS variables
Using Vue 3 was the best decision we could make. With Composition API and its amazing reactivity and availability of the states from any place in application development, it’s a piece of cake. No more Vuex and tricky logic. It’s so important to keep things simple in a multi-brand project. First, it is easier to maintain, Second, it has a low entry threshold for new developers working on the project.
Let’s talk about actual theming. We are creating smart components, which are elements that are reusable and highly customizable. How can you adjust the styles of each component in a simple and clean way? CSS variables are the answer. Besides creating theme files with global properties, we also had to ask ourselves the same questions when developing each component. What is changing for each brand? Fonts and colors? Paddings? Each property had its own CSS variable assigned that will be later overwritten for each brand with its own theme variables. Simple.
The sky, and technology, is the limit
Product Designer point of view:
Marcin Baran, Senior Product Designer, and Design Delivery Lead
Sometimes, as an eCommerce designer, you might wonder, “Can I just create a reusable template for eCommerce to speed up the design work?” What if there is a way to create something which is good enough that can be implemented across many different brands with similar products or for companies from the same market segment. For example, like in the fashion industry. I’ve had an opportunity to check if that’s possible with the recent project and let me tell you, the multi-brand design system is an answer b only to some extent.
Looking for the holy grail
The Divante Product Design Team along with the Design Team from the clients’ side has been working on a multi-brand design system since the beginning of 2020. We faced a complex challenge. How do we build a component library that supports different brand styles that are, sometimes, dramatically different?
The solution we came up with isn’t a holy grail of a multi-brand designed system, so it can be implemented everywhere and work well. We decided to create a centralized resource/library that will help any brand within the company to build its own design system. We talked about the 18 different fashion brands with various targeted audiences, marketing language, and look and feel. It means that the solution needs to be flexible and independent at the same time. We wanted to do it well to enable consistency and efficiency.
We decided to use Storefront UI (SFUI) as a perfect starting point between visuals and the back end, which we knew would be developed in Vue Storefront. SFUI was designed by our team, so we knew the product, and we knew that it’s a perfect bridge between the design and development team. What’s more, it was designed based on best practices for the fashion industry, which makes it a perfect match for us and for the client’s requirements.
So, basically, after creating a white-labeled design system template, every brand will have their framework of choice to keep everything consistent:
- Reuse components from the existing white-labeled library.
- Assemble new components from already-existing base components in the white-labeled library.
- Build custom components, and add them to the white-labeled library.
Thanks to this, we can keep consistency and flexibility for the brands to make solutions that aren’t limited by any technological or time constraints. Also, it speeds up the time to market for every new brand that will be released.
Discovery is a must
At this point, we had the idea and architecture surrounding how we wanted to proceed. It was a time to make some decisions that crucially accumulated along the way. We started our product vision/discovery phase. This was a significant point when our ideas and methodologies clashed with the real data from the client. We ran a few workshops to understand everything along with some test scenarios. We wanted to make sure that our plan wouldn’t fail after a few months. The most important thing about this phase is to sit at the same table with clients, developers, product owners, and managers to go through the many possible scenarios and questions. This is done to be sure that all the needs from the business, technology, and user experience are met. Some decisions are interdependent, so making them without feedback from every point of view would make them less efficient.
The end of the discovery phase was choosing the tools that we wanted to work with that would also speed up the process. The product team in this project was international with designers in Poland and the U.S., developers across the whole world, and managers in different time zones.
Crafting is all about right tools
We chose to work with Sketch and Abstract. This part is less about being a good UX designer and more about being the strategic architect of a system that allows for flexibility and extensibility. We knew Abstract was already a tested and proven tool to act as a perfect bridge for cooperation between designers and developers. Thanks to branches and other features it allowed us to continue working without worrying about different time zones. We introduced a strict naming convention for everything in the system and an extensive library of components to be reused across all the Sketch files. The most important point to being successful in a project like this is it’s naming conventions and system documentation.
That’s why we also chose Storybook and Zeroheight as a place for keeping the documentation. Storybook is an ideal place for developers to have a library available with a preview and also with all the instances of particular components. Zeroheight is a place for all the documentation on how to use the system.
As for now, we’re already after the implementation of one complete design system for one of the brands, and it’s about to be released in the following weeks. We’ve created a white-labeled design system and two other design systems for different brands.
What have we learned so far?
Spending much more time and effort at the earlier stage of the project to create a documented, structured design system will undoubtedly provide long-term payoffs. It’s the only way to sensibly maintain a consistent design language across many brands while keeping the flexibility and independence of each. The main advantages of this solution are:
– A faster release cycle.
Marcin Baran, Senior Product Designer, and Design Delivery Lead
– Improved communication between design and development teams.
– An organized way of developing the products and keeping systems up to date.
– An automated process for new rollouts.
Communication is key, especially on the designer-developer line. Design inconsistencies lead to technical debt. Implementation of functionalities without designer verification can cause an unnecessary waste of time. It’s a two-way street.
The second thing is to be precise. There’s no place for crappy code in projects like this. Write your code with the bigger picture in mind. Make it reusable and clean, and document your work. That’s the way to success.
Anna Musiał, Front-end Developer, Vue.js
Published March 5, 2021
