/projects/rewards Booking.com

The process of earning rewards via our Affiliate Partners during accommodation booking had never been user-tested before. Additionally, the interface elements utilised in the funnel and book process did not align with our Booking.com Design System and so did not work well when displayed alongside reward offerings and promotions from other departments.

Affiliate Partner Rewards are offered to bookers who land on Booking.com via a registered affiliate. For example KLM Flying Blue may direct travellers to book their accommodation on Booking.com after booking a flight, and for every €/£/$ spent on Booking.com the booker earns a percentage in the affiliate’s miles.

Hardly any design documentation of Affiliate Rewards existed so we began by collecting all examples of reward components into one Figma file. From here we were able to grasp the scale of our rewards offering, and also began to see patterns.

↑Audit: collected examples of all reward components into a single Figma file

Although our offering was diverse, we outlined 3 main functions of information:

1. Promotional: banners, badges
2. Informational: T&Cs modals, fulfilled by 𝑥
3. Instructional: don’t forget to 𝑥 at checkout

We wanted to hear from real people about their experience of earning rewards. We decided to use UserTesting.com to power our tests but couldn’t run tests for all reward types. So we looked into the data and found the top reward type and platform (mobile or desktop) per region.

While scripting and prototyping we made sure to try to draw out answers to some key questions we had:

• Were the banners attractive or noticeable?
• Were reward terms & conditions clear and easy to find?
• Was it clear who would fulfil their reward, Booking.com or the Affiliate Partner?
• Was the processing time of the reward surprising?
• How much weight would the reward have on their decision making?

Key user testing discoveries

• Missed the banner on the index page. 63%
• Missed the reward T&Cs 75%
• Didn't know who would fulfil their reward 38%
• Were surprised by the processing time 88%
• Liked earning rewards, it's like getting something for free 100%
• Would let the reward affect their choice of property 00%

These findings drove our decision making for our design solutions. We presented them to the wider team where we learned that the developers were about to start refactoring work in this area. It was an ideal opportunity to implement any design changes, and we got to work.

When exploring different design solutions for our components we focussed on delivering the right information at the right time, while aligning with the Booking.com Design System and different teams.

Banners and affiliate branding

Our proposal moved the banner into the hero component on desktop and into the promotion card section on mobile and made the copy more striking. For partner branding we settled on a non-breaking compromise and planned to collaborate with the design systems team later.

↑Redesigned desktop and mobile rewards banners and Partner branding.

Terms & conditions modal

Our solution introduced headings and additional information about how to use your reward.

↑Redesigned terms and conditions modal with more detailed information.

Badges

Our solution aligned with a larger effort across Booking.com to align all promotional badges into a single line of green text, ideally under 3 words long. Because we knew the rewards we offered were not primary decision makers, we were comfortable with reducing their visual weight and aligning with other badges.

↑Badges aligned to company wide design pattern.

Reward summary

We introduced information tackling each of the mentioned pain-points, who would fulfil the reward, the expected processing time, subtle Partner branding, and if action was still required a callout to what needed to be done.

↑The redesigned rewards summary block with additional information

Payment block

Our solution tied information to the action, placing the reward value next to the required payment method.

↑The payment block showing which payment method is tied to earning the reward.

In-app banners and branding

Introducing Rewards to apps was out of the scope of this project but we wanted to propose designs for Partner branding and rewards banners that aligned with existing app design patterns to lay the groundwork for future development.

Round 02 of user testing

All design solutions were user tested in a follow up round on UserTesting.com, following almost the exact same process and script as round 1.

Results & impact

• Clearer communication of reward delivery times and fufillment processes, lowering related CS tickets.
• Aligment with Design System in 10/12 elements within project scope, lowering development debt and improving compatibility for situations where multiple rewards and promotions are offered from different teams.
• Clearer communication of requirements to earn rewards, shown by follow up user testing.
• An improved flow of communication through the booking funnel, showing the right information at the right time, in the right place.
• Customer behaviour learnings that we were able to share with Account Managers and Affiliate Partners to empower them make better decisions regarding their reward offerings.
• Groundwork layed for offering Affiliate Rewards in apps.

Reflection

It is amazing how much back and forth between product & dev teams over some issues can be resolved by simply talking to customers. Doing just a bit of research helped clarify some issues that would have been near impossible to do without their insight and provided us with knowledge we could share with Partner's via Account Managers about how customers behave on Booking.com and what's important to them.

Rewards Standardisation project was done in collaboration with Svetlana Iagodina