Refining a Consumer
Design System

Senior Product Designer

Overview

The internal platform was originally designed to manage consumer eligibility, card fulfillment, and account data. Over time, lack of design ownership led to a fragmented UI, misaligned patterns, and inaccessible forms. Design debt accumulated across products, creating friction for end users and inefficiencies for product teams. This project focused on modernizing the design system to bring clarity, WCAG compliance, scalable structure, and long-term maintainability across the ecosystem.

Apple display screen with an image of a billing website

My role and responsibilities

I led the redesign of the design system from the ground up. My responsibilities included conducting a full system audit, defining accessibility-first foundations, and leading the rebuild of core components like forms and feedback patterns. I partnered closely with engineering and QA to validate components across viewports and assistive technologies. I also created documentation, supported async onboarding, and facilitated cross-team adoption and feedback loops.

The Challenge

The legacy system was inherited from a branding agency and lacked product-level use validation. Components were inconsistently applied, difficult to maintain, and didn’t meet accessibility standards. Designers created workarounds, developers rebuilt UIs from scratch, and QA flagged avoidable issues late in the release cycle. The lack of system governance, structure, and guidance made consistent product delivery unsustainable.

Design Process

Audit and evaluation

I audited every design token, pattern, and component, comparing the agency deliverables to live product usage. I cross-referenced findings with accessibility standards and usage analytics. I collaborated with product teams to understand which components added value and which created confusion.

My role

I conducted the audit, synthesized insights, and built a prioritized roadmap for system rationalization.

Key takeaways

  • 40% of components had no clear use case
  • Overlapping visual styles introduced friction for dev handoff
  • Color palette and type scale failed WCAG minimum contrast standards

Accessibility and foundation refinement

I rebuilt foundational components to meet WCAG 2.1 AA guidelines, including form fields, buttons, modals, and focus states. I collaborated with QA to validate accessibility using screen readers and keyboard testing. I also created usage guidance to ensure consistent implementation.

My role

I defined accessibility specs, rebuilt base components, and co-led testing across products.

Key takeaways

  • Forms lacked semantic labeling, visible error states, and keyboard support
  • Color contrast required redesign for light and dark themes
  • Focus rings were either missing or non-compliant across multiple elements

Deep Dive into Message Component

Problem

The original alert pattern bundled all message types into a single, ambiguous component. There were no rules for tone, structure, or interaction. Teams improvised with banners, toasts, and inline messages—often skipping accessibility needs like screen reader support or dismiss behavior.

My role

I reviewed product feedback, mapped use cases, and defined a modular system for message delivery.

Design process

I grouped message patterns into a clear taxonomy: inline alerts, toasts, and banners, based on urgency and screen placement. I worked with PMs to understand business-critical use cases (e.g., payment errors vs. passive tips) and ensured messages supported appropriate behavior for screen readers and keyboard users.

Building the component

I built scalable Figma components using variants and properties, ensuring ease of use for designers and parity with frontend implementation.

I used Figma variants and properties to make alert creation and ensure consistency. Each property mirrored a logic state in code, reducing QA churn. I also documented usage dos/don'ts and rolled out templates that guided teams toward correct usage without needing training.

  • Severity variants: Success, Error, Warning, Info, each with distinct color, iconography, and tone.
  • Icon toggle: Ability to show or hide the leading icon depending on context.
  • Dismiss functionality: Optional close icon with customizable onDismiss behavior.
  • Layout flexibility: Support for inline vs. full-width vs. stacked toast placement.
  • Content slots: Headline, body text, and optional action link/button.

Design process

I reviewed over 20 use cases from 5 products and categorized messages by severity, persistence, and screen context. This informed the taxonomy for system alerts (e.g., toast, inline, banner). I aligned with PMs and engineers on expected behaviors, fallback states, and interaction rules before finalizing the system.

I used Figma variants and component properties to make this system intuitive for designers to use and developers to implement. Properties included:

  • Type: (Success / Error / Warning / Informative / Neutral)
  • Device: (Desktop / Mobile)
  • With icon: (Toggle On/Off)
  • Dismissible: (Toggle On/Off)
  • Content layout: (Header / Body Text / With CTA / CTA Position)

Key decisions and limitations

I scoped toast stacking to preserve clarity on small viewports and worked with developers to ensure dismiss actions restored focus for screen readers. I also defined limits on content length and layout behavior to ensure flexibility without creating dev complexity or breaking localization.

Outcome

The message component was adopted across multiple teams within weeks. It reduced QA issues tied to alerts, standardized toast behavior, and saved time in both design and dev cycles. It also became a reference for how to build other modular components.

Impact

+85%
design system adoption across 5 product teams
-75%
redundant or conflicting components removed
+40%
faster delivery via reduced QA/design review cycles
+55%
improvement in WCAG AA compliance scores

Final thoughts

This project reinforced the value of systems thinking at scale. Shifting from a branding toolkit to a product-ready design system required more than component updates, it took cross-functional trust, iterative rollout, and long-term governance. I learned that real system success comes from investing in onboarding, async education, and feedback channels just as much as building components.

If I could do it again, I’d start adoption rituals even earlier and assign clear system ownership roles per product line. Still, this work enabled teams to move faster, stay consistent, and ship with confidence, without sacrificing quality or accessibility.