Native product design × accessibility × systems
Making accessibility structural across two mature healthcare apps.
I first led an accessibility-focused rewrite of more than 400 BCBS FEP iOS and Android screens in Axure. I later led a separate migration into Figma and Storybook—building on the rewrite rather than treating both efforts as one project.
Outcome proof
- 400+
- iOS and Android screens rewritten
- ~150
- reusable native components carrying accessible decisions
- Less rework
- fewer downstream bugs, remediation cycles, and sprint time
The opportunity
Accessibility had to become part of the product—not another layer of fixes.
The rewrite covered more than 200 screens in iOS and another 200+ in Android. The immediate need was accessibility remediation, but fixing issues screen by screen would have created a new consistency problem at enormous scale.
The challenge was to improve accessibility while preserving coherent interaction patterns across two native platforms, each with its own behaviors, conventions, and implementation constraints.
Project chronology
- 01Native rewrite in Axure
Accessibility remediation across 400+ iOS and Android screens, supported by roughly 150 reusable native components.
- 02Later migration to Figma
Atomic structure expanded across the apps and member dashboard, with Storybook aligning design and production code.
What I led
During the native rewrite, I led one designer and two developers within a five-person team, creating two accessibility-first systems and roughly 150 reusable components. In the later migration, I introduced atomic structure, expanded the system across app and web experiences, and led Storybook adoption to align design and production code. Together, the two phases substantially reduced remediation, bugs, and sprint time spent addressing accessibility-related technical debt.
The idea
Make the accessible decision the reusable decision.
Rather than correcting the same problems screen by screen, we encoded contrast, hierarchy, component behavior, spacing, and usage guidance within each app’s design system.
How might accessibility survive across 400+ native screens, future features, and the teams responsible for building them?
Accessibility by design
Accessibility became a product constraint, not a final review step.
The work incorporated accessibility expectations directly into the design language: contrast requirements, component guidance, practical usage rules, and repeatable patterns that could be applied across hundreds of screens. That shifted accessibility from screen-level remediation toward a more durable system-level practice.
Building the systems
Two native systems encoded accessible behavior at the component level.
Axure was the primary design tool for the app rewrite. Within that work, we created roughly 150 reusable components across the two systems and documented anatomy, states, spacing, and behavior so each native app could remain coherent across more than 200 screens.
Systems in action
Accessible patterns carried into real member journeys.
The product practice mattered most when members moved through complex healthcare tasks.
The rewritten apps supported very different member needs—from home and account experiences to care discovery and claims. Within each platform, consistent component logic, spacing, hierarchy, and accessibility expectations created continuity while respecting native behavior.
What came next
The app rewrite became the foundation for a later Figma migration.
After the native rewrite shipped, I led a separate migration from Axure into Figma. This second phase translated the earlier foundations into an atomic system, expanded the work beyond the apps to experiences including the member dashboard, and introduced Storybook alignment between design and code. It continued the system thinking established in Phase 1, but it was not part of the same delivery.
Scale + impact
Accessibility moved upstream—from recurring remediation to product practice.
Embedding accessibility within reusable components made accessible decisions more repeatable across two large native applications. It also substantially reduced downstream bugs, remediation work, and sprint time spent addressing accessibility-related technical debt.