Streamlining Style Guides Across Multi-Brand Websites (2024)

We analyzed several existing style guides using reputable online resources to gather insights and best practices. The goal was to benchmark our approach against industry standards and identify opportunities for improvement.

Examples of Style Guides Reviewed:

• Material Design Guidelines (Google) – https://m3.material.io

• Atlassian Design System – https://atlassian.design

• Shopify Polaris – https://polaris.shopify.com

• IBM Design Language – https://www.ibm.com/design/language

• Salesforce Lightning Design System – https://www.lightningdesignsystem.com

Design Team has collaborated closely with the Front-End Developers to refine and enhance the Style Guide. This effort has significantly reduced duplication of elements and eliminated redundant typography styles, button variants, and colour tokens.

Key Improvements:

1. Naming Convention
We established a simplified naming system to ensure clarity and consistency across all multi-brand websites.

2. Typography
We propose a curated set of font styles as the desired standard. However, manual refinement is still required to tailor the selection for each brand’s unique needs, as a one-size-fits-all solution isn’t feasible.

3. Buttons
Unused button styles have been removed, and only actively used variants are displayed in the guide for better clarity and maintainability.

4. Colour Swatches
Each brand now has an independent colour palette with unique hex values. No colours are shared across brands to preserve brand integrity.

5. Icons
To enhance consistency in iconography, we recommend adopting Material Design Icons. This library provides flexibility with three distinct icon styles and four variable font settings—fill, weight, grade, and optical size.

6. Additional Design Tokens
For smoother handovers and improved clarity, we’ve added sections for Shadows, Border Radius, and Opacity in the updated style guide.

To improve consistency and efficiency across our suite of multi-brand websites, the Design Team partnered with Front-End Developers to enhance and consolidate our existing Style Guides. Our goal was to eliminate redundant components and standardize the use of typography, buttons, and colour tokens—reducing design and development inefficiencies. The result was a more scalable, maintainable design system that supports both brand differentiation and technical alignment.

---

Approach and Collaboration

From the outset, we worked closely with developers to ensure our updates could be smoothly translated into production. TailwindCSS utility tokens served as our foundation, offering a practical, modular approach to building consistent UI components.

To ensure scalability across brands, we introduced a simplified and flexible naming convention. Core design elements—such as colours, typography, spacing, border radius, and shadows—were managed using Figma’s Local Variables, ensuring consistency across all files and components.

Typography Consolidation

Typography was among the most fragmented aspects of the system, with each brand using its own font styles—many of which were duplicates or slight variations of the same function.

We introduced a unified set of text styles based on Tailwind values (font size, weight, line height, and letter spacing). While this standardised system brought visual cohesion, we also allowed for thoughtful brand-specific adjustments.

All text styles—Titles, Subtitles, PreTitles, Paragraphs, Buttons, and Labels—now draw from the same core values to ensure a consistent reading experience across the product suite.

Colour Tokens and Swatches

Colour usage previously lacked structure, with many swatches duplicated and undocumented. To address this, we created distinct colour palettes for each brand, ensuring that hex values were unique and non-overlapping.

Each swatch in Figma now includes descriptions and usage guidelines to reduce ambiguity and prevent misuse. We also standardised opacity using Tailwind’s 5% increments, ensuring consistent transparency across all components.

Button Rationalisation

The button system had become bloated with unused styles, inconsistent naming, and redundant variants. After auditing button usage across products, we removed deprecated styles and redefined a clear hierarchy:

• Primary Buttons – For key actions (e.g., “Submit”, “Book Now”)

• Secondary/Outlined Buttons – For supporting actions (e.g., “Cancel”, “Learn More”)

• Tertiary Buttons – For minor or less prominent actions (e.g., “View Details”)

All variants were rebuilt using Tailwind tokens, ensuring consistency and simplifying implementation.

---

Iconography

We recommended adopting Material Design Icons for their broad library and flexible customization options. With three styles and four variable font settings (fill, weight, grade, optical size), they offered a scalable, unified icon system that could adapt to brand-specific aesthetics.

---

Additional Design Tokens

To further polish and standardise the UI, we introduced additional tokens aligned with Tailwind:

• Shadows – Applied to containers for depth and hierarchy

• Corner Radius – Standardised across elements for visual unity

• Opacity – Applied consistently in 5% steps for clarity and control

These refinements helped streamline the design-to-development handover and improve the overall visual coherence of the system.

---

Figma Variables and Tokenisation

A key advancement was the implementation of Figma’s Local Variables to manage design elements globally. By centralising colour, typography, spacing, and effects, we improved consistency, simplified updates, and accelerated development cycles.

This approach also helped bridge the gap between design and code, allowing for clearer communication and faster handoffs.

---

Outcome

By refining our Style Guides and aligning them with TailwindCSS tokens and engineering needs, we dramatically reduced redundancy and inconsistencies across brands.

The result is a scalable, developer-friendly design system that’s easier to maintain, faster to implement, and more intuitive for cross-functional teams. It lays a strong foundation for future enhancements and fosters a more collaborative design-engineering workflow.

Note:  Retrospect, some of the tokens we created were unnecessary—for example, labels and buttons didn’t need as many font size variations to match titles. We also included too many font weights, when a single default weight would have sufficed.

We were so focused on what they could create, they didn’t stop to consider whether we should.