OVERVIEW
Providing consumers promotions and discounts through mobile ordering
PROJECT
Digital Vouchers on Collect
ROLE
Lead UX/UI
OVERVIEW
Providing consumers promotions and discounts through mobile ordering
PROJECT
Digital Vouchers on Collect
ROLE
Lead UX/UI
-01 Overview
Collect is our mobile ordering service, allowing consumers to order ahead on the app and skip the queue; saving them roughly 3.5 minutes waiting in line.
And whilst our Costa Club app consumers out-spent our more traditional physical card holders, we weren’t rewarding those app consumers who place their orders through our Collect service.
If app consumers wanted to use their rewards and offers via the app, they would need to queue in store and scan their loyalty QR code – negating the very reason why we launched our Collect service in the first place?
-02 Background
The pandemic had seen us close 95% of our stores. With a lack of consumers purchasing our products, we made the decision to work on initiatives to reward consumers once we were able to open and to ensure our physical touch-points were safe to interact with.
When we decided to press on with this project, we faced 3 main challenges.
API
Checkout flow
Rewards
API
Checkout flow
Rewards
-03 Challenge – API
During our workshop we discovered a very limited technical constraint. Once the UK government allowed partially open stores, we saw an increase in Collect orders as consumers returned to the high streets. Although they weren’t allowed in the stores themselves, our consumers would order on our app and collect from the front of our stores.
As expected we saw ann increase in Collect orders however what wasn’t anticipated was the drastic rise of the average basket from £2.98 to £6.43.
Great for the business. Not so much for our tech stack.
There were 2 API calls on the basket screen that fetch information on product, location, price and products qualifying for a bean (stamp on a card). Then a labour intensive calculation is performed.
The increase in basket size and the number of consumers using collect slowed down the API calls significantly.
A new API call on this screen was to match the reward to the product and then re-do the calculations based on that reward.
There were 2 API calls on the basket screen that fetch information on product, location, price and products qualifying for a bean (stamp on a card). Then a labour intensive calculation is performed.
The increase in basket size and the number of consumers using collect slowed down the API calls significantly.
A new API call on this screen was to match the reward to the product and then re-do the calculations based on that reward.
There was genuine concern that the system would fall over.
So we needed a way to separate the API calls so it wouldn’t overload the system and cause a critical failure to the app.
There was genuine concern that the system would fall over.
So we needed a way to separate the API calls so it wouldn’t overload the system and cause a critical failure to the app.
-04 Challenge – Checkout Flow
We had worked up a few different happy and unhappy path scenarios for Alex; focusing on discovering the rewards and adding qualifying products before completing the transaction.
We also wanted Alex to notice the rewards being applied to ensure there was no confusion along the way.
Alex’s journey to add a reward
Alex’s journey to add a reward
-05 Challenge – Rewards
Our biggest challenge was around the trypes of rewards available to Alex – targeted and non-targeted.
Targeted rewards refers to rewards that correspond to a particular product. For instance Alex has a reward for £1 off a bacon roll. So that reward can be mapped directly to the bacon roll product.
Non-targeted rewards are rewards that may have a number of products associated with it. So 50% off a drink would allow Alex to apply that reward to a host of different drink types.
So mapping targeted rewards was easy. Mapping non-targeted was more challenging.
-06 Testing – API
We decided to separate the API calls to spread the load over Alex’s journey. So we decided to move from a 1 step basket to a 2 step approach.
Two step basking performing well
Two step basking performing well
Although Alex found the 2 step approach easier to scan, we were duplicating content. So we looked at an alternative solution.
We took inspiration from Uber Eats. What I wanted to do was draw Alex’s eye to a highlighted area of the screen to ensure she takes in all the important information. Using the overlay would allow Alex to check that the right product was in her basket.
Although Alex found the 2 step approach easier to scan, we were duplicating content. So we looked at an alternative solution.
We took inspiration from Uber Eats. What I wanted to do was draw Alex’s eye to a highlighted area of the screen to ensure she takes in all the important information. Using the overlay would allow Alex to check that the right product was in her basket.
-07 Testing – Flow & Rewards
We wanted to test the discovery of the rewards screen. A simple change of colour was enough to simplify the discovery as it was subtle enough to draw the eye.
-07 Testing – Flow & Rewards
We wanted to test the discovery of the rewards screen. A simple change of colour was enough to simplify the discovery as it was suble enough to draw the eye.
However we discovered a major flaw when we asked participants to add more than 1 reward. After adding 2 rewards, most participants went straight to payment without adding the bacon roll.
“…I expected the products to be added to the checkout once I applied the offers.”
However we discovered a major flaw when we asked participants to add more than 1 reward. After adding 2 rewards, most participants went straight to payment without adding the bacon roll.
“…I expected the products to be added to the checkout once I applied the offers.”
However we discovered a major flaw when we asked participants to add more than 1 reward. After adding 2 rewards, most participants went straight to payment.
We tried telling Alex through onboarding and through a tool tip but with little joy. 40% of participants didn’t notice the tool tip and 60% fumbled their way into the menu (orange circle in the image) and in the end still couldn’t add the bacon roll to their order.
So if participants were struggling to add more than 1 item to their order, how did we see an increase in our basket size during the pandemic? And how much revenue could we have had if this was an issue?
However we discovered a major flaw when we asked participants to add more than 1 reward. After adding 2 rewards, most participants went straight to payment.
We tried telling Alex through onboarding and through a tool tip but with little joy. 40% of participants didn’t notice the tool tip and 60% fumbled their way into the menu (orange circle in the image) and in the end still couldn’t add the bacon roll to their order.
So if participants were struggling to add more than 1 item to their order, how did we see an increase in our basket size during the pandemic? And how much revenue could we have had if this was an issue?
So I changed the close button to say “Menu” which made it easier for participants to discover and go back to the menu to add more items.
I also added a CTA that would allow participants to add targeted reward items straight to the basket. With non-targeted, the CTA would bring up a range of corresponding products to add.
It was a success with our participants.
So I changed the close button to say “Menu” which made it easier for participants to discover and go back to the menu to add more items.
I also added a CTA that would allow participants to add targeted reward items straight to the basket. With non-targeted, the CTA would bring up a range of corresponding products to add.
It was a success with our participants.
As we were testing the experience, the developers were testing the feasibility with the API calls to the solution above. To map the rewards to products was a lot more labour intensive than we all thought. So the CTAs and prompts we used couldn’t be used on the basket screen.
We needed another solution to allow consumers to add more than 1 product for qualifying rewards.
As we were testing the experience, the developers were testing the feasibility with the API calls to the solution above. To map the rewards to products was a lot more labour intensive than we all thought. So the CTAs and prompts we used couldn’t be used on the basket screen.
We needed another solution to allow consumers to add more than 1 product for qualifying rewards.
-08 Recommendation – API
We managed to split the API with the drawer approach. The labour intensive calculations were conducted when consumers tapped the “Checkout” button which made the experience faster than trying to do it on 1 screen.
The iterations of the basket screen
The iterations of the basket screen
-09 Recommendation – Flow & Rewards
The most stable way to inform consumers that they had an un-used reward was to prompt them with an alert. This allowed another API call to take place away from the basket screen.
Prompting consumers of un-used rewards
Prompting consumers of un-used rewards
100% of participants were able to add the bacon roll to their basket and complete the transaction when they were presented with the alert.
Once the team were able to make the API calls more efficient, our original solution would be implemented as a Day 2 delivery.
100% of participants were able to add the bacon roll to their basket and complete the transaction when they were presented with the alert.
Once the team were able to make the API calls more efficient, our original solution would be implemented as a Day 2 delivery.
The iterations of the rewards
The iterations of the rewards
-10 Summary
The pandemic had a big impact on my family and we decided to return home to Australia in 2021. This and 2 other projects were in development at the time I was re-locating home so I never got to see them go live. However at the time of writing, these products are live on the app.