DESIGN SYSTEM | UI DESIGN
Design system case study
Designing a scalable Design System in Figma for a Bootstrap-based white products

01. Project overview
Creating a design system that works well is already an accomplishment. But creating one for a white-label product that needs to support multiple brands, share a single codebase, and remain 100% WCAG 2.1 level AA compliant at all times is where it really starts to get interesting.
With the product constantly evolving and new features being added along the way, every design decision has to scale across brands, fit within an existing Bootstrap-based framework, and make sense to both designers and developers. Without a solid system in place, things fall apart quickly: inconsistencies creep in, accessibility becomes fragile, and collaboration slows down.

02. The Core Problem
The brands I work with vary a lot. Some use highly saturated, vibrant colours, while others rely almost entirely on soft, pastel palettes. Translating both extremes into a single system without breaking WCAG 2.1 level AA accessibility is a real challenge.
At the same time, the system needs to be future-proof. New brands must be easy to add without redesigning components or introducing exceptions. Every brand has to live inside the same token library and safeguard brand expression, without compromising consistency, accessibility, or scalability.

03. Constraints & Non-Negotiables
This design system is built specifically for a white-label product. That means the visual appearance of components needs to change per brand without changing the underlying structure. I achieve this by aligning my Figma tokens directly with the Bootstrap framework.
By focusing on getting the foundations right, I remove the need to second-guess design decisions later on. Token combinations are intentionally limited and always known to be 100% WCAG 2.1 level AA compliant, which allows me to design quickly and confidently without introducing accessibility risks.

04. System Governance
I use Bootstrap as the system of governance because it is the framework used by the development team. Aligning the design system to the same framework creates a shared vocabulary, which makes collaboration clearer and more efficient from the start.
Once the requirements for a new feature are defined, designing becomes faster because I can work in an object-oriented way, composing screens from components that already exist. For developers, this means less time spent building custom components and more time assembling features from a familiar, consistent set of building blocks.

05. Design Approach
All components are created with properties by default, allowing prototypes to behave as realistically as possible. This makes it easier to present and validate ideas with stakeholders, test interactions early, and align expectations before designs move into development.
By aligning colours with Bootstrap’s semantic colour roles and tonal scales, I avoid creating extra colours for different component states. Instead of relying on opacity, I use solid tints to maintain clarity, contrast, and predictability across different backgrounds and layers. This ensures that the colour seen on screen is always a true colour.
Using semantic colour names such as primary, secondary, and warning also prevents the system from being tied to literal colour labels like “green” or “pink,” which may not align with a brand’s palette. This keeps the system flexible, scalable, and brand-agnostic.

06. Validation
To validate the design system, I designed a wide range of screens and layouts across different brands, use cases, and complexity levels. This allows me to stress-test the system, rather than validating components in isolation.
By repeatedly applying the same tokens and components, I check for consistency, accessibility, and edge cases across light and dark mode. This process helps confirm that design decisions hold up in real product scenarios, that brand expression remains intact, and that the system does not allow inaccessible or inconsistent combinations.

07. Documentation
Once I am confident in how each brand is represented and how components scale across pages, I document the design system to future-proof it and make it usable by the wider team. Clear documentation ensures that both designers and developers understand not just what the system is, but how to use it correctly.
Guidelines for adding new brands are carefully documented, including recommendations for colour scaling, light and dark mode usage, and accessibility considerations. This helps maintain consistency and brand expression over time, even as the system continues to grow.

08. Usage & Impact
The design system is actively used across three brands, with two additional brands currently in development. Because the system is token-driven and framework-aligned, new brands can be introduced without redesigning components or increasing complexity.
Design and development workflows are faster and more predictable, with fewer handoff issues and less need for custom solutions. Accessibility remains consistent across brands by default, and design decisions scale confidently as the product continues to evolve. The system now acts as a stable foundation that supports growth, collaboration, and ongoing feature development.
