🌏 閱讀中文版本
Your PM drops a Figma link in Slack.
“Lock this down first.”
The engineer stares at the screen, cursor sitting at line 1.
Do you start with Figma?
Write a Swagger spec?
Or just…open the IDE?
Design-First seems like the safe bet, right?
Not necessarily. If this API is for third-party developers, those platforms typically need an API contract first — and Design-First is actually the longer route.
These three approaches solve fundamentally different problems. If the starting point doesn’t fit the context, later refactor costs can rise.
What Each Approach Actually Solves
This kind of conversation happens on teams all the time.
PM: “Can you show me a wireframe for this feature?”
Engineer: “Spec isn’t defined yet. A wireframe alone won’t support an API contract.”
Boss: “Stop arguing. Ship an MVP and validate the market.”
Sounds reasonable, right?
But here’s the thing: “API contract” means frontend-backend alignment to the engineer. To the PM, it’s unreadable JSON.
Let’s be clear about the constraints.
Approach A: Design-First (Figma leads)
Flow: Requirements → Figma design → Requirements sign-off → Development → API
Upside: Stakeholders can actually read it. No JSON required — just a nod.
Cost: You might design something that’s hard to build.
Approach B: API-First (Spec leads)
Flow: Requirements → API contract → Frontend/backend in parallel → Integration validation
Upside: Solid technical foundation. Frontend and backend can run in parallel.
Cost: It’s abstract. Stakeholders can’t follow it. Easy to drift from user needs.
Approach C: Code-First (Iteration leads)
Flow: MVP → Validate → Iterate → Iterate…
Upside: Fast validation. Working software first.
Cost: Technical debt accumulates. Refactor costs are high.
Why Design-First Is the Recommended Starting Point
In large enterprise system integration and multi-team parallel development, API-First is standard operating procedure.
But here’s the thing: most new products and features don’t start with system integration — they start with value validation.
1. Products are used by people
Visible beats abstract.
A PM reading Figma can say: “That button placement is off.”
A PM reading JSON can only say: “This field format has an issue.”
The communication cost between the two differs by more than one order of magnitude.
Specifically: PMs can audit domain semantics. Written specs and test cases also reduce guesswork — though UI-heavy scenarios depend on design mockups more than others.
2. Cost of change
Changing Figma: 30 minutes.
Changing code: 3 days.
That’s not a time gap — it’s a cognitive overhead gap. Every context switch back to the code means rebooting the mental stack.
3. Team alignment
PM, boss, and client can all read Figma. When everyone is aligned on the same artifact, decisions move faster.
4. The AI-era advantage
With a design file → Claude/Stitch has a reference point.
Without acceptance criteria and design constraints, AI output consistency drops.
AI tools are amplifiers. If you can’t clearly articulate what you need, AI will only help you amplify the rework caused by unclear requirements faster.
Four Common Risks with Design-First
Design-First isn’t a cure-all. There are four risks worth knowing.
Risk 1: Design outpaces technical reality
Design can exceed current technical, cost, or timeline constraints.
For example: a designer specs out infinite scroll, but the backend database doesn’t support cursor-based pagination. The refactor cost is steep.
Mitigation: Get developers into design review early. Not to veto — but to surface technical constraints before they become costly.
Risk 2: Inconsistent tool output
Stitch generates different results each time.
Mitigation: Build a Design System component library. Design-First without a Design System means component divergence, missed states, and visual spec drift.
Risk 3: The design-to-code gap
There will always be a gap between design and implementation.
Mitigation: Accept and manage the gap.
Risk 4: Over-design
Designing too many features that won’t be used.
Mitigation: Design to MVP scope first.
Your job is to make it better, not make it perfect.
Over-design is the same as no design at all.
The Tradeoffs: No Silver Bullet
Design-First fits: new products, MVP validation, clear UI requirements.
API-First fits: large enterprise system integration, pure backend services.
Code-First fits: technical exploration, POCs.
Mature method vs. emerging method — often A and B work in relay. I recommend a hybrid strategy.
Hybrid Strategy: Practical Recommendations
Something happened on the team recently.
A junior engineer used AI to write a feature. Around 500 lines, two hours. High efficiency — he was pleased with it.
Our senior engineer took ten minutes to review it, then frowned:
“There’s room to optimize the logic here. And you didn’t think about this — if this API goes external, your Error Code definitions are too loose. External clients will be calling to complain by day three.”
The junior paused: “But the PM only gave us a Figma…”
The senior said: “Figma is for users. APIs are for developers. You have to cover both.”
That’s why we need a hybrid strategy.
Phase 1: Design-First (Requirements Alignment)
- Designer produces wireframes/mockups
- Stakeholder review
- Developers join, flag technical risks
Phase 2: API-First (Technical Planning)
- Define API spec based on the design
- Frontend and backend align on the contract
- Parallel development begins
Phase 3: Code-First (Implementation Iteration)
- Rapidly implement MVP
- Validate, then iterate
- Continuous refactoring
This isn’t theory — it’s a practical lesson.
How do you pitch this to your boss?
“I’ll run two weeks of Design-First to build the MVP. If something goes wrong, that’s on me. If it validates, we shift to API-First for scale.”
That tells your manager: you’re not arguing over methodology — you’re managing risk.
Closing: Is This Problem Worth Solving?
Tools are amplifiers. But the starting point determines whether you’re amplifying value or debt.
When the product stage isn’t stable yet, the starting point shapes your communication overhead and rework costs.
You don’t need the answer right now. But starting to ask the question is the first step.
Matching the starting point to your context matters more than the tools themselves.
For your next feature — where will you start?
On drawing mockups, writing specs, or…confirming whether the problem is worth solving at all?