Design System: From Constraint to AI-Native

A design system I built at Beacon under hard constraints became the foundation for two AI-native systems at Cube — this is that story, told as one arc instead of two separate projects.

The Throughline

I’ve hit this same moment three times now: a team needs to move fast, and Design is at risk of becoming the thing that slows them down. Every time, I had less resource than I needed to fix it properly. What worked wasn’t protecting Design’s territory — it was building something rigorous enough that other people could use it without me in the room.

The naming discipline I was forced to build under constraint at Beacon is what made everything after it possible — a product design system at Cube, and later a marketing system that had no rules at all when I got it.

Act 1 — Beacon: Discipline Under Constraint (2023–2024)

The problem. Beacon’s platform ran on three separate codebases — Web, iOS, Android — each maintained on its own. High maintenance cost, handoff misalignment, slow iteration on anything that touched more than one platform.

The process. Three designers, one weekly cycle: Figma → Zeroheight→ Storybook → QA → Product/Business review. Every component went through that pipeline before it shipped — deadline or not.

The breakthrough. Adopting Tailwind class names inside Figma Dev Mode. Instead of design and engineering keeping two separate vocabularies for the same components, naming became shared — a real design-to-code connection, not just a handoff doc. That forced me to rethink our naming convention from scratch: every token and component had to make sense on both sides.

A theory I couldn’t act on yet. Our team was smaller at Beacon, and I stepped in to help the marketing team with the company website — which meant working directly in Webflow. Around that time, Figma and Webflow released copy-and-paste between the two platforms. That's when I saw it: if a component could move from Figma into Webflow and hold its structure, you could build the design system as Webflow templates. Not just a documentation system — a building system. Someone outside design could open Webflow, pull a component, and assemble a real screen without ever touching Figma.I copied a complex card component over and rebuilt it in Webflow to test the theory. It held. But we didn't have the resourcing to take it further, and I filed it away.The idea was right. I just didn't have the tools yet.

Outcome. Launched Q2 2024.

The idea was right. I just didn’t have the tools yet.

I copied a complex card component over and rebuilt it in Webflow to test the theory. It held. But we didn’t have the resourcing to take it further, and I filed it away.

Our team was smaller at Beacon, and I stepped in to help the marketing team with the company website — which meant working directly in Webflow. Around that time, Figma and Webflow released copy-and-paste between the two platforms. That’s when I saw it: if a component could move from Figma into Webflow and hold its structure, you could build the design system as Webflow templates. Not just a documentation system — a building system. Someone outside design could open Webflow, pull a component, and assemble a real screen without ever touching Figma.

There was one idea I couldn’t act on yet.

The Bridge

That Webflow idea stuck with me: what does it take for a design system to be usable by people who aren’t designers?

I got my answer twice more — first building the product system at Cube, then again when I was handed a marketing system that had been generated with no rules. At Cube, I watched PMs reach for tools like Lovable to throw together quick prototypes for stakeholders or customers. I understood why — they just wanted to prove an idea was real. But without anything governing those prototypes, it usually created more confusion, not less. It looked finished, so people treated it like a finished decision, when it was really just a guess.

In 2025, I came across a paper in my UX Research Methods class that named what I’d been watching. The GenUI Study by Chen, Knearem, and Li documented how designers, PMs, and engineers actually use AI generative UI tools in practice — and where they break down. Their finding matched exactly: people across roles were generating UI quickly, but the output didn’t connect to any actual design system. The tools could generate. They couldn’t constrain.

They called this gap Constrained Generation. The paper described, from research, what I had already been building from necessity.

That’s the lesson: don’t make Design the bottleneck between an idea and a demo — but don’t let the lack of Design create confusion either. Same fix both times. Build something solid enough that anyone can pick it up correctly without me in the loop.

Idea can come from anywhere. My job is finding a way for the team to move on it without getting stuck.

Act 2 — Claude Design System (Cube)

What I built. The naming and token discipline from Beacon was the foundation, but the medium was different — the system needed to work as something Claude could actually operate on. I wrote a CLAUDE.md file and a design skill that lets Claude Code work directly off locked components and tokens, scoped so it doesn’t burn through tokens re-figuring out context every time.

Fixing the meeting problem. Design alignment meetings kept going sideways — a conversation meant to align on flow would turn into a debate about visual details, and we’d end up back in the room again to redo it. Giving the team a locked, shared vocabulary for components meant those debates had somewhere to land before the meeting instead of during it. Flow conversations stayed flow conversations.

Faster prototypes, fewer engineering loops. With a strong system behind it, I could build high-fidelity prototypes in Claude that looked close to the real product, not a rough sketch. Using those to walk engineers through technical questions cut the back-and-forth by about 30–40%.

Act 3 — Rebuilding the Marketing System

Later I was asked to restructure Cube’s marketing design system, which had been generated entirely in Claude with no rules or naming behind it — the exact problem I’d spent two years learning to fix.

Since the token discipline already existed from the product system, I didn’t start from zero. I applied the same tokens to bring structure to the marketing system, and now marketing and PM can build blog posts and help-center pages themselves, faster, without waiting on design.

What I Learned

The tools were different every time — Figma and Storybook, then Claude Code and Figma MCP, then a cleanup pass on someone else’s AI output. The question underneath stayed the same: what does a system need so people outside design can actually use it, correctly, without me mediating every step?

That's what I keep coming back to, whatever the constraint - leading three designers at Beacon to build a Figma design system where every component had to match Engineering's language; an AI tool people are misusing; a system with no rules at all. The discipline isn't in the tool. It's in the naming and structure under it. That's the part that carries over.

The open question

The one thing still in motion: direct code handoff.

Since the AI-native workflow is new for the team, we haven't formalized how Claude-generated code moves into the engineering codebase yet. The clearest version of that gap: when a new UX pattern comes up, engineers ask how it's built in React — and right now the answer lives in my head, not in the documentation. I'm actively auditing the design system and working through component documentation, starting with the components already in production.

What's already there: Product and Engineering are using the design system to ideate and debate together directly — without waiting on Design. Engineers engage at the implementation level, asking questions about how components work and praising the quality of what's been built. The CEO flagged prototype quality as Sales Demo Ready, which means the system cleared the bar that customers actually see. And because everything shares the same component library and token system, Marketing can pull from it to scale social posts and campaign assets without breaking the visual language. Three teams. One system. The same rigorous foundation, working further than I'd planned.