
Global design system for health care
Tackling the needs of 14 provincial programs with 1 system
Situation
Client
Provincial Health Services Authority of British Columbia
My role
My team
3 PMs, tech lead, 5 front-end devs, creative director, content writer, PHSA and BCMHSUS stakeholders
Brief
In British Columbia, Canada, the Provincial Health Services Authority (PHSA) oversees 14 programs and institutions serving millions. Their websites faced critical challenges: outdated design, unclear information, and poor accessibility compliance.
At Evolving Web, where I worked, we were tasked with modernizing PHSA’s web presence, including 14 program sites like British Columbia Mental Health and Substance Use. To meet their diverse needs, we proposed a federated modular design system: a flexible framework to unify their platforms while allowing for program-specific customization.
Challenge
This project was exclusively comprosed of challenges, there were no easy parts. It was a daily process of ensuring UI designers, UX designers, art directors, stakeholders, PMs, more stakeholders, developers, and even more stakeholders who represent 14 provincial health organizations were continuously up to date and on board with the vision.
Other than that, it was the typical global design system challenges:
-
How do we balance consistency and flexibility across 14 programs while allowing each to maintain its unique branding and functionality?
-
How do we establish clear governance and ownership to manage the design system effectively across the programs?
-
Also, this was the first time the agency had attempted to launch an external design system.
Project process
PHSA planned to redesign all 14 of its program websites, alongside a full visual rebrand. At Evolving Web, we collaborated with stakeholders from each program to roll out these updates. I joined the project early in the ideation phase due to my experience with design systems.
The first website to be tackled was B.C. Mental Health. As a small agency, we faced an extremely compressed timeline. Ideally, I would have created a polished wireframe version of the design system first and then adapted it for each program’s branding. However, due to time constraints, I developed the design system simultaneously with the BCMHSUS wireframes, while development began in parallel to meet deadlines.

Different users, different goals, 1 system
What needs to happen and how can I do it?
This project was honestly intimidating. Up until this point, I had built design systems for software products with thousands of users—big, but manageable. This one? Millions of users, spanning multiple teams, and setting the foundation for years of development between Evolving Web and PHSA. Not my first rodeo with design systems, but definitely my first at this scale, where scalability wasn’t just a nice-to-have—it was everything.
Designer
Scaleablility
Designers need a system that adapts to 14 different brands while maintaining consistency, allowing for creative solutions without reinventing components.
Content editor
Flexibility
Content editors require a system that supports a wide range of content needs, ensuring a cohesive experience that is easy to maintain.
Business
Concise
A reusable, measurable system saves time and resources with standard components, reducing redundant work, & streamlining updates across teams.
Research & process
What needs to happen and how can I do it?
Atomic design & a component audit
Start small to go big. Brad Frost’s principles of atomic design are essential. In parallel, the team and I conducted a massive component audit across all 14 PHSA websites to determine what needed to be included in the system. We identified the core components existing across the sites to identify patterns. What would we need in the future? What can we streamline?

New Figma variables & modes
Around this time, Figma released variables and modes (though, to my disappointment, not text variables yet). I worked with the tech lead to explore how we could integrate them into development.

Governance and naming
A huge amount of time went into deciding how Figma folders, files, and pages should be structured. What about edge case components? How should we handle naming conventions? As always, naming was a highly collaborative effort that evolved throughout the project.
Working with components: Landing pages
An example of component management with variants
I created 3 landing page variations
-
Landing page A- the homepage for all PHSA sites
-
Landing page B
-
Landing page C- Child pages, pages further down the information hierarchy

Landing page B
This is for parent pages, places with high levels of information. The main navigation and hero banner image will always be under the header text.
1. These are primarily for such pages as the navigation menu items.
2. At this level, I added breadcrumbs for improved wayfinding and navigation.

Landing page C
Used for child pages that are deeper in the site map or information architecture.
-
Breadcrumbs improve wayfinding, helping users navigate back through the hierarchy.
-
At this level, child pages feature a side menu on the left third of the page, with content occupying the remaining width.
-
The side menu includes a dropdown to reveal additional levels in the information hierarchy. Given the complexity of healthcare sites, this ensures better visibility of system status while maintaining a flexible design system component.

Of course, many other template pages were included in the design system, such as event detail and listing pages, news detail and listing pages, media pages, search and search results pages, and text-based pages like terms and conditions.
Typography
Noto Sans was chosen for it's readability and scalabiliy as it can be used for the many of the indigenous languages common to the population of British Columbia.

Colours
For the most flexibility for the 14 PHSA sites without overwhelming the content editors, I decided to have:
-
11 grey colours
-
8 primary colours
-
8 secondary colours
-
8 tertiary colours
This was in collaboration with the lead developer who had a great deal of expereince with Drupal content editors.

Achieving customisation in a federated design system
How to make each of the 14 sites feel unique and highlight their brand and value proposition through colour and branded moments
Visual identity
Each of the 14 sites had its own set of primary, secondary, and tertiary colours. To help define the brand identity, the UI designer also created a collection of 8 shapes in three colours (with 5 additional shapes for wireframing purposes). B.C. Mental Health features a more natural, biophilic design to evoke a sense of calm and trust. In contrast, B.C. Children's Hospital adopts a more youthful and playful approach.
Background shapes are incorporated into brand icons, which are used in hero banners, image card collections, and avatars for biographies and testimonials.

Here are the customized brand shapes used in the design system for brand icons and avatars.
Design system components and UI elements
Deliver solutions alongside technical guidance and creative direction
It's big, so big it routinely crashed Figma.
There were hundreds of components! I was continuously trying to pare down and consolidate components. Here is a little look into the various components and variants. If you have questions about any of them, their management, or how I came to certain decisions, I welcome any messages! I can talk about this for hours.
Design system components and UI elements










Lessons learned the hard way
Technical difficulties, compromise and communication
1
Figma libraries
They are not perfect! They did not work when I needed them to and as a result I had to completely restructure how we organised the Figma files. A huge unforeseen technical challenge that took up a lot of time.
2
Design system documentation management
One of my biggest regrets was not pushing harder to use ZeroHeight for design system documentation. I wrote all the documentation, but it remained in Figma. I would have preferred a separate platform or one integrated with code blocks, but this was a compromise made between the PM and the client.
3
People management and decision documentation
Documenting product decisions is crucial in a large design system to ensure consistency, track rationale, and align teams. It prevents confusion, reduces rework, and serves as a reference for future iterations, keeping designers, developers, and PMs on the same page. (Not easy)
Takeaways
-
Communication: Collaborating across teams was crucial to align designers, developers, and stakeholders, ensuring a cohesive and widely adopted design system.
-
System-Level Thinking and Strategy: Building a scalable system required anticipating future needs, creating flexible yet structured components, and maintaining consistency across 14 sites.
-
Documentation: Clear and thorough documentation was key to driving adoption, enabling teams to implement components correctly, and ensuring long-term maintainability.
Results and next steps
1
Happy stakeholders
All stakeholders were very satisfied with the results, which are now live. For the next organization, my colleagues confirmed that the system is working very well—it’s fast, smooth, and easy to use.
2
Improved metrics
Using Google Analytics, I analyzed the data before and after the BCMHSUS website redesign, and it’s clear that the user experience has improved. Users can find information in a clear way.
3
Apply the design system to future sites and iterate
While I was still working at Evolving Web, I began work on B.C. Children's Hospital, with B.C. Cancer and B.C. Centre for Disease Control. New colour palettes and treatments will be applied.








13% Bounce rate

17% Goal completion



Pilot website in production using the design system
Here is the BCMHSUS website using the PHSA design system.
