Complex design system challenges
Many large enterprises and companies struggle to maintain a cohesive system of products that have different needs while maintaining visual consistency and scalability. This leads to inconsistencies across products, extra work creating custom solutions, and siloed approaches to similar problems.
I worked with two very different companies—an online education company and a government contractor with solutions for the military. Despite their differences, both organizations had many sub-brands and products that relied on separate code bases, components, and custom solutions. This fragmentation made it difficult to scale design changes, ensure accessibility, and maintain visual coherence across brands.
Impact
Example problem spaces
Company 1: Enterprise with online colleges and learning platforms with similar experiences
- Separate teams per product, separate design systems, code bases and similar challenges
- Different experiences based on the learner's step of the journey, the prospective students receives a different experience than the current student creating misalignment and disconnected experience for user
- Components are customized with different features and not shared across teams
- Sees a need for a company-wide design system but the effort is too large to get buy-in and create too many standards
Company 2: Complex products for the military with customization and different problems
- Some shared code bases across products but very different products, different look and feel, no brand connection
- No clear brand guides per product
- Most users only use one product for the branch of the military that they work in
- Separate design teams and little sharing of components
- Umbrella company had no design or branding standards
- In the process of creating a company-wide design system but fails to address unique needs of each of product
The total design system
Evolving Legacy Systems for Multi-Brand Needs
While the idea of visual pattern systems is ancient, modern design systems that bridge design and development—like Google’s Material Design, introduced in 2014—are still relatively new. As a result, many large companies are only now beginning to adopt more advanced practices, such as design tokens and theming, to manage complexity across multiple brands.
For most, starting from scratch isn’t an option. These organizations already have mature products built on legacy frameworks, making a full overhaul costly and time-consuming. Fortunately, tools like Figma, Storybook, Supernova, Tokens Studio, and React help bridge the gap—automating much of the work and enabling companies to implement scalable, modern systems without starting over.
Reconciling brand guides, style guides, and design systems
While many UX schools of thought may not stress the importance of a brand guide, I believe that in an ideal situation a brand guide and a design system are one. Design systems are usually extensions of a brand guide for web/digital, however, working the needs of brand into a total, universal design system creates cohesion and alignment across previously siloed entities. This ensures accessibility and flexibility for colors, scalable typography systems, and guidelines for any medium in which the brand is shown.
For color palettes, accounting for interactive states using tints and shades, dark mode colors, and testing out accessibility on screens during the creation of the "total design system" is a streamlined approach to not run into challenges with the core brand colors later on. For companies which already have established brand guides and/or design systems, it's still possible to reconcile UX needs and brand needs by aligning to improve the original palette. Using a new color system, OKLCH, it's easier to create seamless and accessible palettes through adjusting L (lightness) C (chroma/saturation) and H (hue). It's both mathematically and perceptually standardized, meaning adjusting the same increments of any value will produce great looking colors, other than having to guess with hex codes. It also connects seamlessly with CSS, with automatic converters to transition from hex.
Similarly to color, typography chosen in a brand palette can have UX challenges with weight variability, line height, and letter spacing that are not considered. If the brand fonts selected are not open source, it creates issues for team members loading fonts and is usually costly. Selecting Google fonts for the brand palette upfront saves UX time later on.
A "total design system," (or Gesamkunstwerk for the fine art nerds out there) is especially important for multi-brand companies considering how their brands both fit together and are distinct, creating a truly harmonized ecosystem of brands and palettes.
Design tokens and theming
Speaking the same language across an organization
Just as there are challenges connecting brand to design system, many more challenges arise during developer handoff. However, with design tokens as the backbone of our "total design system," teams are aligned across and organization. Typically, design tokens are described as a shared language between designers and developers, but I'm going to extend that definition to mean across all parties, from designers, developers, marketing, brand, writers, product management, etc. If design tokens are created together with all parties in mind, it not only aligns decisions but allows for more flexibility and empowerment as other team members can take ownership through utilizing this standardized system.
What is a design token?
A design token is essentially a name for any singular value, whether that be a color, measurement, font family, etc. These names are semantic, as in they describe that value's purpose. For instance, this blue is used as the primary button color, so instead of just calling it "cerulean-blue" it has another name: "button-color-primary."
In this way, design tokens not only present design decisions, they allow for scalability. If a team wanted to change the primary button color, instead of having to create a new value for the new color "sky-blue," then change it in every instance a button is being used, they only have to update the "button-color-primary" to the new color, and it will automatically update everywhere. (Note: this is a simplified example, in the next section I will describe the structure of tokens that allows for using tokens with components and across different brands)
Design token structure
Below is an example of color tokens for a primary color which is being used as the button color for an enterprise company which has 5 products and sub-brands, Axis, Kivo, Vero, Luma, and Zylo, which all have different palettes. We use three different levels of tokens, the primitive, semantic, and component. The semantic references the primitive token, the component references the semantic. So if the primitive token was changed, the changes would cascade up to the component level token.
- Primitive tokens are associated with the base values and have names which merely describe the color value, unit (like base-unit)
- Semantic tokens are where the meaning or purpose of the token comes in, so for this example, we would use pink-rose-500 as Axis' primary background color
- Component tokens define how the semantic token is used within a component, which is the highest level of specificity. So we'd take from axis' primary background color to use as our primary button color
Using theming, which connects from Figma variables and/or Tokens Studio to the CSS, we are able to preset all of these values, color, units of measurement, and typography styles and effortlessly switch the theme (brand) or mode (light mode or dark mode) in both design and code. See how easily it is to recreate designs for different products.
Enabling t-shaped talent
With access to AI, learning beyond your typical set of skills for your profession has become more prominent, and even expected from us, than ever. With Figma rolling out Figma Make (their AI) and Figma Sites, we can assume that being able to connect your design system and design tokens to AI won't be far in the future. This means that traditional roles, a PO, UX designer, graphic designer, developer, and anyone else on a team are blending together. Having a standardized system of design tokens can allow a PO to make a beautiful, well-thought out design, a developer to tweak a color to make it accessible, or a designer to code a documentation website, all without creating inconsistencies. The total design system is the future of tech.
Flexible, powerful components
Components built for adaptability
Designers: how many times have you had to detach a component in Figma?
Developers: how often does developed component have limitations that won't match the design?
Components should be built to allow for changes—to meet the current needs of users, to scale across different platforms and frameworks, and of course to be styled to match the product's brand. There are a few ways to approach this depending on working with needs of the product and what existing frameworks are present. Following a simplified approach to atomic design, components are built in the order of smallest, simplest components first, then fed into one another to create more complex components. Components should also always be tested for usability and by users to ensure they meet the users' needs.
One way to prevent detaching components and constantly having to make updates is to create components that are simple yet powerful are to use the variant properties in Figma, yet making sure to align this approach and use the same naming convention with development. Below, this button is laid on in different places a screen, which has a lot of variables for sizing, state, text, and icon usage.
AI brings the creativity back into a design system
Although design standards in a design system create a lot of consistency, sometimes they create too much rigidity, less creativity, and less ability to experiment. Experimentation should be at the core of good UX design to be able to discover what the user really needs to the most seamless, enjoyable, and helpful experience. Also, in order to stay up to date with UX trends, designers should be empowered to test new components. Through AI, designers are able to quickly iterate, animate interactions, and create live sites to test their experiments. The system then expands to accommodate those needs, rather than being to strict to add in. The concept of web components can also be a helpful way to implement new components within an older or legacy system as they are framework agnostic.
Helpful documentation for anyone
Never put documentation to the side! For a true total design system that can be used easily by anyone, helpful, user-friendly documentation is absolutely necessary. For a total design system, I recommend having distinctive documentation for the different types of users, whether that's for other designers, developers, POs, or anyone else on the product team.
Do you need a total design system?
In summary, the total design system is an approach I created to solve a recurring problem I saw across teams: inconsistent user experiences, duplicated design efforts, and scattered brand implementations. I've used this approach with both large companies and small businesses to create a shared system that connected brand and product, saved time, and scaled across platforms.
The system includes centralized token theming, flexible components, and accessibility-focused foundations—like OKLCH color palettes and scalable design tokens. It helped teams launch faster, maintain consistency, and collaborate more efficiently—saving over 1,000 hours a year in design and dev work.
If this sounds like something your company needs, I'd love to talk! Reach out to me here.