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 coordination between designers and developers starts earlier than most people think: right from the wireframe, not after the design is complete. Involving developers early helps catch technical constraints before the design goes too far in an unbuildable direction. Sinh Vũ maintains a common language through specs and naming conventions so that design and engineering do not end up with different understandings.
- 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 occur due to poor skills. They happen because the two sides meet too late in the process. The designer works alone, then "throws it over the fence" to programming, and only then discovers that seemingly simple elements on screen take three times longer to build or 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 the responsibility as quickly as possible, and no one wants to hold it for long. Designers consider their task complete when the design file is finished. Programmers receive the file and figure out how to build it without understanding the intent behind each decision.
The practical consequence: programming deviates from the design due to misunderstanding of specs, designers complain that programmers do not respect the original files, 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 Sinh Vũ maintains: it is never too early to involve programming. Ideally, this should happen from the wireframe stage or when discussing initial ideas, before the design has colors, fonts, and effects.
Why is this phase 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 actual devices if browser constraints are not considered. Catching these issues early incurs almost no adjustment costs. Catching them after the design is complete significantly increases costs.
Common language: 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 file and the code, developers do not have to guess "which blue this is in the system."
- A clear spec means documenting intentions, not just visual outcomes. Why is this button disabled? What triggers the error state? If this information is not recorded in the spec, programmers have to guess.
- The naming convention for components (interface elements) helps both parties discuss the same thing when addressing issues or discussing.
Without a common language, each side works in its own silo even when sitting in the same room.
Collaborating with the client's existing technical team: Sinh Vũ takes on design and works directly with your programming team. This approach is suitable when the client has their own platform and system, and the design needs to fit into the existing infrastructure. It requires establishing a common language and clear feedback rhythm from the start.
Sinh Vũ offers a complete package: Sinh Vũ takes responsibility for both design and actual production, serving as a single point of contact. This approach is suitable when clients do not have a technical team or want to avoid management costs associated with coordinating multiple parties. The technical perspective is integrated from the experience flow design stage, addressing seemingly simple yet challenging construction points early on.
Collaboration is continuous, not a one-time event.
Even with a good start, many projects still fail midway because they treat coordination as a one-time event: a kick-off meeting followed by each side working independently, only to reconvene at delivery. In reality, design evolves throughout the process. New screens are added. Issues are discovered during assembly. Client adjustments are required.
If there is no regular feedback loop and clear version control, the programming will be based on an old file while the design has moved to a different version. This is the source of most disputes about "not following the design," which is actually due to both sides using different versions.
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
The viewpoint of Sinh Vũ
Since Sinh Vũ designs and builds functional websites, the perspective on technical feasibility is not an afterthought; it is integrated from the start when creating the user experience flow. This helps catch early design decisions that may look reasonable on screen but are costly or fragile in real implementation.
When working with the client's technical team, Sinh Vũ does not just hand over files and walk away. Sinh Vũ establishes a common language from the start, maintains a communication channel throughout the project, and clearly defines who makes decisions when design and technical conflicts arise. This is what helps the project avoid getting stuck between two islands.
Decision checklist
Topic: Collaboration between designers and developers. Sinh Vũ Handbook, sinhvu.com
Select each item you find appropriate, 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 client already has their own programming team, how does Sinh Vũ coordinate?
Sinh Vũ will work directly with your technical team, establishing a common language through clear specifications and consistent naming conventions. Instead of delivering once and moving on, Sinh Vũ maintains a rhythm of ongoing feedback throughout the project to catch discrepancies between design and actual implementation early.
Is it okay to find a developer after the design is completed?
Yes, but the risks are significantly higher. Meeting the programmer for the first time after the design is complete is a handoff that the industry calls 'hot potato': design is thrown over the fence to the technical team, and discovering late that some parts cannot be built will multiply the repair costs. If you must follow this sequence, at least have a very detailed spec and be ready to adjust the design after programming evaluation.
What are tokens and naming conventions? Are they necessary?
Tokens (design variables) are shared values like 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 multiple screens or states, this is what keeps both sides aligned.