Stop Throwing PNGs Over the Wall: The Zero-Friction Nuxt 3 Handoff.
A developer cannot build a product from a happy-path PNG. Here's the 4-State Deliverable framework I use to ship designs that need zero rebuilds — with actual Nuxt 3 code examples.

Qompyl App: 60+ states documented before development. Zero rebuilds.

I used to throw Figma files over the wall and hope developers could read my mind.
Then I watched a senior developer spend three hours rebuilding a "simple" button component because I only designed the happy path. He had to guess the loading state, the error state, the disabled state, and what happens when the text is too long.
That button took 3 hours to rebuild. My fault. Not his. I gave him a PNG of a perfect world. He lives in the real one.
The handoff isn't about pretty mockups. It's about removing ambiguity. Every state, every edge case, every interaction — documented before a single line of code is written.
A developer cannot build a product from a happy-path PNG. Design every state or watch it get rebuilt.
Short answer: The 4-State Deliverable framework requires every component to be designed in four states before handoff: Empty, Loading, Success, and Error.
Why do traditional handoffs fail?
Short answer: Traditional handoffs fail because designers deliver screenshots of perfection while developers need specifications of reality.
The problem isn't the designer or the developer. It's the artifact. A static PNG answers "what" but not "how," "when," or "what if."
01 The Happy Path Trap
The issue: Designers show the ideal scenario: data loads instantly, users never make mistakes, and the API always returns 200 OK.
The reality: Users have slow connections, enter invalid data, and APIs fail. When these scenarios aren't designed, developers invent them — and their inventions rarely match the design system.
Example: I once designed a dashboard with beautiful charts. What I didn't design: the empty state, the loading state, or the error state.
02 The Spec Gap
The issue: "Make it look like the design" is not a specification. What's the exact padding? The exact hex code?
The reality: Without tokens and documented values, every developer makes their own interpretation. Suddenly you have 14 shades of blue and 8 different border-radius values.
What is the 4-State Deliverable?
Short answer: Every component must be delivered in four states: Empty, Loading, Success, and Error.
This isn't just about designing four screens. It's about designing for time and uncertainty.
01 Empty State
When it appears: First-time user, no data yet, cleared filters, zero results.
Example: An empty portfolio shows: "No strategies yet" with a "Create Your First Strategy" button.
02 Loading State
When it appears: Fetching data, processing transaction, uploading file.
Example: A dashboard shows skeleton cards matching the final layout's dimensions.
03 Success State
When it appears: Data loaded, action completed, form submitted successfully.
04 Error State
When it appears: API failure, validation error, network timeout, server error.
Example: "Connection failed. Check your internet and try again." with a "Retry" button — not just "Error 500."
How to implement this in Nuxt 3
Here's the actual code structure I hand off with designs. This isn't pseudocode — this is what developers copy-paste into their projects.
<script setup lang="ts">
const props = defineProps<{
state: 'empty' | 'loading' | 'success' | 'error'
tokenBalance?: number
cost?: number
}>()
const emit = defineEmits<{
(e: 'run'): void
(e: 'get-tokens'): void
}>()
</script>Real example: The Qompyl Order Box
Here's how I applied this to a real component in the Qompyl trading app.
Sufficient tokens, clear cost breakdown, enabled CTA.
Token shortfall shown before click, "Get Tokens" CTA.
The result: Zero component redesigns after handoff.
Handoff checklist
Before you send that Figma link to development, run through this checklist.
✓ Every component has:
- All 4 states designed (Empty/Loading/Success/Error)
- Token-based design system documented
- Interaction specs (hover, active, focus)
- Responsive breakpoints defined
- Accessibility notes (ARIA labels, keyboard nav)
- Code snippets for complex components
FAQ
Initially, it takes 2-3x longer than designing just the happy path. But you save 10x that time in development rebuilds. After a few projects, designing all four states becomes muscle memory and only takes 30-40% longer than the happy path alone.
No, but it helps immensely. For technical audiences (CTOs, senior devs), providing Nuxt 3/Vue 3 code snippets shows you understand their constraints.
Start with the core four (Empty/Loading/Success/Error), then add variant states as needed. Document all of them.
Show them the math: 3 hours spent designing states upfront vs. 20 hours spent on rebuilds later. Then do one component as a pilot and measure the time saved.
Monthly receipts. No fluff.
One email per month. What I shipped, what I measured, what I'd do differently.
One email per month. Unsubscribe in one click.
Send me your Figma file — I'll audit it for free
I'll record a 5-minute Loom showing exactly which states are missing and how to fix them.
figma/Share your Figma fileloom/5-min video with state gapscode/Nuxt 3 component examples