This week at the studio, I was working on two end-to-end projects: a client app for managing inventory in a warehouse and a generator for the studio’s backgrounds.
Initially, I jumped straight to code, opting for speed in an attempt to bypass the detailed design work that I would usually do in Figma. Instead, I used a themed component layer (Shadcn) and set up an inspectable, rendered, code-based design system using Storybook.
But I found that, even with this approach, the quality was worse. I got somewhere functional very quickly, but it wasn’t where I wanted to go.
AI still doesn’t really have “taste”. While it’s easy to get past purple gradient slop, telling something with a clear ability ceiling to “make it look better” became a recursive failure loop. It needed to be shown.
A screenshot can communicate appearance. However, controlling how AI applies what it sees in a reference image is difficult. Models often take sources too literally, resulting in component inconsistency.
Behaviour and system context are harder. Which component should it use? Should it fork one or create a variant? This resulted in loads of similar components and design system drift.
The product lacked a soul. It was functional but didn’t evoke a feeling. This can only happen when you deliberately consider how to create moments of delight and surprise, which requires combining layered or hidden interactions, animations, and other details. AI isn’t comfortable with absence, so it often over-designs.
So, I thought about how products used to be designed when you had a team of designers: through systems and rules. There was no point in creating every screen and component from scratch in Figma before sending it to Codex. That would be a waste of time.
Instead, I took the visual system hosted in Storybook, which was already based on tokens with primitive and semantic values, and set up an atomic design system starting with atoms and molecules. Focusing on refining the design, use, and interaction behaviour of these smaller, more commonly used components makes it much easier to ensure consistency when they come together.
Secondly, I took advantage of the Figma MCP “Write” feature and instructed Codex to create some of the components, with their variables and layout configurations ported over. I had a fully token-accurate view of the components in Figma, where I could explore the visual direction on a canvas. When ready, I could give the component back to Codex in a form it could read, without confusion over values. This was particularly useful for an interaction with multiple states, which was difficult to capture with a screenshot or prompt.
With the system in place, I codified clear rules and patterns for AI to follow: empty states, action confirmations, responsive behaviour, and more. Once this system is established, AI can create variants based on these patterns, which can then be extrapolated to future components. These guardrails constrain AI to create only valid component types that remain within acceptable visual parameters.
When designing AI-native products and moving at speed, you can’t manually design every screen. But you do need a system to avoid entropy and inconsistency. Treat your design system as you would when working in a larger team with junior designers. Create patterns and a philosophy that AI can follow.
That said, I have been questioning whether we need one source of truth for design when working with AI. If so, should it live in Figma, Storybook, code, or another platform; and how do we keep it up-to-date?
If you’re building AI-native products and want to create a long-term system that is maintainable and friendly to both designers and AI, let’s chat.