As we plan our e-commerce digital transformation, it's crucial to find a scalable solution that enhances design and development efficiency. Our focus was how to implement Design System for multiple e-commerce sites to ensure the scalability and consistency.
At Munro, our small design and development team supports over 10 brands, each with its own e-commerce site. While it’s a testament to our growth, managing and scaling these platforms is becoming increasingly complex and challenging for the future.
Design System is Needed
During our digital transformation, I saw our small team and tight budget would delay market delivery. To solve this, I proposed a multi-brand design system for long-term efficiency and consistency.
How can we create a simple, flexible, and scalable multi-brand design system that serves both designers and developers?
Research & Design
I always love creating things that genuinely make people's lives easier. After multiple rounds of discussion with the team, we finally agreed on the solution of creating a design system.
Far From Reality
I quickly started exploring top design systems from leading companies on Designsystemrepo.com, such as Base Web from Uber, Polaris from Shopify, and Material from Google. It turned out that these design systems were incredibly comprehensive. We wanted ours to be just as thorough, but without a dedicated team, it would take us forever to achieve that level of completeness.
Back to reality
We needed to start small and align with our ongoing projects. Brad Frost’s Atomic Design methodology gave us the best solution with our current situation.
Start From Small
The design system started very small, with only a few button and input components. As other projects progressed, the design system grew alongside them. However, I still try to reuse existing components as much as possible when building new ones to make maintenance easier.
When structuring the Figma page, I list out all potential components and create separate pages for them to reduce loading time.
For each component, I include all relevant information—such as size, state, and Storybook link—along with the required CSS tokens and CSS code for each states, making it easier for developers to reference.
Flexibility & Scalability
Creating a component shouldn’t be difficult, but we need to consider various current and future use cases. In addition to reviewing existing functionality, I also collaborated with marketing and QA teams to identify potential near-future use cases for each component.
Component Pressure Test
After discussing with the QA team, I realized that some extreme cases might not actually be edge cases. We may need solutions for each extreme case we can anticipate.
The easiest solution is to ask marketing content creators to limit their character count. However, we can't expect them to always follow our suggestions. So, we came up with potential solutions just in case.
Design Tokens
We want to make the design system easy to scale and capable of serving multiple brands. Initially, we considered creating individual components for each brand, but this would be time-consuming and difficult to maintain with our small team.
After discussing with our front-end lead, we thought exploring design tokens could be a great way to make our design system more robust.
we've created the token structure which potentially easier for developers using the tokens for multiple brand.
We've all the token names are the same regardless different brand, as the devs would have each component token css file for each brand, but all tokens are coming from global token.
Global Token - Colour
Component Token - Colours
Component Token - Spacing
Figma Variables - The challenges
We want to keep our Figma files minimal for easier maintenance. The original plan was to have 1 Brand Styleguide file linked to the Design System, but since the professional plan only allows 4 modes and we can’t upgrade to enterprise.
Work Around
Due to the 4-mode limit per Figma file, I split the tokens across multiple files using the same token name, all linked to the Styleguide. This workaround lets our design system support up to 16 brands while keeping a single source of truth for components.
Device variables for better convenience when designing for multiple platforms.
Brand variables make it easier for designers to create functionality for multiple brands.
Making our figma as consistent as possible with storybook will significantly reduce design and development time when the business launches a new brand or when the marketing department updates brand styles.
Documentation
We didn’t focus much on documentation due to limited resources for the design system. But, I still created a basic reference guide, which could help new design staff onboard more easily.
The documentation structure includes several sections: component overview, anatomy, properties, examples, and do’s and don’ts.
Outcome
With our Shoniverse Design System, our design and development time has been reduced by almost half. We can now bring products to market faster, even with tight timeframes and limited resources, while also minimizing back-and-forth during QA.
End of Case Study but no for the Design System
A design system is a living, breathing product that requires constant maintenance and care. There is still a lot of room for improvement in the Shoniverse design system, and some areas may be too complex for a small team. I’ve learned a lot from this design, which will contribute to my future work on design systems.
