I was using Radix Themes every day, and it did a lot of things right. It gave me components that were accessible out of the box, strong defaults, and a toolkit that let me move fast. The components worked reliably, the API felt intuitive, and I could trust that what I built would function for users. As I used it for real products, I found myself needing different choices: different patterns, different design decisions, and different opinions about how a design system should work.
KookieUI began as a fork of Radix Themes. I took the infrastructure they built and changed what sits on top of it. The underlying system remained, but I made considerable changes to the design layer: the tokens, the patterns, the opinions about spacing, sizing, theming, and component behavior. It's about taking something that works well and reshaping it to match how I think design systems should function.
Radix Themes is a complete design system with its own opinions. Where I differed was in those opinions.
When I started using it for real applications, I noticed places where I wanted different choices:
Variants needed unification. A "surface" card looked different from a "surface" button. The shadows meant different things across components. The visual language needed consistency. Some components had "classic" variants, others had different options. The system needed clear rules for when to use what.
Theming needed extension. Radix had a panelBackground token for cards and tables. Dialogs, popovers, and dropdowns needed their own theming approach. The system needed per-component control so every surface could match the theme intentionally.
Sizing needed alignment. Each component had its own scale: cards went up to 5, buttons to 4, dropdowns to 3, selects to 2, avatars to 12. A size-1 button inside a size-1 card needed to feel related. The proportions needed to be systematic across all components.
Motion needed consistency. Some transitions, like segmented controls, felt smooth and polished. Others, like tabs, snapped instantly with no easing. The system needed a consistent motion language.
Accessibility needed enforcement. The core accessibility was excellent. Screen readers worked, keyboard navigation was solid. Icon buttons needed enforced aria-labels. Tooltips needed to be native. Icons needed consistent sizing across components.
Radix Themes delivered a complete system with its own choices. KookieUI is my version of those choices, built on the same infrastructure but shaped differently.
KookieUI is a fork of Radix Themes with different design opinions. The infrastructure stays the same. What changed is the design layer.
Patterns before parts. I start with spacing, radius, shadow, color, typography, and motion. These rules apply everywhere, and components inherit them consistently. When you use a size-2 button, it uses the same spacing scale as a size-2 card. When you apply a "surface" variant, it means the same thing across every component.
Material system for backgrounds. I replaced panelBackground with material, a system that defines how components render against whatever background they sit on. Material is more flexible and works across more use cases.
Unified tokens. Sizes, radii, typography weights, and color scales all match across components. Every scale is systematic and intentional. If you see a size-3 anywhere in the system, it means the same thing everywhere. This consistency makes the system predictable and learnable.
Accessibility enforced. Icon buttons require labels, enforced at the component level. Tooltips are native and built in. Screen reader and keyboard support from Radix are extended with the details that matter in day-to-day use. The accessibility is built in and enforced by the API.
Extended patterns and components. I added toggle buttons, toggle icon buttons, more typography weights, and layout primitives like shell, split view, and sidebars. Even new patterns like AI chat interfaces fit inside the same rules. The goal is to fill gaps where teams need patterns beyond what Radix Themes provided.
KookieUI makes components behave consistently, as if they were designed together as a coherent system.
KookieUI started as my personal project. As I worked on it, I realized I could use it for Womp to solve real problems.
The migration is ongoing. Some areas of the product run on KookieUI, others are still being migrated. Even in this partial state, the benefits are clear.
Here's what changes when you have a system like this:
Speed. Engineers get design details from the system. Update the dependency, and the new design flows in automatically. Consistency conversations are eliminated. The system handles design coherence, so engineers focus on functionality.
Principles in code. Spacing and motion rules live in the system itself as defaults. When someone uses a component, they get the right spacing automatically. When they need to override it, the system guides them toward the right choices.
Direct contribution. I push design changes directly into KookieUI code, which means the team can move faster while maintaining polish. A design improvement I make on Monday can be in production by Tuesday, with full engineering implementation included.
Clear ownership. Through KookieUI, design controls the design layer. If something looks wrong, the system needs to encode it. That responsibility belongs to me as the consulting design lead. Engineers implement design from the system. This creates clarity.
The migration is uneven. Some areas look and feel more coherent than others. The trend is clear: KookieUI gives design a way to lead through code.
KookieUI continues to evolve. I'm still figuring out:
How to extend the system with new patterns while maintaining flexibility. Every new component I add has to fit the existing rules, but sometimes the rules need to evolve. Balancing consistency and flexibility is constant work.
How to refine motion and interaction so every component feels equally polished. Some components have smooth, thoughtful transitions. Others still feel a bit mechanical. Getting the motion language right across the entire system is harder than I expected.
How to keep the system flexible enough to evolve while remaining dependable. Teams need components that work predictably. They also need a system that can grow with their needs.
Some days it feels like too much structure. Other days there are still gaps. That tension is part of building a design system.
Radix Themes gave me a solid foundation. KookieUI is my fork with different opinions built on that foundation.
It's about noticing where I wanted different choices, and then implementing them. It's about codifying rules so design intent stays intact through implementation. It's about giving the design team a way to own how design shows up in the product through code. KookieUI remains open source because Radix Themes is open source.
KookieUI is early and uneven. Some parts feel mature and stable, others are experimental. Step by step, it's making Womp faster, more consistent, and more deliberate. The team moves quicker because design decisions are encoded and consistency is enforced. I can iterate on design directly in code.
That's enough reason for me to keep building.
