Skip to main content

Premera Blue Cross

  • Healthcare
  • Design Systems
  • Accessibility
  • Mobile

Premera's design practice and mobile team were growing faster than our processes were. I built a mobile design system to do three things: make our design elements consistent, fix communication between teams, and bring the apps up to accessibility standards.

Scope

Role

Product Designer

Team

3 Engineering Teams 3 PMs 1 Product Director

Timeline

Jan 2019–Dec 2019

Results

WCAG 2.1 AA

Accessibility standards met

25%

Faster UI development

Dedicated design systems designer hired after I left

Compared to Legacy

Starting with research

I talked to product managers, developers, and designers to find out what the team actually needed from a design system, what frustrated them about how we were working, and what they valued most about their own jobs.

Everyone wanted a say in UI design. PMs, developers, and designers all felt that shaping the experience directly was part of why they liked the work. That raised the question the whole project turned on: could a system standardize without taking that away from people?

Two concerns came up again and again. Developers and PMs worried a design system would shift work onto developers while making the designer's job easier. And handoff was chaotic, with screens changing as new features were designed, which disrupted stories developers had already started. A system could actually solve both by creating stability and a shared language between the teams.

Research plan and interview analysis

Cross-team pain points surfaced in research

Our tools were working against us

We were on Sketch and InVision. Health insurance security requirements meant new tools took months to get approved, so I worked with what we had. I set up stricter version control through Abstract and built a Sketch Library for all the components.

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

Design tooling: Sketch File

Development tooling: InVision Design Systems Manager

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 get there through better layer naming. Instead of Title_copy 3, I started using Title/Body Semibold/Brand-3. Developers got everything they needed from the layer name, with no additional work on either side.

Layer naming convention to support handoff

Foundations before components

With tooling sorted I focused on the elements that would have the biggest impact on consistency: color, typography, and iconography. Getting those right first gave the team a shared language to reference, which addressed the two worries from research directly.

Accessibility went into the foundations rather than being checked at the end. The color scales were built to hold contrast across the full range rather than passing at a few specific pairings, and the type scale carried across both Android and iOS.

Color system for mobile

Typography: Android + iOS

Iconography system

Components were harder

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

Without a real design system manager, I turned to Confluence to document our principles and core components. It isn't built for design systems, but it gave us somewhere to put the foundation.

Before: inconsistent button and link styling across screens

After: one standardized button

Documentation drove adoption

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

Design system documentation in Confluence

Governance was what actually got buy-in

As the visual design evolved for accessibility and brand consistency, other designers wanted more agency in creating components. Rather than treat that as a threat to consistency, we set up regular meetings to work through how to build the system together.

That answered the question from research. The system didn't take UI ownership away from people, it gave them a defined way to exercise it. By the time I left I was regularly working with designers and developers to define scalable components: buttons, inputs, navigation lists, search, and more.

Tracking success

The apps were checked by a third party and met WCAG 2.1 AA. Visual design and UI development moved about 25% faster. Questions about color, typography, and iconography effectively stopped once the team had tokens and shared terminology, which was the change people noticed day to day even though it isn't a number.

But I waited too long to prove the value. I treated adoption as something that would happen once the system was good enough, when the faster path was to demonstrate the value of something small and visible early.

Where it stands

Premera hired a dedicated design systems designer after I left to continue the work.

The governance model is the part that carried forward for me personally. A year later at Buy with Prime I proposed a federated contribution model to a much larger team, and the argument I made there was the one I learned here: people are more willing to get behind what they contributed to.