Checkout migration and optimization for white labeling
Role
Lead UX Designer
Platform
Web
Status
Shipped
Year
2023
Our entire hotel-booking platform had been migrated to React.js except for the checkout which was still in Angular.js. In the process of migrating checkout, we heavily optimized the UX throughout which resulted in a 10% increase in both conversion and margin.
We had a dedicated EPD scrum team to tackle this checkout migration.
Including our product owner, a small group of developers, and me as the design lead with occasional support from 1-2 additional designers.
Since the front-end would need to be rebuilt anyway, this created a unique opportunity to optimize the UX & UI along the way.
Mobile and desktop views of the final design
A sample of the configurable features to account for.
Existing mobile page
Existing desktop page
Competitive analysis comparing desktop-first vs mobile-first UIs.
With help from our UXR lead, we conducted qualitative user testing on 3 different styles of checkouts.
We interviewed 9 users in an unmoderated walkthrough. Each user saw all 3 prototypes in varying order and shared their thoughts and experience out loud.
Wireframe prototypes we used for this round of user testing
A small portion of the test analysis, showing users' split preferences on checkout style.
A multi-page experience was the style of checkout we chose to proceed with
While the research results were inconclusive, our focus on mobile-markets ultimately leaned me towards the multi-page style of checkout to relieve users of content overwhelm. Our parent company also used this style of checkout for similar needs which validated this choice.
My EPD scrum team documented all needed features upfront
This helped us prioritize work so we could work agilely and launch iteratively.
#1 priority features for design: guest information inputs, accommodation details, price breakdown, and payment details.
Consulting best practices
Our new layout style would require some rethinking when it came to how some of our features would be communicated. The nature of this project meant we would be updating multiple aspects of the design simultaneously.
We launched the new checkout with our first partner, T-Mobile!
The page experiment was rolled out with partial user traffic at first. We watched conversion closely to triage any errors.
Some views from this partner launch.
We conducted a round of usability testing to validate our new experience.
Our mobile-first checkout performed well and 100% of respondents felt either confident or very confident about their overall experience.
Results from our test's tasks. This showed us where any spots were that may have needed any re-evaluation.
Old checkout on the left, new checkout on the right.
After troubleshooting a few bugs, not only was conversion up, but overall load time was also down.
Once the page met and/or exceeded conversion rates of the existing Angular page, it was rolled out to all users of T-Mobile.
We continued designing and developing for our other two types of checkouts:
T-Mobile was considered a "discount" partner. Next, we solved for when a user earns rewards through checkout, and for when a user redeems rewards for their booking. These checkouts all used the same design system base, but each required unique details and features.
Comparison of how the details panel varies based on which type of funnel the checkout is for.
In addition to migrating and optimizing all old features, we added entirely new ones as well
One such feature was the ability to pay through a third party. This is an example of a long anticipated feature that many users spoke about that we were finally able to design and implement for our platform.
Payment selector flow with cascading logic.
Interaction details
Eventually, all products under all types of checkouts on this platform were successfully migrated to the new design.
In production walkthrough of a discount funnel checkout.
A sample of documentation for nested components and their configurability.
A sample of documentation laying out how each feature should be configured if needed per partner.
Retrospective
Throughout the process, we had moments of needing to go back and tweak previously designed pieces. As much as we tried to document all use cases upfront, we occasionally uncovered new details that required some additional consideration for everything to work together seamlessly.
Reward travel is complex!
There’s a learning curve to understanding how all of its unique features and use cases work together.
A clearer source of truth on our product could’ve potentially helped mitigate some of these instances of reconsideration.
Information gathering became a large time suck and made it clear the importance efficient internal systems that include robust baseline templates and documentation.