There was a time when design systems were not even called design systems. In the early 2000s, companies relied on static brand manuals PDFs filled with logo rules, color codes, and font sizes. They worked because products moved slowly. A website redesign could take years. Mobile apps were barely a concern. Fast forward to today, and a single company may ship updates daily across web, iOS, Android, kiosks, wearables, and internal tools. The old rulebooks could not survive this speed. Tools like Figma, Storybook, and Zeroheight arrived with a promise: shared truth, living systems, and scale without chaos. Yet, as global teams multiply, a harder question has emerged: are these tools actually solving fragmentation, or just hiding it behind polished interfaces?
This is where Daniel Ojo enters the conversation. A product manager known in global product circles for turning messy systems into usable ones, Daniel has built and governed design systems that stretch across continents, platforms, and cultures. Colleagues often describe him as the rare Product Manager who speaks design, engineering, and business without sounding like a translator. In an ecosystem crowded with opinions, his perspective carries weight because it comes from systems that survived real scale, not theory.
When One Source of Truth Becomes Many
On paper, modern tools look like the answer. Figma centralizes components. Storybook documents UI behavior in code. Zeroheight promises alignment by turning decisions into readable guidance. But Ojo frames reality more sharply. At enterprise scale, a “single source of truth” often fractures the moment teams move at different speeds.
He points to what happened across large tech organizations in the late 2010s. Google’s Material Design, introduced in 2014, was meant to unify products across platforms. Instead, it quietly split into Material Design, Material You, and internal variants adapted by teams with different priorities. The tools worked. The fragmentation still happened. Not because designers failed, but because organizations grew faster than governance models.
In practice, teams duplicate Figma libraries to move faster. Engineers fork Storybook components to meet deadlines. Documentation drifts in Zeroheight because no one owns the narrative. The surprise is not that inconsistency appears, but that it appears even in companies that invested heavily in the “right” tools. Airbnb, for example, famously rebuilt its design language system around 2017, yet later acknowledged the need for constant recalibration as teams scaled and products diversified.
Daniel treats this not as a tooling flaw, but as a structural truth. Tools can store decisions, but they cannot enforce alignment when incentives push teams in different directions. A growth team optimizing conversion will bend components differently from a platform team optimizing stability. The fragmentation begins quietly, long before anyone names it.
What makes Dniel’s insight stand out is how he reframes consistency. For him, consistency is not visual sameness. It is behavioral predictability. A button does not need to look identical everywhere, but it must behave in ways users expect. Many tools focus on pixels. Enterprises suffer at the level of behavior.
Scaling Systems in an Age of Digital Transformation.
The second challenge is more uncomfortable. Digital transformation has forced companies to run multiple design systems at the same time. Legacy platforms cannot be rebuilt overnight. New products demand modern stacks. Global brands like IBM and SAP openly operate layered systems core foundations beneath product-specific expressions. Daniel does not see this as a failure. He sees it as realism.
What changes the outcome is how these systems relate to each other. In too many organizations, design systems compete. Each claims authority. Each has its own roadmap. The result is quiet rivalry instead of shared evolution. Tools like Figma and Zeroheight faithfully reflect this split, cataloging systems without questioning why there are five of them.
Daniel’s approach flips the script. Rather than forcing convergence, he emphasizes contracts between systems. Shared tokens, agreed behaviors, and clear rules on when divergence is allowed. This mirrors what engineering has done for years with APIs. In 2011, when Amazon publicly talked about its internal API mandate, it was not about uniformity. It was about interoperability. Design systems, Daniel argues, need the same mindset.
This is where tools show both their strength and their limits. Storybook excels when components are stable and shared. It struggles when teams need flexibility. Figma enables collaboration, but it also makes copying dangerously easy. Zeroheight clarifies intent, but only if someone curates it like a newsroom, not a wiki. The surprise here is that scale demands more human judgment, not less. Automation helps, but governance decides.
Daniel Ojo is often praised for turning this tension into momentum. Instead of promising teams freedom or control, he frames systems as agreements that can be renegotiated. That framing has helped organizations avoid the false hope that a new tool will “fix” fragmentation. Tools amplify culture. They do not replace it.
In 2020, McKinsey observed that companies treating design as a system rather than a department saw stronger long-term growth than their peers. Daniel’s thinking fits squarely in that mindset. He doesn’t trade in certainty; he equips teams for preparedness.
The lingering question remains unresolved, and perhaps it should. Can tools truly make scalable, cross-platform systems? The honest answer, drawn from the field, is no, at least not alone. They can support scale. They can reveal fractures early. They can preserve intent. But coherence emerges from decisions made repeatedly, under pressure, by people who understand why the system exists.
The era of static rulebooks is gone. The era of magical tools never arrived. What remains is the harder work of stewardship. As global products continue to sprawl across devices and markets, design systems will keep fragmenting and recombining in unexpected ways. The companies that thrive will not be the ones with the most sophisticated tools, but the ones with leaders willing to treat design systems as living infrastructure, not finished artifacts. In that reality, fragmentation is not the enemy. Ignoring it is.
