M.
0%
Systems14 Min ReadNov 4, 2026

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.

Mamdouh Ghaneemy
Mamdouh Ghaneemy
Fintech Product Designer
Component Redesigns After Handoff
0
The Reality

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

Split screen showing Figma design on left with 4 states and Nuxt 3 code on right
States Before Pixels · Dev-Ready

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."

The State Machine
EMPTY
No data · First visit
user triggers load
LOADING
Fetching · Skeleton UI
success
failure
SUCCESS
Data present
ERROR
Failed · Recovery path

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.

OrderBox.vueVue 3 + TypeScript
<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.

Success State

Sufficient tokens, clear cost breakdown, enabled CTA.

Insufficient State

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 file
  • loom/5-min video with state gaps
  • code/Nuxt 3 component examples