Add-to-order: letting customers change an order after payment

Auchan is one of Russia's largest grocery retailers, with an online store and mobile apps. Online grocery ordering is rigid: the customer builds a cart, picks a delivery slot and pays, and then the order goes to the store for picking.

Between payment and the start of picking there is a window when the order already exists, but nothing is physically happening to it yet. That's exactly when customers most often remember they forgot the milk.

The task came from the business – from Auchan's product managers and the head of the department. It had three sources:

How it was

Objectives

• Design a new user journey for adding items to an existing order
• Show all the screens and states needed to understand the feature
• Adapt the solution for the website, mobile web and the mobile app
• Stay within Auchan's existing brand book and UI kit

I was the Senior / Lead of aic studio's external design team. Auchan had a full product team but no in-house designers, so the design expertise and responsibility for the solution were on our side.

Add-to-order is limited not by the interface but by operations: the warehouse, pickers, couriers and the payment flow. We received these constraints from the business and development teams, and they shaped almost every design decision.

The main question was where the customer picks the items to add.

User flow

In Figma, the flow is built separately for each of the three entry points and each platform: 9 branches in total, each with the catalog, adding items, three exception pop-ups, the add-on page and the updated order.

Add-to-order should meet customers where they remember the forgotten item – not where it's convenient for us to place it.

We identified three such moments and added an entry point to each. Everywhere, the conditions are worded the same way and shown before the click: how many items can be added, the weight limit and the deadline.

Thank you for your order

The hottest moment: the customer has just paid and still has their shopping list in mind. Next to the order information we added a "Forgot something?" block: an informer with the conditions, a recommendations slider based on the items in the order, and a link to the catalog. The screen in the mobile app is shorter, so only the informer and the "Go to catalog" button remained there.

My orders

Customers come back here later, once they remember an item. Order cards with the "Awaiting picking" status got an "Add to order" button. On desktop it opens a pop-up with recommendations for quick adding; on mobile it goes straight to the catalog.

01 / 02

Order details page

The third entry point is for those who came to check the order status. The button sits in the "Total" block next to the amount, because adding items changes that amount.

A constant companion in the catalog that answers three questions: which order am I adding to, how much more can I add, and how much does it cost.

From any entry point, the customer lands on the top level of the catalog with add-to-order mode already on, and then browses sections as usual. On desktop, the module is pinned as a floating bar in the corner of the screen; in mobile web and the app, it's built in above the navigation bar, where the cart usually lives.

Product cards work the same way as in the regular catalog: "Add to cart", then a quantity stepper. Only the destination changes: the item goes into the add-on instead of the cart.

If an item can't be added right now, the customer sees a "This item can't be added to your order" pop-up right in the catalog. Instead of a dead end, the pop-up suggests a similar item that can be added straight away, and nothing already selected is lost.

01 / 02

Before confirming, the customer sees the original order and the added items on one screen.

The "Order add-on" page follows the cart's logic: at the top, the original order with its delivery slot; below, the added items, where you can change quantities, remove an item or clear the whole add-on; on the right, a summary with the weight and the add-on total. The "Back" button returns the customer to the catalog page they were on, so they can throw in something else.

The hardest part is the money. The mechanics depend on how the original order was paid.

After confirming, the customer returns to "My orders" and sees the same order with the added items and the new total.

The add-on lives inside someone else's process and can end without the customer choosing to end it.

When picking has already started, the pop-up explains why and immediately offers two ways out: "Move to cart" for a new order, or "Exit add-to-order".

01 / 02

The scenario was designed for desktop, mobile web and the app at the same time. The logic, copy and states are shared; only the way the module fits into navigation differs.

Under the brief, the solution had to fit within Auchan's existing brand book and UI kit. The only new components were the ones specific to the scenario: the add-to-order module, the recommendations modal and the three exception pop-ups. Everything else was built from existing cards, buttons and informers.

How we validated the solution

Before development, the scenario went through internal UX reviews with product managers and developers, plus testing on a clickable prototype. I don't have access to post-launch quantitative results: Auchan's team ran the measurements after the mockups were handed off. Below is the validation plan I built into the solution.

What the team expected

Final decisions were made by Auchan's product managers and head of department, while the design expertise sat with the studio. That meant arguing every decision in terms of the business task, not taste.

• Presented options with their pros and implementation cost, rather than one "right" design
• Discussed every warehouse and payment constraint with developers first, and only then designed
• Designed edge cases together with the main scenario, not after it

Process: brief from product managers → scenario and constraints → options → review → mockups for three platforms → handoff → design support during development

The handoff included the module's states, the copy for the conditions, rules for each order status and annotations for the payment branches.