Design Systems · 4 min read
Decide Once, Ship Everywhere
A shared record of meaning keeps product decisions consistent while letting each platform do its own design work.
The same idea can look like four different decisions: “paused” appears one way in the web app, another in the Mac app, a third in the Android app, and yet another in the docs. The teams may all be doing careful work. But if each team decides the name, shape and color separately, the product still drifts.
The drift problem
Each platform has its own grid, color model, file format and state rules. Think of these as its dialect: the local conventions that shape how a design is made and delivered. The differences are real, and they matter. A detail that works in one dialect may not work in another.
The trouble starts when meaning is decided inside each dialect, too. If “warning” gets named, drawn and colored separately on every platform, the decisions can slowly diverge. With five libraries, that drift has five places to hide.
A designer can spot a mismatch and patch it. Then someone else updates a file on another platform. Now the libraries disagree again. This is not a failure of effort. It is a system that asks people to remember and repeat the same decision.
Consistency should not depend on someone catching every mismatch. It should be a property of the system.
One record of meaning
The alternative is a manifest: one record that says what a thing means and how it maps to each platform. Each entry holds one meaning, with a name, label, roots, sign type, synonyms, whether it mirrors in right-to-left layouts, and the matching names in each platform’s own icon set.
Alongside that record are design tokens: named values for shared decisions such as size, color, state and status. Master drawings provide the source artwork. A build reads the entries, tokens and drawings, applies the rules, and writes the files for every platform.
The key is that people make the meaning decision once. The build carries it through the different dialects. Nobody edits an output by hand; if something needs to change, the source record or drawing changes, and the files are made again.
That does not mean every platform gets the same pixels. It means each platform’s version starts from the same decision. The files can differ where the platform requires it, without the meaning drifting along with them.
It worked before the tools existed
In 2003, every Citrix screen went to one of sixteen marketing agencies. There was no style guide and no shared vocabulary. Over 2003–2007, the product design team built one icon grammar.
It was an atomic system: shapes, elements, base icons, applied icons and complex frames. Five rules governed the work: read at every size, depth and theme; look as if one designer drew everything; make creation fast and teachable; encode meaning in filenames; keep one gatekeeper and one depot.
Windows Vista-era delivery meant 28 files per named icon. The work is estimated to have saved $10M a year.
The tools may change, but the underlying move is familiar: establish one place for meaning, then make the outputs from it.
The industry is moving the same way
The W3C Design Tokens Community Group's specification reached its first stable version on October 28, 2025. It gives design tools and code a shared, portable format for design decisions such as color, size and type.
On May 26, 2026, Google announced a fresh visual identity for its Google Workspace app icons: Gmail, Calendar, Chat, Meet, Drive, Docs, Slides, Sheets, Vids, Keep, Forms, Voice, Sites and Tasks. The company said the changes “drive consistency and cohesion across our product suite, while ensuring each individual application remains modern and recognizable.”
That is a company with one of the most recognized icon families choosing suite-wide consistency. It is not evidence that Google used tokens or a manifest. It is evidence that keeping a family coherent across a suite is worth deliberate work.
The case for local decisions
Platform teams know their platform best. That is a strong reason not to force one visual treatment everywhere. A central record can become a bottleneck, or it can flatten the work into a lowest-common-denominator design.
But the record holds meaning, not pixels. Each platform still speaks its own dialect: its grid, rendering modes and color model. Platform designers own that dialect. The build only makes sure that each dialect says the same thing.
This is the useful split: central meaning, local craft. The shared decision gives teams a stable starting point; it does not take away their responsibility to make the result work on their platform.
Icon lens
In Digital Sanskrit terms, meaning lives in the glyph layer (root plus modifier) and is decided once. State, status, size and color live in the context layer and are applied by tokens. A platform is a dialect, not a new language. That distinction keeps the concept stable while the expression adapts.
Try this
**Goal:** Find one status meaning that is being decided more than once.
**Steps:** 1. Pick one status sentence from your product, for example “this item is selected and needs attention.” 2. List every platform it appears on. 3. Write down how each one draws, names, colors and announces it to screen readers. 4. Circle every cell where two platforms disagree, then write the single manifest entry that would make them agree.
**Check:** Every platform's version can be generated from that one entry.
**Reference:** Digital Sanskrit, Appendix B.1 (The surface map) and B.8 (One concept across every surface).
Sources
- [Google Workspace Updates, Introducing a fresh visual identity for Google Workspace app icons (May 26, 2026)](https://workspaceupdates.googleblog.com/2026/05/introducing-fresh-visual-identity-for-Google-Workspace-app-icons.html)
- [W3C Design Tokens Community Group, Design Tokens specification reaches first stable version (Oct 28, 2025)](https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/)