Building the operating system for a multi-product SaaS platform
Overview
When I joined EcoOnline, the company had been growing fast, mostly through acquisitions. Eight products, eight teams, eight different ways of solving the same UX problems. From a customer's perspective, it felt less like a platform and more like a holding company.
Prism started as a design system. It became shared infrastructure for how the whole company builds product.
The Challenge
Every product had been built in isolation, and it showed. Navigation, workflows, page structures, even simple interactions like assigning tasks or uploading documents had all been solved independently, multiple times, in incompatible ways.
That's a real cost. Customers had to relearn the basics every time they moved between products. Teams kept reinventing solutions that already existed elsewhere. And for a business trying to position itself as a unified platform, not eight loosely connected tools, it was a genuine strategic liability.
Approach
We knew a full UI overhaul across eight products wasn't realistic. The tech debt alone made that a multi-year undertaking. So we started where the impact was immediate: navigation.
By standardising on a single global top bar across every product, the portfolio started looking like a family. It sounds small, but it meant sales could demo the full offering and products felt related rather than acquired. That mattered commercially while the deeper work was underway.
From there, we defined how common cross-product experiences should actually work: task management, document handling, notifications, error states, mobile, page structures. Products were progressively revamped to align with Prism, and every new build was required to use the design system from day one.
The goal throughout was simple. If a customer knows one EcoOnline product, the next one should feel like they've been here before. Not just similar. Familiar.
AI and the Next Step
The ambition was specific: a PM should be able to open Claude, describe a problem, and get back something that already follows EcoOnline's design system, with the right tokens, components, and interaction patterns, without needing a designer in the loop.
Getting there required making our own knowledge legible first.
Designers documented every significant UX pattern, describing not just what each one looked like but how it behaved. What happens when you click A. What happens next. What's not supposed to happen. Writing for AI forced a level of rigour that made the documentation more useful for humans too.
Those descriptions became the foundational rules inside Claude Code. Any developer or PM starting a new build was already working within Prism's system from the first prompt. Connecting Claude to Figma via MCP meant live tokens and components were always available, so AI was referencing what Prism actually was today, not a months-old snapshot.
More people can now build the EcoOnline experience, not just designers. And consistency is maintained not because everyone remembered to check the docs, but because the system is embedded in the workflow itself.
Outcome
Prism is now one of the foundations of EcoOnline's platform strategy. Eight-plus products unified under a shared experience framework, with more in progress.
But the more meaningful outcome is what the system unlocked. With the design system effectively automated, designers stopped spending time on the UI layer and started spending it on work that actually moves the business forward: understanding users deeply, shaping the experiences and decisions that define the product, building differentiation that competitors can't easily copy.
A consistent design system is valuable. But the real advantage is what your designers do when they're no longer maintaining one.
Reflection
Most people assume design systems are about consistency. I think that's the wrong frame.
Consistency is a byproduct. What a design system actually gives you is speed in reaching alignment. When the foundational decisions are already made and embedded in the tools people use every day, teams spend less time debating patterns and more time solving problems that actually need solving.
That's where the leverage is. Not in the components. In everything you no longer have to argue about.
