The design-dev handoff is where most fintech teams leak velocity. A designer completes a component spec on Tuesday. Dev starts Thursday (waiting for answers). Friday they ask three clarifying questions. Designer answers Monday. Dev rebuilds Tuesday. QA finds a mismatch Wednesday. By Thursday, it's finally right.
Five days to ship a feature design. The design took one day. The communication took four.
This isn't a people problem. It's a process problem. And it has a specific fix: eliminate ambiguity by making design explicit, linking it to code, and documenting everything async.
Here's how to reduce that cycle from 5 days to 1.
Why Back-and-Forth Happens
The real reason teams have prolonged handoffs isn't because designers are slow or developers are lazy. It's because design specs are incomplete.
A typical Figma screen shows what something should look like. It doesn't show:
- What component should I use for this? (Button vs. IconButton vs. custom?)
- What tokens does this use? (Color name, spacing, typography)
- What are all the states? (Default, hover, focused, disabled, loading, error)
- What happens on mobile vs. desktop?
- What accessible attributes are required?
Developers have to ask. Designers have to answer. Repeat for each component. That's where the five days comes from.
The Root Causes
1. Component Names Are Different Designer calls something "Primary Button". Code calls it "ButtonPrimary". Small inconsistency, big coordination problem.
2. States Are Assumed, Not Documented The design shows the happy path. Developers invent the error state. QA tests it and says "this doesn't match the design." Because design never specified the error state.
3. Token Names Are Unknown Design uses a color. Code needs a token name. "Is this color-semantic-primary or color-semantic-action?" Someone has to ask.
4. The Spec is a Static Image Designer exports a screenshot. Developer reads it offline. They ask a question. Designer has to wait to see the message. They write back. Dev hasn't checked Slack. By the time dev reads it, their context is gone. Now they re-read the old spec and ask a different question.
5. No Single Source of Truth Design lives in Figma. Code lives in a repo. Storybook is somewhere else. No one is 100% sure what the current reality is.
Step 1: Name Everything the Same
Start here. This single step cuts clarifying questions by 30%.
Component names: decide on a standard. Call it either PascalCase or kebab-case. Pick one. Use it everywhere.
Designers: Button, Modal, DataTable, FormInput.
Developers: Button.tsx, Modal.tsx, DataTable.tsx, FormInput.tsx.
Figma components: "Button", "Modal", "DataTable", "FormInput".
Storybook: Button.stories.js, Modal.stories.js, etc.
Token names: same consistency. color-semantic-primary in Figma, --color-semantic-primary in CSS, colorSemanticPrimary in TypeScript. Always the same base name.
Create a naming reference document. Put it in your design system wiki. Have designers and developers sign off on it. Reference it when you disagree.
Step 2: Document States Before Handoff
Before design goes to dev, the designer must answer: what are all the states?
For a button, that's: default, hover, active, focused (keyboard), disabled, loading.
For a form field, that's: default, filled, focused, disabled, error (with message), error + focused, success.
For a data table row, that's: default, hover, selected, loading, empty state.
Create a state matrix in Figma. Every component gets a 2D grid showing every state across every context. Show it to developers before they start coding. They build exactly what's designed. QA tests exactly what's designed. Ship it.
This single practice—documenting states upfront—probably saves more developer time than anything else. No surprises in production. No "wait, how should the error state look?" calls.
Step 3: Connect Components to Code
Use Figma's Code Connect feature. Link each Figma component to its corresponding code component (Storybook story, React component, whatever).
Now when a developer opens the Figma file, they see the component and immediately see: "This is Button.tsx" with a link to the actual code. No hunting for the right component. No ambiguity.
Similarly, when a designer opens Storybook, they see all the states and variants actually built. They can validate: "Did dev build this correctly?"
Figma and code become one system. Not two separate tools.
Step 4: Use Async Check-ins, Not Sync Meetings
Here's where a lot of handoff time gets wasted: meetings.
Designer finishes spec. Sends it to dev with a message: "Ready to build." Dev says "Let me review and get back to you." They study it offline. 30 minutes later they send written questions: "Q1: confirm this uses spacing-sm here? Q2: is the loading state a spinner or skeleton? Q3: mobile breakpoint at 640px?"
Designer reads it. Answers in writing. "A1: Yes, spacing-sm. A2: Spinner. A3: 640px, confirmed."
Dev builds. No more questions. Ship it.
Total back-and-forth: 2 rounds of async communication. Time to first build: 4 hours.
Compare this to the default: "Let's sync on Thursday at 2pm." One day passes. On Thursday they talk through it. Dev realizes they missed something. Asks the designer to clarify. Designer goes back to Figma, realizes they didn't spec it. Back-of-the-napkin fix. Dev builds on Friday. It's close but not exactly right.
Time to first build: 2 days. Result: lower quality.
The rule: No sync meeting unless you've exhausted async. Use Slack threads on the PR, Figma comments, or email. Give async questions a 2-hour turnaround. Usually that's enough.
Step 5: What "1-Day Handoff" Actually Looks Like
When all four steps are in place:
Day 1, 10am: Designer finishes component. Verifies all states are documented. Checks that every component name matches code. Links the Figma frame to the Storybook story using Code Connect. Adds a comment: "Ready for dev. All states in the state matrix. Uses spacing-sm, color-semantic-primary. Mobile breakpoint 640px. Linked to [Storybook story]."
Day 1, 11am: Dev opens Figma. Reads the description. Sees Code Connect link to Storybook. Clicks it. Reviews the current component. It's 95% there. They see which variants are missing. They scan the state matrix. Zero questions. They start building.
Day 1, 3pm: Dev opens a PR. Includes new variants. Shows them in Storybook. Tags the designer for review: "New variants: loading, error, error+focused. Design review needed."
Day 1, 4pm: Designer reviews PR. Sees the new states rendered in Storybook. Validates them against the state matrix. One feedback: "Error state needs the error icon next to the text." Dev makes the change.
Day 2, 9am: PR merges. Feature ships. QA tests. No mismatches. Done.
Five days compressed into one. The key: clarity from the start, async communication, and a system (Code Connect + Storybook) that's the single source of truth.
How to Start This Week
Monday: Create naming standards. PascalCase for component names. Token naming convention. Document it. Align with the team.
Tuesday-Wednesday: Retrofit your Figma and code. Rename mismatched components. Update token names in Figma to match code. Not everything, just the core 5-10 components your team uses most.
Thursday: Set up Code Connect. Link Figma components to Storybook stories. 15 minutes per component. Start with 3 components. Get it working.
Friday: Draft a handoff template. Include sections: "States documented" (matrix), "Component names" (list), "Tokens used" (list), "Accessibility notes" (checklist). Use it for your next feature.
By the following week, you'll see the difference. Questions drop. First build is faster. Rework shrinks. That's the compound return on a clearer process.