De[v]sign: Blurring the Lines Between Development and Design

Our designer hasn't opened Figma in months. Our engineers are making design decisions. We're shipping faster than we ever have, and the product looks more consistent, and to be honest, none of us are totally sure what our job titles mean anymore.

This is what happened when we built a design system at Astrocade.

Astrocade is a social entertainment platform where creators dream up games and experiences, and players have fun, socialize, and build community. We're a small team moving fast, with constant A/B tests, weekly UI changes, features shipping back-to-back. For a long time the workflow was the standard one: design in Figma, hand off to dev, go back and forth until it looks right, repeat.

It worked… but the translation layer between design and code was expensive. Animations we couldn't communicate in a static mockup. Spacing that felt right in Figma but wrong in the browser. Devs blocked waiting on designs. Design blocked waiting on implementation to review.

The design system started as a way to reduce that friction. The question we started with was simple: can anyone on the team grab these pieces, compose something new, and have it feel intentional?

To make that possible, we needed a strong foundation. We built Figma variables, constructed a responsive token system, and created a robust component library on top of shadcn/ui. Shadcn worked well for us because it's open, readable, and easy for AI tools to modify directly. We used the primitives where they made sense, customized heavily where Astrocade needed its own feel, and added custom components as the product demanded them.

Process-wise, Figma was the trojan horse. It got the system defined in a place the team already understood, kept our designer in her Figma comfort zone (for now), and gave us a clear path for translating those decisions into code. Then we pulled the rug out, dropped our designer into a black-and-white Cursor window (and she hasn't looked back!).

With the system embedded in our codebase, AI could now be used to produce new UI and even update the system itself. Figma got us there, but the code became the source of truth.

There was real skepticism about this. Vibe-coding has a reputation for producing inconsistent UI — things that look fine in isolation but feel incoherent as a product. But because the token system was well-structured and the component library was tightly scoped, AI's decisions mostly stayed within the guardrails. It wasn't making aesthetic choices. It was assembling pieces we'd already designed, and the system kept it honest.

What changed for the team is harder to separate into design vs. dev because that's kind of the point. The system gave everyone a shared language — not metaphorically, but literally the same tokens, the same components, the same codebase. Devs can confidently build features with design-quality output because the lego blocks are all there and the rules are clear. Design can come in and iterate directly in the same branch instead of throwing a Figma file over the wall. We build on each other's work. The “does this match the design?” conversation mostly disappeared because design is already in the code when it ships.

For design, the biggest shift was control. It has always been difficult to communicate motion, rhythm and responsiveness through static screens alone - but moving the workflow into code closed a lot of that gap.

Storybook became a place to explore components. Coding agents became a vehicle to build and revise UI. GitHub PRs became part of the design process. We still look to Figma for open-ended exploration, but the source of truth moved much closer to the product itself.

We also created a design playground: a separate space for unlinked page files where ideas are explored without touching the main codebase. It works like a sketchbook, except the sketches are functional. We can test how it feels and put something real and interactive in front of users much more quickly.

For engineering, the shift was equally wild. Devs can now take more rough ideas or conversations with design and flesh them out into full-formed screens. For example we rebuilt the entire editor UI in the new system with only a few cryptic notes and some messy sketches as input. The combination of AI tools and strong foundations got us most of the way there, and after two quick feedback cycles, it was ready to ship.

The practical impact: features that used to take weeks to go from design to product now take days. Not by cutting corners, but by removing much of the translation layer.

This workflow does really ask something different of both designers and engineers though.

For designers, thinking in code, components, branches, and PRs is a different muscle than thinking in screens and flows, and that took time to get comfortable with. It's not just learning new tools; it's changing where design happens and what the artifact of design work actually is.

Engineers need enough taste to make good calls, enough restraint to stay inside the system, and enough judgment to know when design needs to come back in. Some of the workload shifts into reviewing more PRs from design and making sure the code is sound, but it's still much faster overall.

A few key takeaways for anyone thinking about this kind of workflow:

• A design system doesn't need to be comprehensive to be useful. It needs to be structured enough that AI can make predictable decisions with it. Tight tokens and clear component boundaries matter more than total coverage.
• Customizing an existing library like shadcn can oftentimes be a better investment than starting from scratch. You inherit solid patterns and accessibility work, then spend your energy adding on unique components and making the product feel like yours.
• The biggest unlock wasn't AI generating code faster. It was that a well-structured system made AI a reliable design collaborator. When the rules are clear, AI can compose layouts and interactions without creating the inconsistency that makes teams nervous.

As designers and engineers we each bring unique skills to the table, but at Astrocade we are now truly sitting at the same de[v]signer table and are understanding each other better. The product ships faster, feels more consistent, and the team is working way closer together than when we had a formal process keeping us in our lanes. The line between design and development is getting blurrier fast, and we believe that teams that learn how to work across that line are going to move at a speed that's hard to compete with.