Premera Blue Cross

Researcher, UX Designer, UI Designer · 2018–2020 · Healthcare / Design Systems / Accessibility / Mobile

Premera's Design practice and Mobile team were growing quickly, and our processes weren't keeping up. I built a Mobile Design System to solve three problems: create consistent design elements, improve communication across teams, and make our experiences more accessible.

Results

WCAG AA 2.1

Accessibility standards met

25%

Faster UI development

Dedicated DS designer hired after departure

Legacy

The result

The Premera mobile app rebuilt with the new design system’s components and styling.

Premera mobile app screens showing the Home, Health, and Costs sections rebuilt with the new mobile design system

Read the case study

Starting with research

I talked to Product Managers, Developers, and Designers to understand what the team actually needed from a design system. I wanted to know what frustrated them about our current process and what they valued most about their work.

Everyone wanted a say in UI design. PMs, developers, and designers all felt that directly shaping the user experience was part of why they liked their jobs. That raised a real question: could a design system support standardization without taking that ownership away?

Two concerns came up repeatedly from developers and PMs. First, they worried a design system would burden developers while making the designer's job easier. Second, our handoff process was chaotic: screens kept changing as new features were designed, disrupting stories developers were already working on. A system could actually solve both problems by creating stability and a shared language between teams.

Research plan and interview analysis

Cross-team collaboration diagram mapping pain points between design, development, and product management

Cross-team pain points surfaced in research

Our tools were working against us

We were already using Sketch and InVision. Health insurance security requirements meant waiting months to get new tools approved, so I worked with what we had. I implemented stricter version control through Abstract and created a Sketch Library for all components.

Handoff was still broken. We used InVision Inspect and started testing InVision Design System Manager, but components lived in DSM and our design files without being connected to Inspect. Developers had to manually match properties between tools, which was exactly the kind of inefficiency we were trying to eliminate.

Sketch component library showing design system components organized in Abstract for version control

Design tooling: Sketch + Abstract

InVision Inspect panel showing the gap between component attributes in DSM and what developers could access

Development tooling: InVision Inspect

A fix hiding in layer naming

A designer on the team mentioned wanting to see styles directly in the InVision Inspect panel. I realized I could make that happen through better layer naming. Instead of generic names like Title_copy 3, I started using Title/Body Semibold/Brand-3. Developers got all the information they needed from the layer name with no extra work on either side.

With tooling sorted, I focused on the foundational elements that would have the biggest impact on consistency: color, typography, and iconography. Getting these right first gave the team a shared language to reference, which addressed the biggest worry about burden and constant churn.

Before and after comparison of Sketch layer naming conventions, showing generic names replaced with semantic token-based names

Layer naming convention before and after

Premera color system showing accessible color scales for the mobile design system

Color system for mobile

Components were harder

I built components from existing app elements and designers started using them, but developers couldn't access component attributes through InVision Inspect. The result was inconsistent UI across features even when designers were using the right components.

Without a proper design system manager solution, I turned to Confluence to document our principles and core components. It wasn't built for design systems, but it gave us a place to establish the foundation.

Typography scale for Android and iOS showing type styles across both platforms

Typography: Android + iOS

Iconography system

Component library

Documentation drove adoption

Confluence worked better than I expected. Starting with obviously consistent elements like buttons, links, and inputs made the value tangible. Principles around spacing, icon design, and content gave the team something concrete to reference and hold each other accountable to.

Governance became the catalyst for broader buy-in. As the visual design evolved for accessibility and brand consistency, other designers wanted more agency in creating components. We set up regular meetings to work through how to build out the system together. The team saw the value and wanted to contribute.

By the time I left, I was regularly working with designers and developers to define scalable components: buttons, inputs, navigation lists, search, and more. Premera hired a dedicated design systems designer after I left to continue the work.

Confluence documentation page showing design system principles and component guidelines

Design system documentation in Confluence

Reflection

The apps met WCAG Level AA 2.1 accessibility standards. Questions about colors, typography, and iconography virtually stopped once the team had design tokens and shared terminology. Visual design and UI development moved about 25% faster.

Learnings

01Prove the value of a design system earlier rather than waiting for adoption to happen organically
02Involve developers from the start of the process, not after the design decisions are made
03Communicate how components are built sooner so designers can contribute meaningfully
04Be patient with adoption. Teams are slow to change regardless of how obvious the value seems