Back to blog

From Figma to Cursor 24/7: A Designer's Guide to Vibe Coding

There's a new way of building that has fundamentally changed how I work. Some call it "vibe coding" - describing what you want in natural language and letting AI help write the code. As a product designer, this hasn't just been useful. It's been transformative.

Let me back that up with some numbers from my own Cursor usage:

  • 191 conversations across 28 projects
  • 85 detailed plans ranging from simple styling fixes to full application architectures
  • 25MB of transcripts documenting my journey from "help me center this div" to shipping complete products

This isn't a tutorial. It's a look at what happens when a designer decides to stop handing off mockups and starts building.

The Gap That Wouldn't Close

For years, I felt the friction. You design something in Figma, hand it off to engineering, and what comes back is... close, but not quite right. The spacing is off. The animation doesn't feel right. The interaction you spent hours perfecting doesn't exist.

The traditional answer was to learn to code "properly." Spend months learning React, understanding state management, wrestling with build tools. That's a huge investment for someone whose primary skill is design thinking, not software engineering.

But here's the thing I discovered: design thinking transfers.

How I Actually Prompt

Looking through my 191 conversations, a pattern emerges. I don't prompt like an engineer. I prompt like a designer.

Here's an actual prompt from one of my sessions:

"It feels wonky and poorly designed compared to the rest of the app, redo it"

That's it. No technical requirements. No specification of frameworks or patterns. Just design language - the language I've been speaking for years.

And when things aren't working:

"On refresh we get rid of a lot of information, changes go away, usage metrics go away, sub agent tasks go away. I don't know why this is something I even have to mention - that should not be happening."

I talk to Cursor like I'd talk to a colleague. The frustration, the design intuition, the expectations - it all comes through. And it works.

The Evolution: From Styling to Systems

Looking at my 85 plan files tells a story of progression. The names alone show how far I've gone:

Phase 1: Designer Comfort Zone

  • message_spacing_overhaul
  • scroll_animations
  • theme_accessibility_audit
  • page_styling_consistency

This is where every designer should start. You know exactly what you want - you've been making these decisions for years. The difference is now you can implement them yourself.

Phase 2: Getting Ambitious

  • make_chat_feel_alive - redesigning tool calls to show rich, interactive components
  • next_level_polish - because "good enough" never was
  • dashboard_enhancement - moving from pages to full features

Here's what the make_chat_feel_alive plan actually looked like:

"Redesign tool call rendering to show rich, interactive components - file viewer with diffs for edits, terminal output for bash, file badges for reads, and a working indicator - making the chat feel alive like Cursor."

That's a designer spec. I described the experience I wanted. The AI figured out it needed to do stuff in PureScript, handle JSON parsing, implement collapsible <details> elements, and manage CSS for five different component types.

Phase 3: Building Products

  • purescript_radix_component_library
  • elm_dashboard_implementation
  • weapon_gui_mvp
  • vibe_codex_mvp

By this phase, I was building full applications. Not landing pages. Not prototypes. Production software.

The Meta Moment

Here's where it gets weird: I built a tool called Wavelength to analyze my own vibe coding patterns. An app that scans your AI coding chat history from Cursor, Windsurf, VS Code Copilot, Codex CLI, and Claude Code, then computes Lighthouse-style scores for your workflow.

Think about that for a second.

A designer built a multi-source data extraction tool with SQLite adapters, a multi-provider LLM client, and a full React dashboard - all through conversations with AI.

The plan for Wavelength was 400+ lines. It included:

  • Database schema designs
  • API architecture
  • A two-pass LLM analysis pipeline
  • Cross-platform path detection for Mac, Windows, Linux, and WSL
  • Caching strategies to minimize API costs

I didn't learn to be a systems architect. I described the product I wanted to exist, and iteratively built it.

What Actually Helps (Practical Advice)

After 191 conversations, here's what I've learned:

1. Lead with Design Intent, Not Technical Specs

Instead of: "Create a React component with flex-direction column and gap of 8px"

Try: "This feels too cramped and the visual hierarchy isn't clear"

The AI will figure out the CSS. Your job is knowing what "right" looks like.

2. Express Frustration Naturally

Seriously. My most productive sessions include phrases like:

  • "This doesn't feel right"
  • "It should be obvious that..."
  • "I'm seeing X but I expected Y"

Design is about gaps between expectation and reality. Expressing that gap clearly is more valuable than technical descriptions.

3. Reference What You Know

I constantly reference other products: "Like the Cursor sidebar", "Similar to Vercel's dashboard", "The way Linear handles this."

You've spent years studying good interfaces. Use that library. The AI knows these products too.

4. Don't Start in Figma

This was the hardest habit to break. For new ideas, I now describe the component or page directly to Cursor first. I iterate at full fidelity. Figma becomes a documentation tool, not a starting point.

5. Read the Code (Eventually)

The code Cursor generates is right there. I read it. I'm accidentally learning PureScript by building things I actually care about. I now understand Halogen components, CSS-in-PureScript patterns, and functional state management - not because I studied them, but because I kept seeing them in context.

What This Means for Designers

We're entering an era where the barrier between design and implementation is dissolving. And I don't mean in the "designers should learn to code" way we've been hearing for a decade.

I mean: the implementation is the design process now.

My most polished work isn't a Figma file. It's running software I actually built. The accessibility audit I did? I fixed the issues myself. The animation that "didn't feel right"? I tweaked the easing curve directly in code, refreshed, and saw the difference.

The designers who embrace this will have a superpower. They won't just hand off mockups - they'll hand off working prototypes. They'll speak the language of the engineers they work with. They'll understand what's easy and what's hard to build.

They'll ship.

It's Not Magic

Let me be clear: I'm not replacing engineering teams. Complex state management, authentication systems, database design at scale - that's still specialized work that requires deep expertise.

But for UI, interactions, visual polish, and even surprisingly complex features? I can now do that myself. And honestly? It's the most fun I've had as a designer in years.

There's a creative joy in describing something and watching it appear on screen. It feels like the design tools we always wanted.

Try It

If you're a designer who's been intimidated by code, give vibe coding a shot. Start with something you know cold - maybe a component you've designed a dozen times. Describe it naturally, like you'd describe it to a colleague.

You might surprise yourself.

After all, I went from Figma handoffs to shipping 28 projects. The gap finally closed. And not because I became an engineer - but because I stayed a designer who learned to describe things to a new kind of collaborator.