SummaCare Design System

The Problem

SummaCare's Plan Central product hadn't been meaningfully updated since it was built in 1997. For 27 years, it had been maintained by ASP.NET developers with no design support—functionality worked, but the user experience was a disaster.

The product was developer-led with no design system, no consistency, and no accessibility standards. Buttons looked different on every page. Colors and spacing were inconsistent. Basic interactions like tabs and buttons didn't work properly. It took 11 screens just to view your claims—on a product designed primarily for viewing claims.

The Stakes:

Brokers and members were complaining - The interface was confusing and outdated
Customer service was overwhelmed - Members called for help with basic tasks they should have been able to do themselves
Accessibility violations everywhere - Color contrast issues, missing alt text, broken screen reader support
Brand inconsistency across products - Plan Central, SummaCare's website, and mobile app all looked and behaved differently
Technical debt from 1997 - ASP.NET codebase maintained by developers who hadn't built anything new in years

The Challenge

This wasn't just building a design system—it was modernizing a 27-year-old healthcare product used by the largest hospital system in the Akron area (4 hospital sites, hundreds of private practice offices) while working with a development team that had been maintaining legacy code since 1997.

Constraints:

No design precedent - SummaCare had never had designers on staff. Everything was built by developers focused solely on functionality.
Legacy ASP.NET codebase - Developers hadn't built new features in years, only maintained what existed
No accessibility knowledge - Team had never tested for WCAG compliance or used screen readers
Inconsistent brand - Marketing owned the brand but had little design system experience, resulting in inconsistency across products
Healthcare compliance requirements - Had to meet WCAG AA standards for patient-facing healthcare products
Building while redesigning - Couldn't pause Plan Central redesign to build the system, had to do both in parallel

The Approach

I approached this in a few phases:

Phase 1: Audit and Documentation

Audited Plan Central, SummaCare's website, and mobile app to identify inconsistencies and defects
Documented 3,100 defects across all digital products (849 in Plan Central alone)
Identified repeating patterns and interaction problems (11-screen flows, broken buttons, inconsistent navigation)
Established WCAG AA as the minimum accessibility standard

Phase 2: Build & Accessibility

Built 1,100+ components covering all SummaCare patterns
Introduced the team to WCAG standards and tested every component with screen readers
Built accessibility into every component from the start (proper contrast, alt text, keyboard navigation, ARIA labels)
Created design tokens for colors, typography, and spacing to ensure brand consistency across products

Phase 3: Rollout & Adoption

Rolled out to Plan Central immediately as the pilot product
Trained developers on using design system components in ASP.NET
Documented each component with accessibility requirements and implementation specs
Established the system as the standard for all future SummaCare product development

The Solution:

I designed a comprehensive design system with three core layers.

1. Component Library (1,100+ Components)

Built a library covering every SummaCare pattern—from basic buttons and inputs to complex healthcare-specific components like claims tables, member dashboards, and broker workflows. Each component was built with WCAG AA accessibility standards from the ground up.

Key Decision: Audited the existing 27-year-old product first to understand which patterns were most-used and where the biggest defects existed. This ensured the design system solved real problems, not just theoretical ones.
‍
2. Accessibility & WCAG Compliance

Introduced WCAG standards to a team that had never tested for accessibility. Every component was built with proper color contrast, alt text, keyboard navigation, and screen reader support. Tested each component with actual screen readers to ensure compliance.

‍Key Decision: Made accessibility non-negotiable from day one. Rather than "fix it later," we built every component to WCAG AA standards and tested with screen readers before marking it as complete. This eliminated the need to retrofit accessibility later.
‍
3. Documentation & Developer Handoff

Documented every component with usage guidelines, interaction states, accessibility requirements, and ASP.NET implementation specs. This was critical for a development team that had been maintaining legacy code for years and needed clear guidance on how to implement modern design patterns.

‍Key Decision: Documented components specifically for developers unfamiliar with modern design practices. Each component included visual specs (spacing, colors, typography) plus detailed implementation notes (HTML structure, ARIA attributes, keyboard interactions) to bridge the gap between 1997-era ASP.NET and modern UI standards.

The Outcome

What Shipped:

1,100+ component design system
Full Figma library with accessibility documentation
WCAG AA compliance across all components
Comprehensive developer handoff specs for ASP.NET implementation
Adopted by Plan Central and established as standard for all future SummaCare products

Impact:

Documented 3,100 defects across SummaCare's digital products (849 in Plan Central alone)
17% reduction in customer service calls - Members could complete basic tasks without calling for help
Achieved WCAG AA compliance - Brought accessibility standard from essentially zero to AA, with AAA as the next target
Broker and member satisfaction improved - Surveys praised the new design for clarity and ease of use
100% Plan Central adoption - Immediately adopted for Plan Central redesign, now standard for all SummaCare products

View the complete design system in Figma

Reflection

The biggest challenge wasn't building the components—it was introducing modern design and accessibility practices to a team that had been maintaining a 27-year-old codebase with zero design support.

I learned that you can't just hand developers a design system and expect adoption. I had to educate them on why accessibility mattered (not just compliance, but real users with real needs), how to test with screen readers, and what modern UI patterns looked like. The documentation became as important as the components themselves.

If I could do it again, I'd involve developers even earlier in the audit phase. They knew the ASP.NET codebase intimately and could have identified technical constraints sooner—like which components would be hardest to implement in legacy code. That knowledge would have helped me prioritize which components to build first.

The system's success came down to meeting the team where they were. Rather than forcing them to learn Figma or modern design tools, I documented everything in a way that translated directly to their ASP.NET workflow. That made adoption feel achievable, not overwhelming.