Magdalena Mrowiec

Glovo • 2021

Checkout Error Recovery

Redesigned a checkout error flow to help users recover when selected product customisations became unavailable before placing an order

Checkout

Error Recovery

Interaction Design

Context

In Glovo’s checkout, product customisations could become unavailable after a user had already selected them. The system only rechecked availability at specific moments: when users landed on checkout, modified products, or tapped “Place order.”

The existing experience showed a generic native error message saying that some selected customisations were unavailable, without explaining which product or customisation was affected.

Problem

The generic error forced users to troubleshoot the issue themselves at the worst possible moment: checkout.

Key issues:

​

  • Users were not told which product or customisation was affected.
  • The flow did not help them recover or continue the order.
  • The error created friction at checkout and decreased checkout conversion.

Because the issue had a relatively low business impact — around 1 bps to checkout conversion — the goal was not to redesign the whole availability logic, but to find the minimum valuable solution that could unblock users.

Approach & Decisions

I explored three recovery flows and tested them with 60 users in Maze. The goal was to understand which solution helped users recover with the least friction while staying realistic for engineering and design system constraints.

Flow 1: Remove affected products automatically

This was the simplest to develop and allowed users to continue quickly, but it removed control from the user. If they still wanted the product with different customisations, they had to go back and rebuild the order.

Flow 2: Let users remove or edit the product

This gave users control, but required new components and added implementation complexity.

Flow 3: Let users remove or edit the product using existing design system components

This kept users in control while reducing design system and development effort, so it became the strongest candidate.

The usability test confirmed that Flow 1 was the least usable and had the highest bounce rate. Flows 2 and 3 were both intuitive, but Flow 3 offered the best balance between usability, implementation effort, and system consistency.

Outcome

We selected Flow 3 for the final app test and added the option to remove the product from the customisation page, in case users did not want to continue with the available alternatives.

​

Compared with the old flow:

​

  • Almost 3x more users placed an order at the same store.
  • Users ordering from another store decreased by half.
  • Around 25% fewer users abandoned the flow.
  • Overall conversion from error message to order at any store increased by almost 10%.
Store Browsing Experience

Redesigned store cards to better support promotions, loyalty benefits, ratings, and trust signals at scale.

See case study →

Magdalena Mrowiec

Glovo • 2021

Checkout Error Recovery

Redesigned a checkout error flow to help users recover when selected product customisations became unavailable before placing an order

Checkout

Error Recovery

Interaction Design

Context

In Glovo’s checkout, product customisations could become unavailable after a user had already selected them. The system only rechecked availability at specific moments: when users landed on checkout, modified products, or tapped “Place order.”

The existing experience showed a generic native error message saying that some selected customisations were unavailable, without explaining which product or customisation was affected.

Problem

The generic error forced users to troubleshoot the issue themselves at the worst possible moment: checkout.

Key issues:

​

  • Users were not told which product or customisation was affected.
  • The flow did not help them recover or continue the order.
  • The error created friction at checkout and decreased checkout conversion.

Because the issue had a relatively low business impact — around 1 bps to checkout conversion — the goal was not to redesign the whole availability logic, but to find the minimum valuable solution that could unblock users.

Approach & Decisions

I explored three recovery flows and tested them with 60 users in Maze. The goal was to understand which solution helped users recover with the least friction while staying realistic for engineering and design system constraints.

Flow 1: Remove affected products automatically

This was the simplest to develop and allowed users to continue quickly, but it removed control from the user. If they still wanted the product with different customisations, they had to go back and rebuild the order.

Flow 2: Let users remove or edit the product

This gave users control, but required new components and added implementation complexity.

Flow 3: Let users remove or edit the product using existing design system components

This kept users in control while reducing design system and development effort, so it became the strongest candidate.

The usability test confirmed that Flow 1 was the least usable and had the highest bounce rate. Flows 2 and 3 were both intuitive, but Flow 3 offered the best balance between usability, implementation effort, and system consistency.

Outcome

We selected Flow 3 for the final app test and added the option to remove the product from the customisation page, in case users did not want to continue with the available alternatives.

​

Compared with the old flow:

​

  • Almost 3x more users placed an order at the same store.
  • Users ordering from another store decreased by half.
  • Around 25% fewer users abandoned the flow.
  • Overall conversion from error message to order at any store increased by almost 10%.
Store Browsing Experience

Redesigned store cards to better support promotions, loyalty benefits, ratings, and trust signals at scale.

See case study →

Magdalena Mrowiec

Glovo • 2021

Checkout Error Recovery

Redesigned a checkout error flow to help users recover when selected product customisations became unavailable before placing an order

Checkout

Error Recovery

Interaction Design

Context

In Glovo’s checkout, product customisations could become unavailable after a user had already selected them. The system only rechecked availability at specific moments: when users landed on checkout, modified products, or tapped “Place order.”

The existing experience showed a generic native error message saying that some selected customisations were unavailable, without explaining which product or customisation was affected.

Problem

The generic error forced users to troubleshoot the issue themselves at the worst possible moment: checkout.

Key issues:

​

  • Users were not told which product or customisation was affected.
  • The flow did not help them recover or continue the order.
  • The error created friction at checkout and decreased checkout conversion.

Because the issue had a relatively low business impact — around 1 bps to checkout conversion — the goal was not to redesign the whole availability logic, but to find the minimum valuable solution that could unblock users.

Approach & Decisions

I explored three recovery flows and tested them with 60 users in Maze. The goal was to understand which solution helped users recover with the least friction while staying realistic for engineering and design system constraints.

Flow 1: Remove affected products automatically

This was the simplest to develop and allowed users to continue quickly, but it removed control from the user. If they still wanted the product with different customisations, they had to go back and rebuild the order.

Flow 2: Let users remove or edit the product

This gave users control, but required new components and added implementation complexity.

Flow 3: Let users remove or edit the product using existing design system components

This kept users in control while reducing design system and development effort, so it became the strongest candidate.

The usability test confirmed that Flow 1 was the least usable and had the highest bounce rate. Flows 2 and 3 were both intuitive, but Flow 3 offered the best balance between usability, implementation effort, and system consistency.

Outcome

We selected Flow 3 for the final app test and added the option to remove the product from the customisation page, in case users did not want to continue with the available alternatives.

​

Compared with the old flow:

​

  • Almost 3x more users placed an order at the same store.
  • Users ordering from another store decreased by half.
  • Around 25% fewer users abandoned the flow.
  • Overall conversion from error message to order at any store increased by almost 10%.
Store Browsing Experience

Redesigned store cards to better support promotions, loyalty benefits, ratings, and trust signals at scale.

See case study →