Why Designers Should Own the Experience in Production
design-systemsdesign-engineeringproductkookie-uiwomp
Why the design layer should live in code, how we do it with KookieUI at Womp, and what changes day to day.Loading article content...
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.
We are a startup. We do not have 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. We can change the interface quickly and keep it consistent across what we release.
I created KookieUI to fit our way of building. 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 our design system. It is large and growing. It lives next to product code and stays separate from application logic. It holds tokens, primitives, and patterns we use every day. It also carries our 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 us a strong baseline. We add what our products need. We focus on contrast, focus states, motion, density, theming hooks, keyboard paths, and predictable behavior across states.
We started by strengthening primitives like buttons, inputs, dialogs, menus, tooltips. Reliable building blocks let us 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 us 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, we solve it once where the user feels it. We still review. We 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, we pull that work up into KookieUI as a pattern, give it proper contracts, add tests and docs, and replace the local version. 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 we do that work inside KookieUI, in isolation, while engineering focuses on application logic. Both tracks move.
We write down intent in the docs next to the code. We keep APIs clear and narrow. We avoid one off styling in features. We keep keyboard paths and focus rules visible. We add examples that match real screens, not toy cases. When a component grows too many concerns, we split it. When a token change is risky, we stage it and roll 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 we do this at Womp. It helps us move faster and it gives us time to raise the quality where people notice it.