Coordinate designers and developers: don't let it become hot potatoes.
The most common mistake is not in the skill level but in the timing of the first meeting between both parties.
Good collaboration between designers and programmers starts earlier than most people think. It begins right from the wireframe, not after the design is complete. Involving programmers early helps identify technical constraints before the design goes too far in an unbuildable direction. Both sides should use a shared specification (spec) and naming conventions to ensure mutual understanding.
- the product has complex interactions, requiring programming from the wireframe stage
- Guests with an existing foundation that needs design integration into the current system.
- multiple dynamic states and many screens need continuous synchronization
- a hot potato handover, meeting the developers for the first time after design is complete
- There is no common language, so each side understands the spec differently.
Most issues between design and programming do not arise from a lack of skill. They occur because the two sides meet too late in the process. The designer works alone and then "throws it over the fence" to programming. Only then do they discover that seemingly simple elements on the screen take three times longer to build, and sometimes cannot be built as designed. This is the root of most conflicts and delays in digital projects.
Core error: delivering in a hot potato manner
The term "hot potato handoff" in the industry accurately describes the essence of the problem. Everyone wants to pass responsibility as quickly as possible, and no one wants to hold onto it for long. Designers see their job as done when the design is complete. Programmers receive the design and try to figure out how to implement it without understanding the intent behind each decision.
The practical consequence is that programming builds something different from the design due to misunderstanding the specifications. Designers complain that programming does not respect the original. Both sides blame each other, and the product ultimately suffers. No one is wrong; the process is wrong.
Bring programming in earlier than you think.
The principle to keep is to involve programming as early as possible. Ideally, this should be from the wireframe stage or when discussing initial ideas, before the design has colors, fonts, and effects.
Why is this stage important? Because programming reveals constraints that designers may not see. A smooth transition effect in a prototype may require complex logic that does not correspond to the value it brings. A flexible layout on a design screen may break on real devices if browser constraints are not considered. Catching these issues early keeps adjustment costs low. Discovering them after the design is complete significantly increases costs.
Common baseline: the conditions for collaboration
Early collaboration is insufficient if both parties do not have a common baseline. This is the role of tokens (design variables) and a unified naming convention.
- Tokens are shared values: primary colors, font sizes, spacing. When tokens are consistently named between the design and code, developers do not have to guess "what shade of blue this is in the system."
- Clear specifications mean documenting intent, not just visual outcomes. Why does this button have a disabled state? What triggers the error state? This information, if not documented in the specifications, leaves programmers to guess.
- The naming convention for components (interface elements) helps both parties discuss the same thing when addressing issues or discussing.
Without a common baseline, each side works in its own silo even if they are in the same room.
The design team collaborates with the existing technical team of the business: this approach is suitable when the business already has its own infrastructure and systems, and the design needs to fit into the running framework. It is essential to establish a common language and clear feedback rhythm from the start.
One party takes full responsibility for both design and implementation: this approach is suitable when the business does not have a technical team or wants to avoid the management costs of coordinating multiple parties. The technical perspective is integrated from the experience flow building stage, catching early on elements that seem simple but are difficult to implement. In return, the business relies on a single point of contact.
The business handles both sides: collaborating with an internal team that includes both designers and developers who are used to working together; what needs to be maintained is a common baseline and feedback rhythm.
Collaboration is continuous, not a one-time event.
Even with a good start, many projects still fail midway because they view collaboration as a one-time event: a kickoff meeting followed by each side working independently, only to meet again at handoff. In reality, design changes throughout the process. New screens are added. States are discovered during implementation. Client requests for adjustments arise.
Without regular feedback loops and clear version control, programming may be working from an old version while the design has moved on to a different one. This is the source of most disputes over "not building according to design," which is actually due to both sides using different versions. When design and technical constraints conflict, it is also necessary to clarify from the start who makes the final decision to avoid prolonged debates.
The strongest teams do not focus solely on a single deliverable moment, but gradually build a shared understanding and space for design alongside product development.
Figma Blog, The Designer's Handbook for Developer Handoff
Decision checklist
Topic: Collaboration between designers and developers. Sinh Vũ Handbook, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Figma Blog, The Designer's Handbook for Developer Handoff; WeAreBrain, Designer-Developer Handoff: The Art of Collaboration; Lucidchart Blog, Best Practices for Designer to Developer Handoffs; practical experience from Sinh Vũ.
Frequently asked questions
If the business already has its own development team, how should the design side collaborate?
The design team should work directly with your technical team, establishing a common baseline through clear specifications and consistent naming conventions. Instead of handing off once and leaving it, both sides should maintain a regular feedback rhythm throughout the project to catch discrepancies between design and actual implementation early. This approach is suitable when the infrastructure is running and the design must fit into it.
Is it okay to find a developer after the design is completed?
Okay, but the risks are significantly higher. Meeting programming for the first time after the design is complete is what the industry calls a 'hot potato handoff': design is thrown over the fence to engineering. Discovering late that certain elements cannot be built increases the cost of fixes. If this sequence is unavoidable, at least a detailed specification is needed, and the design should be ready for adjustments after programming evaluation.
What are tokens and naming conventions? Are they necessary?
Tokens (design variables) are shared values such as colors, font sizes, and spacing, named consistently so that both design and code use the same baseline. Naming conventions help programmers understand the design intent without needing to explain each case. For projects with many screens or states, this is what keeps both sides aligned. For a simple page with few states, a concise set of conventions is sufficient.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.