top of page

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 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.

  1. Breadcrumbs improve wayfinding, helping users navigate back through the hierarchy.

  2. At this level, child pages feature a side menu on the left third of the page, with content occupying the remaining width.

  3. 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.

Screenshot 2025-03-17 at 8.03.01 PM.png

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

  1. Communication: Collaborating across teams was crucial to align designers, developers, and stakeholders, ensuring a cohesive and widely adopted design system.

  2. System-Level Thinking and Strategy: Building a scalable system required anticipating future needs, creating flexible yet structured components, and maintaining consistency across 14 sites.

  3. 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

bottom of page