Creating an Inclusive Design System for Healthcare Operations
Adopting an open-source framework to create components and documentation for CoverMyMeds' electronic prior authorization platform.
Adopting an open-source framework to create components and documentation for CoverMyMeds' electronic prior authorization platform.
Role
Team
UX Activities
CoverMyMeds is a McKesson healthcare technology company that specializes in electronic prior authorization (ePA) solutions. Their digital platform helps automate arduous PA forms and facilitates better coordination between providers, pharmacists, and payers to get patients their medication faster.
When CoverMyMeds approached us for help, their UX team was siloed across embedded product teams, which had created disjointed experiences in the PA platform. We investigated how to achieve better cohesion between their design and engineering teams, ultimately creating a centralized design system to facilitate collaboration and guide their perspective on product design.
Discovery
After McKesson acquired the company in 2017, CoverMyMeds underwent changes that unintentionally deteriorated cross-functional collaboration and prolonged release cycles. Myself and a design peer facilitated a series of group interviews with the UX, engineering, and product teams to uncover the root of these problems:
Definition
CoverMyMeds knew the legacy design system needed replaced and expressed interest in one that could bring efficiency, consistency, and reusability to the product development process. A previous attempt at a centralized design system, called the “Design System Language,” was obsolete and limited. I led the audit of the design system to expose its weaknesses:
Technical Assessment
At this time, a separate engineering effort to consolidate frameworks revealed an opportunity to start building the design system. I met with a small group of their product and engineering leads to discuss implementation tactics, ultimately aligning on adopting a React-based framework.
After reviewing several options, I recommended using IBM's Carbon Design System for its deep library of components, detailed documentation, and out-of-the-box accessibility features that would be in closer compliance with healthcare policies.
Organization
To make the design system look and work better for CoverMyMeds, we customized styles to refine the product language using cascading design tokens for easier maintenance. I also introduced a system of interlocking components using "base" and "core" structures, allowing single base edits to cascade across all core components, speeding up design time.
Customization
Although Carbon comes baked with accessibility in mind, requirements for digital healthcare products are much stricter. I conducted a visual accessibility audit before modifying specific UI elements to follow UX best practices and healthcare usability policies.
We built the components prototype-ready so that anyone could test their ideas, not just designers. I worked in Figma to simplify component variants, leveraging features such as booleans, nesting, and instance simplification to make components easier to use.
Documentation
Once my team had a foundation of components and documentation, we solicited feedback from CoverMyMeds employees. The extensive documentation initially overwhelmed participants, prompting us to streamline it.
I was responsible for creating various resources to accommodate different learning styles, including written content and interactive Figma activities. I made video tutorials to onboard employees and voiceover new product and design principles.
Implementation
We gradually released components to the UX team, eventually supporting ScriptHero, CoverMyMeds' first patient-facing product for prescription discount cards.
I worked together with ScriptHero's product manager and engineer, as well as another CoverMyMeds designer, to unravel technical complexity and make a plan for how to implement the new design system. To get started, we integrated a couple essential components into the UI and planned iterative cycles for further integration. I created designs for the future full experience in order to guide refinement of the product.
Component Design
Many of the atomic Figma components are built with states and interactions baked in, meaning anyone from the product organization can leverage the library to quickly test ideas without needing prototyping skills.
Some of the educational resources I created for the documentation library are activity-based, giving anyone the ability to practice using the design system with simple prototyping tutorials.
Product Language
The new Carbon-based design system pulls the same terms for styles from developer documentation to close the gap in communication between engineers and designers.
The semantically-named design tokens use labels such as $danger and $text-primary to reduce ambiguity in implementation, ensuring solutions across different product teams follow similar conventions.
User Experience
I no longer endorse using base components to this extent. Although practical in some cases, using base components to build components complicates layers and variants. It also bloats file size due to increased memory consumption.