Ascenda Design System

Upgrading Ascenda’s design system to support a whitelisted product, enhancing flexibility, responsiveness, and documentation for a more scalable and accessible experience.

Company

Ascenda Loyalty

Duration

6 months

My role

UI design

Design system

Elevating a design system with components that support multiple brands

Context

Ascenda Loyalty delivers innovative white-label rewards solutions, enabling banks, fintechs, and travel brands worldwide to power seamless loyalty programs. Our clients' users can redeem points for a variety of rewards, including flights, hotels, car rentals, gift cards and others.

Challenge

As Ascenda scaled rapidly, the existing design system struggled to keep up, leading to several challenges:


  • Limited flexibility in supporting different brand styles and languages

  • Accessibility issues with client brand colours

  • Lack of proper component documentation

  • Inconsistent naming conventions for component properties

  • Inconsistent interactive state styling

  • Components were not responsive

Guiding principles

With the product being whitelisted, a key goal of the Ascenda design system was to ensure flexibility in accommodating various brand styles and colors, without sacrificing color contrast for accessibility.

Flexibility & customisation

Prioritize flexibility to support various brand identities and colors while preserving design consistency and accessibility.

Specs & documentation

Clear and comprehensive documentation that accelerates the design and development process, enabling faster iteration cycles.

Consistency

Ensure uniformity across all components and interactions for a cohesive user experience.

Scalability

Components should be reusable and easily adaptable to new use cases across multiple platforms.

Flexibility & customisation

Ascenda supports a wide range of configurations, with the most common use cases including:

  • Typeface

  • Primary brand colour

  • Secondary brand colour

  • Border radius for buttons

Aliases and tokens

One of the methods I proposed to support the whitelisted product was introducing aliases and tokens, allowing product designers to easily switch between brand colors and ensure the interface meets accessibility requirements.

Testing with different brand colours

I tested all components with various brand color schemes to ensure they maintained consistency and visual integrity across different styles. Additionally, I verified that all components met accessibility standards, focusing on color contrast and readability to ensure an inclusive experience for all users.

Specs & documentation

When I first joined, I observed that most of the components lacked documentation. After discussions with the frontend engineers and designers, we identified and prioritised key specifications that were hindering proper implementation.

Change log summary

Component anatomy

Component variations

Behavioural guidelines for complex components

Component property naming conventions

Interactive state guidelines

Consistency

Another major concern was the inconsistency in interactive states across components—hover, active, focus, and disabled. Variations in colours and shades created a disjointed experience, making it harder for users to navigate and caused confusion among designers and developers.

UI audit

To pinpoint the affected components, I conducted a UI audit of the design system to identify components that are:

  • Using incorrect shades or colours in their interactive states

  • Using client branding colours incorrectly

Standardising colour usage

Beyond ensuring consistent application of colours for interactive states and components, I established guidelines to help other designers create new components correctly to maintain a unified user experience.

Scalability

For scalability, I prioritised two critical areas—responsiveness and localisation. Ensuring components adapted seamlessly across different screen sizes improved usability, while supporting multiple languages was essential for a more inclusive and globally accessible product.

Responsiveness

Fixing the lack of responsiveness was one of my top priorities. Most of the components were either not responsive at all or failed to meet tablet-specific requirements, resulting in a suboptimal experience for users on various screen sizes.

Localisation

As the product began rolling out localisation features, I tested and re-designed components to ensure they could accommodate different languages. This included adjusting text sizes, alignment, and ensuring the layout was flexible enough to handle varying word lengths and scripts, without compromising the overall user experience.

Tracking the impact of the design system

Our design system lacked clear metrics to evaluate its performance, relying instead on ad hoc feedback from developers and designers. To address this, I implemented a metric system and a bi-annual survey to gather structured feedback, ensuring our efforts align with continuous improvement.

Outcomes and learnings

Improving the design system made a real difference. Developers found the clearer documentation sped up implementation, while product designers had an easier time understanding how each component worked. Components became more polished—more consistent, responsive, and adaptable to different needs. Plus, accessibility improved, with fewer contrast issues when applying different brand colours.


Working on a whitelisted product really pushed me to think beyond just design—it was about making something truly flexible. I also gained a much deeper appreciation for documentation and what developers actually need, which has made me a better, more thoughtful designer.

© 2025 Gwendolyn Goh

© 2025 Gwendolyn Goh

© 2025 Gwendolyn Goh