Design systems & enablement at scale
company
Doctor Anywhere
time
'23/'24
Role
Product Design
Keywords
#design system #scaling design #design leadership #org design
Building the system that helped Doctor Anywhere scale design across products, brands, and teams
Gravity started from a pattern I could see becoming bigger every quarter.
Doctor Anywhere was growing fast. What began as a telehealth-first experience was expanding into a much broader healthcare ecosystem - new products, new user journeys, new partner experiences, and increasingly more white-label requirements across B2B and B2C.
The ambition of the company was evolving quickly. The way we designed was not evolving at the same pace.
As new initiatives launched, teams were solving similar UI problems repeatedly across different products. Separate Figma files existed for different brands and platforms, interaction patterns were starting to drift, and every white-label request introduced more operational complexity than it should have.
At first glance, this could easily be described as a consistency problem.
But to me, the bigger issue was much more strategic. This was an early signal that our design operations would not scale with the business. The cost wasn't only visual inconsistency. It was the growing amount of time teams spent maintaining, recreating, and aligning work that should already have been systemized.
I saw Gravity as an opportunity to solve that at the root.
Not by creating another UI library, but by establishing the first multi-brand, cross-platform design system that could become shared infrastructure for the company.
Building the foundation before the organisation felt the pain fully
The system started as an initiative I drove myself. In the early phase, my focus was on defining the foundations clearly enough so the system could support the scale we knew was coming: multiple brands, multiple product surfaces, multiple teams, and a growing white-label business.
A key principle from the start was that this could not become a "designer-only tool".
If Gravity stayed as a Figma library, it would solve local design problems but not the bigger organisational challenge.
So I intentionally positioned it as something larger: a shared framework for how Doctor Anywhere designs, builds, and evolves experiences.
That mindset shift became one of the most important parts of the work.
The challenge was less about creating components, and more about helping teams understand that the design system was directly connected to:
delivery speed
implementation quality
scalability of white-label work
long-term maintainability
accessibility
brand consistency
This was where a lot of my leadership effort went: creating alignment early enough that adoption could happen naturally as the system matured.
Evolving from individual craft into a scalable team capability
One of the most meaningful parts of this journey for me was how my role evolved alongside the maturity of the system.
Gravity began with my direct contribution and hands-on foundation work.
But as adoption increased, it became clear that the next challenge was not system quality alone. It was organisational scalability.
To make Gravity sustainable, I hired and led a small UI team, bringing in two strong designers and shaping the team into a horizontal function that could support both our B2C and B2B streams.
This became an important shift in our design operating model.
Instead of product teams solving visual consistency locally, we now had a shared layer focused on:
system evolution
reusable patterns
accessibility standards
white-label scalability
design QA quality
My role became defining the roadmap, helping the team prioritise where the system could unlock the most leverage, and creating the conditions for them to become increasingly autonomous.
That transition - from sole driver to building a strong team layer around the capability - is something I'm particularly proud of.
It reflects how I like to lead: start by proving the value through execution, then scale it through people and structure.
Using Gravity to align brand and product around a bigger company shift
One of the most strategic moments in this work came when the company's brand direction began evolving.
Doctor Anywhere was moving from being strongly associated with virtual consultations into a broader healthcare and lifestyle platform.
That shift needed to feel coherent everywhere: inside the product, across B2B experiences, and in marketing touchpoints.
I worked closely with the marketing team to redefine the visual language so it could support this broader brand ambition.
This wasn't just a visual refresh. It was about ensuring the system could express a more mature healthcare brand while still staying practical for product teams to use at scale.
Accessibility became a key design principle here. We introduced a new accessible colour system and UI foundations that aligned with WCAG standards, making the product feel more modern while also improving usability across all user groups.
This was one of the strongest examples of how Gravity became a bridge between:
product design
brand evolution
accessibility
implementation realities
Rather than letting those streams evolve separately, the system gave them one shared language.
Simplifying scale through tokenization
A major unlock came from centralising the system through a token-based library.
Before this, supporting multiple brands meant maintaining parallel files and making repetitive updates across systems. That model simply wouldn't scale.
By moving to a centralised tokens-based architecture, we dramatically simplified how teams worked across brands and platforms. A single update could now cascade consistently across multiple product surfaces.
This was especially powerful for white-label work. The time required to create or update branded experiences reduced significantly, and the cognitive load on teams dropped with it.
But for me, the most important outcome was what this unlocked creatively. Teams could spend less time rebuilding UI foundations and more time focusing on the actual user problems we were trying to solve.
That shift in energy - from maintenance to problem solving - is where the real business value of systems work shows up.
Impact
The most measurable outcome was a ~30% improvement in design efficiency.
But the more important impact was what changed culturally.
Gravity helped establish a shared understanding that design quality, accessibility, speed, and brand consistency should not depend on individual teams reinventing solutions.
It improved:
consistency across products and brands
speed of white-label implementations
collaboration between B2B and B2C teams
design QA efficiency
implementation confidence
long-term maintainability
Most importantly, it changed the role design played in the company. Instead of being seen primarily as a function that creates outputs, design became a function that creates systems for scale.
That shift in perception is what made Gravity much bigger than a design system initiative. It became a foundational layer for how the organisation builds.
The work was also recognised externally. Figma featured Doctor Anywhere as a customer story, highlighting how Gravity enabled the team to design healthcare experiences faster. Read the Figma feature →
Reflection
What I value most about Gravity is that it represents the kind of design leadership I care deeply about.
Not just improving the quality of what gets shipped today, but building the foundations that make the next 50 decisions better.
The work required systems thinking, stakeholder alignment, team building, and knowing when to stay hands-on versus when to scale through others.
For me, this project is one of the clearest examples of how design leadership can create leverage far beyond the design team itself.
It's where design became not just a craft discipline, but a multiplier for the business.
Next Projects
