Increasing Premera's usability and accessibility through a new Design System
Premera's Design practice and Mobile team was growing quickly, and our processes weren't keeping up. New teams were forming around SMS, Virtual Assistant, and Mobile Apps, but their features were making our core iOS and Android apps feel disjointed.
I took on building a Mobile Design System to solve three problems: create consistent design elements, improve communication across teams, and make our experiences more accessible.
Project Timeline
2018 – 2020
Role
Researcher, UX Designer, UI Designer
Impact
WCAG Level AA 2.1 Compliant
25% faster UI development
Eliminate questions about colors, typography, and iconography
Increasing Premera's usability and accessibility through a new Design System
Premera's Design practice and Mobile team was growing quickly, and our processes weren't keeping up. New teams were forming around SMS, Virtual Assistant, and Mobile Apps, but their features were making our core iOS and Android apps feel disjointed.
I took on building a Mobile Design System to solve three problems: create consistent design elements, improve communication across teams, and make our experiences more accessible.
Project Timeline
2018 – 2020
Role
Researcher, UX Designer, UI Designer
Impact
WCAG Level AA 2.1 Compliant
25% faster UI development
Eliminate questions about colors, typography, and iconography
Increasing Premera's usability and accessibility through a new Design System
Premera's Design practice and Mobile team was growing quickly, and our processes weren't keeping up. New teams were forming around SMS, Virtual Assistant, and Mobile Apps, but their features were making our core iOS and Android apps feel disjointed.
I took on building a Mobile Design System to solve three problems: create consistent design elements, improve communication across teams, and make our experiences more accessible.
Project Timeline
2018 – 2020
Role
Researcher, UX Designer, UI Designer
Impact
WCAG Level AA 2.1 Compliant
25% faster UI development
Eliminate questions about colors, typography, and iconography
Starting with research
I knew I needed to start with research to understand what the team actually needed from a Design System. I talked to Product Managers, Developers, and Designers to understand their pain points with our current design process and what they valued most about their work.
Starting with research
I knew I needed to start with research to understand what the team actually needed from a Design System. I talked to Product Managers, Developers, and Designers to understand their pain points with our current design process and what they valued most about their work.
Starting with research
I knew I needed to start with research to understand what the team actually needed from a Design System. I talked to Product Managers, Developers, and Designers to understand their pain points with our current design process and what they valued most about their work.
Research plan + interview analysis
The research revealed that everyone wanted a say in UI design. Product Managers, Developers, and Designers all felt that directly impacting the user experience was a core part of why they enjoyed their jobs. This raised a critical question. Can a Design System really support both standardization and the constant visual changes our team thrived on?
Research plan + interview analysis
The research revealed that everyone wanted a say in UI design. Product Managers, Developers, and Designers all felt that directly impacting the user experience was a core part of why they enjoyed their jobs. This raised a critical question. Can a Design System really support both standardization and the constant visual changes our team thrived on?
Research plan + interview analysis
The research revealed that everyone wanted a say in UI design. Product Managers, Developers, and Designers all felt that directly impacting the user experience was a core part of why they enjoyed their jobs. This raised a critical question. Can a Design System really support both standardization and the constant visual changes our team thrived on?
Our cross-team collaboration needed work
The Development team and Product Managers had two big concerns with a standardized system. First, they worried it would burden Developers while making my job as a Designer easier. Second, our old handoff process meant screens constantly changed as new features were designed, impacting stories Developers were already working on. There was also a lack of understanding about our current design process outside the Design team.
A Design System could actually solve these problems by establishing trust between teams while making our designs more usable.
Our cross-team collaboration needed work
The Development team and Product Managers had two big concerns with a standardized system. First, they worried it would burden Developers while making my job as a Designer easier. Second, our old handoff process meant screens constantly changed as new features were designed, impacting stories Developers were already working on. There was also a lack of understanding about our current design process outside the Design team.
A Design System could actually solve these problems by establishing trust between teams while making our designs more usable.
Our cross-team collaboration needed work
The Development team and Product Managers had two big concerns with a standardized system. First, they worried it would burden Developers while making my job as a Designer easier. Second, our old handoff process meant screens constantly changed as new features were designed, impacting stories Developers were already working on. There was also a lack of understanding about our current design process outside the Design team.
A Design System could actually solve these problems by establishing trust between teams while making our designs more usable.
Tools were working against us
Design tooling
I started by evaluating our design tools. We were already using Sketch and InVision, and health insurance security requirements meant waiting months for new tool approvals. No other tools offered compelling enough benefits to justify the switch. Instead, I implemented stricter version control through Abstract and created a Sketch Library for all components. This kept the same core process while adding the structure we needed.
Development tooling
Our development handoff tools stayed the same too. We used InVision Inspect and began testing InVision Design System Manager, tools developers already knew. But there were major gaps in our process. Components lived in DSM and our design files, but weren't connected to Inspect. Developers had to manually match properties between tools, creating the exact inefficiency we were trying to solve.
A breakthrough
Speaking with another designer led to the solution. He mentioned wanting to see styles directly in the InVision Inspect panel, and 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. This simple change gave developers all the information they needed with minimal extra effort.
Tools were working against us
Design tooling
I started by evaluating our design tools. We were already using Sketch and InVision, and health insurance security requirements meant waiting months for new tool approvals. No other tools offered compelling enough benefits to justify the switch. Instead, I implemented stricter version control through Abstract and created a Sketch Library for all components. This kept the same core process while adding the structure we needed.
Development tooling
Our development handoff tools stayed the same too. We used InVision Inspect and began testing InVision Design System Manager, tools developers already knew. But there were major gaps in our process. Components lived in DSM and our design files, but weren't connected to Inspect. Developers had to manually match properties between tools, creating the exact inefficiency we were trying to solve.
A breakthrough
Speaking with another designer led to the solution. He mentioned wanting to see styles directly in the InVision Inspect panel, and 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. This simple change gave developers all the information they needed with minimal extra effort.
Tools were working against us
Design tooling
I started by evaluating our design tools. We were already using Sketch and InVision, and health insurance security requirements meant waiting months for new tool approvals. No other tools offered compelling enough benefits to justify the switch. Instead, I implemented stricter version control through Abstract and created a Sketch Library for all components. This kept the same core process while adding the structure we needed.
Development tooling
Our development handoff tools stayed the same too. We used InVision Inspect and began testing InVision Design System Manager, tools developers already knew. But there were major gaps in our process. Components lived in DSM and our design files, but weren't connected to Inspect. Developers had to manually match properties between tools, creating the exact inefficiency we were trying to solve.
A breakthrough
Speaking with another designer led to the solution. He mentioned wanting to see styles directly in the InVision Inspect panel, and 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. This simple change gave developers all the information they needed with minimal extra effort.
Building the visual foundation
With our tooling sorted, I focused on establishing the core visual elements. The Development team and Product Managers already had concerns about standardization, so I needed to prove the system's value early. I started with the fundamentals that would have the biggest impact on consistency: color, typography, and iconography.
These foundational elements addressed the team's main worries about burden and constant changes by creating a shared language everyone could reference. Instead of screens changing arbitrarily, updates would follow clear principles that made sense to both designers and developers.
Colors
Typography: Android + iOS
Iconography
Building the visual foundation
With our tooling sorted, I focused on establishing the core visual elements. The Development team and Product Managers already had concerns about standardization, so I needed to prove the system's value early. I started with the fundamentals that would have the biggest impact on consistency: color, typography, and iconography.
These foundational elements addressed the team's main worries about burden and constant changes by creating a shared language everyone could reference. Instead of screens changing arbitrarily, updates would follow clear principles that made sense to both designers and developers.
Colors
Typography: Android + iOS
Iconography
Building the visual foundation
With our tooling sorted, I focused on establishing the core visual elements. The Development team and Product Managers already had concerns about standardization, so I needed to prove the system's value early. I started with the fundamentals that would have the biggest impact on consistency: color, typography, and iconography.
These foundational elements addressed the team's main worries about burden and constant changes by creating a shared language everyone could reference. Instead of screens changing arbitrarily, updates would follow clear principles that made sense to both designers and developers.
Colors
Typography: Android + iOS
Iconography
Components were the real challenge
This phase was the most difficult. We had styling and familiar tools, but components were entirely new. Building, integrating, and communicating them required a different approach.
I started by creating components from existing app elements. Designers used them, but developers couldn't access component attributes through InVision Inspect, leading to inconsistent UI across features. Meeting more frequently with developers helped generate excitement but didn't increase component usage since the elements weren't truly systematized.
Without Design System Manager, I needed a new solution. I turned to Confluence to document our principles and core components. The tool wasn't built for design systems, but it might help establish the foundation we needed.
Components were the real challenge
This phase was the most difficult. We had styling and familiar tools, but components were entirely new. Building, integrating, and communicating them required a different approach.
I started by creating components from existing app elements. Designers used them, but developers couldn't access component attributes through InVision Inspect, leading to inconsistent UI across features. Meeting more frequently with developers helped generate excitement but didn't increase component usage since the elements weren't truly systematized.
Without Design System Manager, I needed a new solution. I turned to Confluence to document our principles and core components. The tool wasn't built for design systems, but it might help establish the foundation we needed.
Components were the real challenge
This phase was the most difficult. We had styling and familiar tools, but components were entirely new. Building, integrating, and communicating them required a different approach.
I started by creating components from existing app elements. Designers used them, but developers couldn't access component attributes through InVision Inspect, leading to inconsistent UI across features. Meeting more frequently with developers helped generate excitement but didn't increase component usage since the elements weren't truly systematized.
Without Design System Manager, I needed a new solution. I turned to Confluence to document our principles and core components. The tool wasn't built for design systems, but it might help establish the foundation we needed.
Documentation became the key to adoption
Confluence turned out to be exactly what we needed. Starting with basic components like buttons, links, and inputs helped establish obviously consistent elements. Principles around spacing, icon design, and content effectively communicated our design decisions while keeping the team accountable.
Most importantly, governance became the catalyst for building a real system that everyone contributed to. As the visual design evolved for accessibility and brand consistency, other designers wanted more agency in creating components. We established regular meetings to discuss how to build out the system more effectively.
This was critical. I could create components all day, but if designers weren't interested in using them, the effort was pointless. The team saw the system's value and wanted to help make it better.
Documentation became the key to adoption
Confluence turned out to be exactly what we needed. Starting with basic components like buttons, links, and inputs helped establish obviously consistent elements. Principles around spacing, icon design, and content effectively communicated our design decisions while keeping the team accountable.
Most importantly, governance became the catalyst for building a real system that everyone contributed to. As the visual design evolved for accessibility and brand consistency, other designers wanted more agency in creating components. We established regular meetings to discuss how to build out the system more effectively.
This was critical. I could create components all day, but if designers weren't interested in using them, the effort was pointless. The team saw the system's value and wanted to help make it better.
Documentation became the key to adoption
Confluence turned out to be exactly what we needed. Starting with basic components like buttons, links, and inputs helped establish obviously consistent elements. Principles around spacing, icon design, and content effectively communicated our design decisions while keeping the team accountable.
Most importantly, governance became the catalyst for building a real system that everyone contributed to. As the visual design evolved for accessibility and brand consistency, other designers wanted more agency in creating components. We established regular meetings to discuss how to build out the system more effectively.
This was critical. I could create components all day, but if designers weren't interested in using them, the effort was pointless. The team saw the system's value and wanted to help make it better.
Success led to continued investment
By the end of my time at Premera, I was regularly meeting with designers and developers to define scalable components including buttons, inputs, navigation lists, search, and many more. The system's success led Premera to hire an additional dedicated design systems designer after I left.
Results
The apps met WCAG Level AA 2.1 accessibility standards with stricter standards where possible
Questions about colors, typography, and iconography virtually stopped as the team used design tokens and shared terminology
Visual design and UI development completed about 25% faster, with similarly sized projects requiring fewer story points
What worked
Created standardized and consistent patterns for mobile app users
Made our apps more accessible and increased usability
Streamlined the design and development handoff process
Added more intentionality to our design patterns
Areas for improvement
Prove the importance and value of a design system earlier
Involve developers from the beginning of the process
Communicate how components are built sooner to designers
Be more patient with adoption, teams are slow to change regardless of industry buzz
Success led to continued investment
By the end of my time at Premera, I was regularly meeting with designers and developers to define scalable components including buttons, inputs, navigation lists, search, and many more. The system's success led Premera to hire an additional dedicated design systems designer after I left.
Results
The apps met WCAG Level AA 2.1 accessibility standards with stricter standards where possible
Questions about colors, typography, and iconography virtually stopped as the team used design tokens and shared terminology
Visual design and UI development completed about 25% faster, with similarly sized projects requiring fewer story points
What worked
Created standardized and consistent patterns for mobile app users
Made our apps more accessible and increased usability
Streamlined the design and development handoff process
Added more intentionality to our design patterns
Areas for improvement
Prove the importance and value of a design system earlier
Involve developers from the beginning of the process
Communicate how components are built sooner to designers
Be more patient with adoption, teams are slow to change regardless of industry buzz
Success led to continued investment
By the end of my time at Premera, I was regularly meeting with designers and developers to define scalable components including buttons, inputs, navigation lists, search, and many more. The system's success led Premera to hire an additional dedicated design systems designer after I left.
Results
The apps met WCAG Level AA 2.1 accessibility standards with stricter standards where possible
Questions about colors, typography, and iconography virtually stopped as the team used design tokens and shared terminology
Visual design and UI development completed about 25% faster, with similarly sized projects requiring fewer story points
What worked
Created standardized and consistent patterns for mobile app users
Made our apps more accessible and increased usability
Streamlined the design and development handoff process
Added more intentionality to our design patterns
Areas for improvement
Prove the importance and value of a design system earlier
Involve developers from the beginning of the process
Communicate how components are built sooner to designers
Be more patient with adoption, teams are slow to change regardless of industry buzz