Multiple platforms, one core identity

When the digital product expands across multiple platforms, a silent issue begins to arise: the web uses one color palette, iOS uses another, and Android uses yet another, not because anyone intends to, but because each team makes changes in their own space without informing each other. After a while, customers look at the three platforms and feel they are facing three different brands.

Which factor must be exactly the same, and which factor can differ?

This is the first question that needs to be answered before discussing tools or processes. Not everything needs to be absolutely uniform, and forcing uniformity in the wrong places will disrupt the user experience.

• Must remain consistent across platforms: brand colors, typography (including font sizes), signs, and the ratio of white space around the signs. These are the elements that users look at and immediately recognize as your brand.
• Should follow platform habits: Navigation, button placements, and notification displays. iOS users are accustomed to the tab bar at the bottom of the screen. Android users are familiar with a different layout. Forcing both platforms to look identical will make both feel strange.

Brand assets are the core layer inside. Platform experience is the outer layer. These two layers do not conflict if clearly defined from the start.

Common source: why it is needed and what it looks like

The most sustainable way to maintain consistency is to establish a common source for core elements, then allow each platform to retrieve them, instead of each platform saving separate copies.

In the practice of digital product design, this concept is referred to as design tokens: each color value, font size, and spacing is named and stored in a single location. The technical team connects those tokens to the source code of the web, iOS, and Android. When a primary color needs to be changed, it is only changed in the common source, and the entire platform updates accordingly.

Update a self-applied token across all platforms. There is no common source, and platforms drift apart over time.

Summary from iTitans, UXPin

From a design perspective, the common resources include a color system with codes for all display environments, typography rules that maintain reading rhythm, and a synchronized component library with documentation. The integration of tokens into the code for each platform belongs to the technical team operating the product, not the design team.

When to invest consistently, when it’s not necessary yet

Investing in synchronization when the product is not stable is a waste, as each structural change requires a complete redo of the pipeline. The level of synchronization investment should be measured by team size and product stability, not just by the number of platforms.

Common errors when managing multiple platforms

• Changing each platform without informing others: the web changes the button color, Android is unaware, and two months later, it is only discovered that there is a discrepancy. This is the most common mistake and can be avoided with a common resource.
• Making iOS and Android look identical: the result is an app that feels strange on both platforms because it does not follow the habits of any user.
• No clear owner for the standard file: each person keeps a version, and no one knows which one is the original. When needing to check the color standards, it takes time to trace back to the beginning.
• Invest in a token pipeline when the product is still continuously changing: it takes effort to keep up and is often left unfinished.

This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.