Evolving Design Systems from 0.5 to 1
Everyone uses AI. But how much does it actually change the way we work?
When working at a conceptual level, vibe coding as a form of proof of concept has become my default approach. I imagine a lot of designers and builders share this habit. It's fast, fluid, and it helps turn vague ideas into something visible.
When working within a single product, vibe coding also becomes a strong alignment tool. It helps stakeholders see what we mean instead of interpreting static and abstract frames or long documents.
But when the scope expands into an ecosystem, the question changes. What's the right way to build and align when everything starts connecting?
PoC Speed Prototyping
A short while back, I was a sole IC owning end-to-end product delivery. When building a full proof of concept, it was relatively straightforward to move fast: pull up mock data, assemble flows, and rely on open-source design systems to quickly match the look and feel at a production level.
What I was really delivering wasn't just UI. It was a way to prompt user flows into clarity. It helped align PMs, engineers, and stakeholders with speed. In a complex, regulated space where ambiguity is expensive, this approach created momentum.
Within a few months, I had effectively vibe-coded a full feature set in a highly constrained environment. It reduced uncertainty. It moved conversations forward. The prototype worked. Stakeholders were happy.
However, the speed also hides what doesn't scale:
- Open questions often stay undocumented
- Solutions are validated visually, but not always systematically or with evidence
- Data privacy considerations are sometimes deferred in early prototyping
- A working prototype doesn't guarantee performance, maintainability, or scalability
The prototype answers, "Can we make this work?"
But not always, "Should this work this way long term?"
The Challenges of Designing in a System
As the product ecosystem grows, especially when a design system is still in its early stages, the complexity shifts.
The challenge is no longer creating components. It becomes evolving a system without breaking what already exists in handed-off designs and in production.
One bottleneck I kept encountering was surprisingly simple:
"It's not a component," an engineer would say.
And the question behind that statement is often deeper: why isn't it?
What's visible in design tools doesn't always translate cleanly into implementation. In Figma, we assemble components visually, but in code, behavior, state, and composition live differently. The gap between the two is where friction starts to accumulate.
We begin to see undefined behaviors, inconsistent compositions across applications, and increasing difficulty in streamlining development across teams.
The shared interpretation is the key challenge.
Solving the Puzzles One by One
The approach becomes investigating first. It's less about designing screens and more about understanding patterns by collecting use cases across designs and what's in production.
Real use cases can help identify repeatable patterns, and how they behave across contexts, instead of defining just pixels. The focus changed:
- From pixels to behaviors
- From components to systems of composition
- From static specs to scalable, configurable rules
Documentation became less about describing UI and more about defining the design intent.
AI tools also started playing a supporting role as a way to rapidly explore and articulate behavioral structures, especially in assembled components. It helped bridge the gap between design intention and implementation logic. It helped designers understand the rules of thumb, and developers understand the implementation that becomes the source of truth.
More importantly, feedback loops became continuous rather than episodic.
Beyond Design Execution
At some point, the role started to feel different.
The scope has quietly expanded beyond design execution. It feels closer to an architect mindset that orchestrates systems, navigates multiple scenarios, and understands how components behave as a network rather than isolated parts.
Design system 0.5 wasn't the destination. It was an honest starting point.