The order summary collapse test: hiding the basket on mobile did not do what we expected
Payment entry is the highest anxiety moment in the checkout, and the summary is the shopper anchor: the proof that the page is still about their order, at the price they agreed to. Watch session recordings and the pattern is plain. Eyes flick to the total before typing the card number, and again before pressing pay. The summary is not information at that point. It is reassurance, and reassurance has to be visible to work.
That reframes the collapse question. The issue was never screen space. Mobile screens fit a one line summary bar fine. The issue is whether the collapsed state preserves the two numbers the shopper checks: how much, and for how many items. Versions that preserve them test neutral to fine. Versions that show only the words order summary with a chevron test badly, because the chevron asks for a tap at the exact moment the shopper hands are busy deciding whether to trust the page.
Why shoppers keep looking at the summary
Split by device or do not bother. Desktop summaries sit in a sidebar and are not collapsed, so a blended result dilutes the mobile effect into invisibility. Run mobile only, completion of the payment step as the metric, and watch the summary toggle interaction rate as the diagnostic. A high toggle rate on the new design is the design failing in public: shoppers are spending taps to recover information the old layout gave free.
Give it real traffic before judging. Checkout tests are low conversion events per visitor compared with product page tests, and a few hundred checkouts a side will produce noise that looks like a result. Operators who log null results honestly will tell you most summary tests are null. The ones that are not null are the ones where the total vanished.
The test setup that tells you anything
The collapsed bar breaks hardest after shipping is chosen. A shopper who selected a 9.95 express option watches the total in the bar, and if the bar total does not update, or the bar hides the total until the review step, the express choice feels unverified. Some shoppers go back a step to check, and the back button at payment is where mobile checkouts bleed.
Delivery charges are part of the total problem
Keep reading: Wallet buttons above or below the form: the order is a segmentation question, Address line two: the optional field that eats apartment deliveries.
What we kept, and what we dropped
Keep the collapsed total live: it updates when delivery changes, and it itemises on tap, delivery line included. That single behaviour, a total the shopper can trust without opening anything, is worth more than any animation or styling applied to the same component.
The pattern worth keeping is a sticky summary bar on mobile with item count, total, and an expandable item list for the shoppers who want it, roughly a fifth of them in most logs. Expand on tap, with the delivery line shown separately from the product subtotal, because conflating them is what makes shoppers suspect a hidden fee.
What got dropped, after testing, was the auto expanding summary that pushes the payment form down the screen on arrival at the step. It tested as clutter returning through the back door. The form is the job at the payment step. The summary is the reference. References sit still and stay readable. That is the whole design rule this test bought.
Frequently asked questions
Should the mobile order summary be collapsed or expanded by default?
Collapsed as a list, visible as a bar. Show item count and total at all times, let shoppers expand the item list on tap if they want it. Hiding the total itself behind a toggle is the version that consistently tests badly.
How much traffic does a checkout summary test need?
More than most stores expect, because checkout completion differences worth having are often one or two points. As a rough discipline, judge on thousands of mobile checkout starts per variant, split new and returning, and treat anything decided on a few hundred starts as a guess.
Why do shoppers open the summary during payment entry?
To verify the total and the items before committing card details. It is a trust check, not an information search. Designs that keep the total visible satisfy the check without a tap, which is why the collapsed bar with a live total performs like the expanded summary.
Should the summary total update when delivery changes?
Yes, immediately and visibly in the collapsed bar. A total that does not reflect the delivery choice the shopper just made reads as an error, and sends shoppers back a step to investigate, which is where mobile abandonment concentrates.