Synchronizing design with code: sufficient or overdone
The question is not about whether to synchronize or not, but at what level synchronization is appropriate for the team's scale and product stability.
The level of consistency should correspond to the number of platforms and the number of people building the interface, not just follow technical trends. For a stable product, using a shared token set (color values, typography, spacing as variables) is sufficient; there is no need to connect automatically to each codebase. Only when there are many platforms, multiple teams developing features in parallel, and a dedicated technical person maintaining it is it worth investing in a tighter connection.
- multiple web platforms on iOS and Android need tight synchronization
- A stable interface with a technical team maintaining the connection.
- The interface is still continuously pivoting and should not be tightly synchronized.
- Your team doesn't have enough people to operate the automated synchronization mechanism.
Synchronizing design with code is a common topic Sinh Vũ encounters when working with clients who have digital products. Most questions are not about "should we synchronize?" but rather "how far should we synchronize?" The answer does not lie in technical trends but in the actual scale of the team and the stability of the interface at that time.
The real risk of asynchrony
When there is no common source, brand colors can exist in three different places: one code in CSS for the web, one value in Swift for iOS, and one value in Kotlin for Android. Initially, all three places match. Over time, if someone changes the color on the web but forgets Android, the product starts to look like three different brands.
This is the core risk that a shared token addresses: define a color once, and all platforms pull from that source, changing one place applies everywhere. Even without automatic connections, having a clearly documented list of tokens and ensuring the entire team adheres to it significantly reduces this risk.
Three synchronization levels and when to use which level
Level 1: Common tokens, clear documentation, manual updates
Suitable when: a product has a relatively stable interface, the team is moderate, and there is no dedicated person for interface technicalities.
What to do: create a file listing color, text, spacing variations, and update conventions. Whenever a value changes, the whole team follows that file.
Limits: dependent on human discipline; if someone forgets to update, it will still be off.
Level 2: Tokens connected to each platform's code, with an automated pipeline
Suitable when: multiple platforms are used simultaneously, multiple teams are developing features in parallel, and there is a technical person dedicated to maintaining the connection.
What to do: tokens are automatically exported from the source file into each codebase. Changing tokens updates all platforms through the pipeline.
Limits: building and maintaining a pipeline is labor-intensive, requiring someone who understands both design and technology.
No automatic synchronization, maintain manual sources but with discipline
Suitable when: the interface frequently changes direction, or the team does not have enough operational personnel.
What to do: maintain a token list, not yet automated, waiting for the interface to stabilize before reassessing.
The reason: when the interface is continuously pivoting, the pipeline automatically becomes a burden because it must be updated each time the direction changes.
Which factor determines your sufficient level?
- Number of platforms: Web, iOS, Android simultaneously increases the demand for synchronization. One platform is sufficient.
- Stability of the interface: If the interface changes frequently, tight synchronization requires more effort to keep up than the value it brings.
- Technical team capability: an automated bridge requires maintenance. Without dedicated personnel, the pipeline will fail, and no one will fix it.
- Opportunity cost: The effort to build a bridge could be used for more urgent features during the product expansion phase.
Core elements like color and typography should be consistent across platforms, but each platform still has its own interaction habits that need to be respected. Absolute uniformity makes the product unfamiliar to users of different operating systems.
UXPin, Design systems for cross-device consistency
Common mistakes when going in the wrong direction
- Forcing absolute consistency between iOS and Android: disrupts the habits of users on each platform, making the product appear rigid and unfamiliar.
- Create an automated pipeline when the interface is still unstable: it takes more effort to keep up than the value created, leaving the team exhausted with infrastructure instead of focusing on the product.
- Neglecting a common source: Allowing each platform to drift over time means that when you want to change brand colors, you have to fix dozens of places and still miss some.
The viewpoint of Sinh Vũ
In working with clients who have digital products, Sinh Vũ takes on the role of creative director and rule setter: locking shared resources such as colors, fonts, and interface components into a clear library and documentation. The task of integrating tokens into each codebase is the responsibility of your technical team or programming partners; Sinh Vũ does not replace that role.
What Sinh Vũ advises is to achieve just enough synchronization with the actual scale. For small clients, one platform with a flexible interface: clear token documents are sufficient, no need for a complex system. For larger clients with multiple teams and platforms: consider level 2, but there must be a technical person responsible for maintenance. There is no one-size-fits-all formula, only the right questions to ask before making decisions.
Decision checklist
Topic: How much should design be synchronized with code, enough or overdone. 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
iTitans: design tokens for cross-platform. UXPin: design systems for cross-device consistency. Practical experience from Sinh Vũ Studio.
Frequently asked questions
What is a design token? Is it complicated?
Design tokens are common variable names for colors, font sizes, and spacing, for example: 'primary-color' instead of hardcoding hex codes everywhere. When you need to change the brand color, you only edit one place, and all platforms update accordingly. It starts simply: a file listing variables and clear documentation is enough for a small team.
Does Sinh Vũ handle code integration for my product?
Sinh Vũ handles the common source lock such as color palettes, typography, interface components in the library, and design rules. The integration of tokens into each platform codebase is the responsibility of your technical team or programming partners. Sinh Vũ advises on appropriate synchronization levels and prepares handover documents for the technical team to implement correctly.
With the interface changing frequently, should we set up automatic synchronization yet?
You shouldn't. When the interface is frequently pivoting, automated connections become a burden because every design direction change requires updating the pipeline. During this phase, maintain a manual but disciplined source, meaning there should be a single token file and clear update agreements, waiting for the interface to stabilize before considering automation.