UNOWHY operated five distinct product brands from a single engineering organization: SQOOL (the main educational tablet suite), SQOOL Extend (virtual machines), SQOOL Protect (content filtering and parental controls), Hi SQOOL (the student communication platform), and the corporate brand used across institutional communication. Eight or more applications, spanning Android, Windows, and web. Each brand had its own product manager and its own visual identity. None of them shared components.
The case for a unified design system was obvious from an efficiency standpoint. The case against it, from a product manager's perspective, was also obvious: a shared component means your product looks like the others, moves at the speed of others, and has its roadmap constrained by others. Getting five PMs to surrender that autonomy required a different conversation than the one designers usually have.
The token architecture as political architecture
The Figma architecture I designed has three layers. The raw layer contains values: specific hex colors, pixel dimensions, font sizes with no semantic meaning attached. The semantic layer assigns meaning to those values: color/interactive/primary, spacing/component/default, typography/heading/large. The brand layer maps each brand's specific visual identity onto the semantic layer, overriding values without touching the component logic.
This three-layer structure solved the political problem more than the technical one. A product manager who understood that their brand token layer was entirely under their control, and that changing it required no coordination with other brands, was much more willing to accept shared components at the semantic layer. The shared components became infrastructure rather than constraint: they expressed the brand identity through the token layer, not through their own structure.
The practical implication was that a button component existed once, in the shared foundation. SQOOL's button was blue with a specific rounded corner radius, expressed through tokens. SQOOL Protect's button was a different shade with different typography weight, also through tokens. The component itself never changed. The brand expression was entirely localized to the token layer.
More time in alignment meetings than in Figma
The honest account of how this system got built involves acknowledging that the most difficult work happened in meeting rooms, not in Figma. Each PM had a mental model of which components in their product were unique and which were generic. Those mental models were often wrong, but they were held with conviction because they were grounded in the PM's product strategy.
The most productive alignment sessions were the ones where I brought existing component inventories: a visual audit showing every button variant, every card pattern, every form element across all five products. When PMs could see side by side that their "unique" component was 80% identical to another brand's version, the conversation shifted from principle to specifics. "Where exactly do these need to differ?" is a more productive question than "should we share components at all?"
The answer was usually: the difference is in the tokens, not in the component. Which is exactly what the architecture was designed to support.
Maintenance as the condition for trust
A design system that is not actively maintained becomes a liability faster than it became an asset. Teams adopt it because they trust that it reflects current standards and that someone is accountable for keeping it current. The moment that trust erodes, teams start diverging: building local variants, skipping the system for "urgent" work, until the system is technically present but practically unused.
At UNOWHY, I treated the design system as a live product with its own roadmap and release notes. When a shared component was updated, all five product teams received a structured change note: what changed, why it changed, what they needed to update in their products, and the expected timeline. That communication discipline was more important than the token architecture for sustaining adoption.
The 60% reduction in design time was the metric that mattered to leadership. For the design team, the more significant outcome was consistency: decisions made in one product's context informed the others, and the ecosystem started to feel like a coherent suite rather than five separate applications that happened to share a color palette.