I think it's time designers start owning their design in code, which is to say, owning the experience in production. I'm not saying it because I want designers to do more than what they already do, but because the end user doesn't get to use their designs as-is. What users feel and interact with is the implementation of their design, which is not entirely in their control - deadlines, speed, lack of focus on details - often ends up compromising exactly what is needed for design to feel good. Users never see the Figma file. They feel the implementation.
As part of my consulting engagement with Womp, I own the design layer in production. Womp is a startup without a dedicated design engineer. I sit across design, product, and code, so I took responsibility for the design layer in production. UI work does not sit in a frontend queue. The team can change the interface quickly and keep it consistent across releases.
I created KookieUI to fit the way the product gets built. The frontend imports components like Button from KookieUI, while I define their appearance, tokens, and behavior. When anything needs an update, I adjust KookieUI and publish a new version. The frontend team then updates the package, and the app adopts the new standard automatically.
KookieUI is the design system I built for Womp. It is large and growing. It lives next to product code and stays separate from application logic. It holds tokens, primitives, and patterns the team uses every day. It also carries best practices, accessible components, and the small engineering choices that make interactions feel clean.
KookieUI is a fork of Radix UI and it is open source. Radix gives a strong baseline. I add what the product needs. The focus is on contrast, focus states, motion, density, theming hooks, keyboard paths, and predictable behavior across states.
I started by strengthening primitives like buttons, inputs, dialogs, menus, tooltips. Reliable building blocks let the team move faster everywhere else. Now I want to invest in pattern components that carry real but less glamorous work:
Patterns reduce decision load and make changes flow through the product. They also let the team run smaller experiments because the base holds steady.
If you ask someone uninterested in design to handle design, the result is not ideal. Do not do it. The person shaping the experience should also shape the code that delivers it.
Traditional handoffs solve the same problem twice. Design in Figma, cover edge cases, pass to engineering, cover code edge cases, ship, feedback, loop. When the design layer lives in code, you solve it once where the user feels it. You still review. You still test. The work sits in the right place.
The ideal is to add new UI patterns to KookieUI first, then use them in the app. Reality is simpler. Whoever is unblocked does it. If I am deep in product work, the feature team can build the UI inside the application layer to keep moving. Later, that work gets pulled up into KookieUI as a pattern, given proper contracts, tests and docs, and the local version gets replaced. This keeps velocity high while still growing the system.
When shipping fast, teams often skip the details that lift an experience from a nine to a ten. Now that work happens inside KookieUI, in isolation, while engineering focuses on application logic. Both tracks move.
Intent is written down in the docs next to the code. APIs stay clear and narrow. One-off styling in features is avoided. Keyboard paths and focus rules stay visible. Examples match real screens, not toy cases. When a component grows too many concerns, it gets split. When a token change is risky, it gets staged and rolled in steps.
If you can teach designers to use code, do it. If that is not possible yet, at least separate the design layer from the application layer.
Building quality components is an orthogonal task to building features. Teams rarely estimate time for it in a feature sprint, so it gets missed. Shipping a well engineered component is not easy and it should not compete with a feature deadline.
Start with a primitive or headless library. If your design team is advanced, or you have UI engineers, build a separate component layer and treat it as your design system. Keep it in the repo. Give it owners. Pull patterns up from features when you have breathing room.
Design that feels good is design that survives the trip to production. Owning the design layer in code gives it that chance. KookieUI is how I do this for Womp. It helps the team move faster and gives time to raise the quality where people notice it.
