Design System

When I started building this design system, Kimberly-Clark didn’t really have one. Every product looked and behaved differently. Fonts changed from page to page. Buttons meant different things in different tools. Developers defaulted to whatever framework was easiest—often Bootstrap—with no real design guidance. Even within the same product, consistency was rare.

I set out to change that by building a company-wide enterprise design system—single-handedly—that standardized the user experience across all of Kimberly-Clark’s digital products.

The problem

There was virtually no shared design language. Each team made decisions in isolation. Products spanned wildly different tech stacks—React, Angular, legacy systems—which made alignment even harder. There was no governance, no shared components, and no clear standard.

Our UX team was excited about the idea of a system. Development teams were more skeptical. Many had ingrained habits and varying levels of technical maturity. Convincing them to change how they built things was just as big a challenge as designing the system itself.

The approach

I built the system from the ground up using atomic design principles. It included foundational styles, core UI components, and full application and website modules.

On the code side, I built the system on top of ShadCN components and Tailwind utility classes. Tokens and variables were named to match familiar Tailwind conventions so developers didn’t have to relearn everything from scratch.

In Figma, I created a full component library using variables and modes, synced to the same tokens used in code. Designers could switch brands, themes, and modes without rebuilding components.

I also built the documentation, usage guidelines, and example patterns so people didn’t just have components—they knew how to use them.

Adoption and governance

A system only works if people use it. I hosted weekly working sessions to walk designers and developers through the system. I standardized parts of the tech stack across teams so the system could be adopted without friction.

Every new component or change went through a governance process that I managed directly. This ensured quality, consistency, and long-term maintainability.

Support wasn’t just docs—it was demos, open office hours, and direct help when teams were implementing something tricky.

The result

The design system became the foundation for enterprise UI at Kimberly-Clark. What used to be a scattered landscape of mismatched interfaces became a cohesive ecosystem.

While it’s hard to reduce the impact to a single number, the difference was dramatic. Teams shipped faster. Designs were more consistent. Developers spent less time reinventing patterns. Products felt like they belonged to the same family.

Most importantly, it raised the bar for everyone. Designers and developers now share a common language, a common toolkit, and a shared standard for quality.

This project showed me that a design system isn’t just a library of components—it’s a cultural shift. And when it works, it changes how an entire organization builds software.