Order Placement · Fixing a Legacy Checkout — Case Study by Mari Kondrateva

The situation

A checkout users called broken — when nothing was broken.

Unimarket is a large, scalable procurement system, first built around 15 years before I joined the order-placement work. The customer success team was fielding a steady stream of the same complaint: the checkout doesn't work. Orders weren't completing.

In a procurement platform, an order that won't place isn't a cosmetic annoyance. It's committed spend that never lands — a buyer who escalates to support instead of finishing the transaction. The same failure mode any checkout or money-movement flow lives in fear of.

Engineering had checked the checkout end to end. Technically, it submitted fine. So the problem was living somewhere between the screen and the user — exactly where a designer is supposed to go looking.

Investigation

The carts that failed all had one thing in common.

I sat with the customer success team, pulled the order data, and looked for the pattern in who got stuck and who didn't. It split cleanly on one variable: cart size.

Under 10 items

Smooth

Buyers submitted their orders without trouble. No complaints.

Over 10 items

70%

of buyers got stuck before the order was ever placed.

Something about larger carts was breaking the path to checkout — and larger carts are exactly the high-value orders you least want to lose.

The problem

Three buttons said "Next". Only one was checkout.

Over 10 items, the cart paginated. Each page got a primary "Next" and "Back" to move between pages. The button that actually placed the order was styled the same way — as a primary "Next".

So at the bottom of a long cart, a buyer faced two or three identical buttons all saying "Next". One advanced the page. One committed the order. Nothing told them apart. Most people clicked through pages expecting to reach checkout, looped, and concluded the checkout was broken.

The original Unimarket cart with a paginated item list, showing a 'Back' and 'Next' pagination pair mid-page directly above a second primary 'Next' checkout button at the bottom right — The live cart: the pagination "Back / Next" pair (mid-page) sat directly above the checkout "Next" (bottom-right) — same colour, same weight, same word.

The bug wasn't in the code. It was that the most important action on the page — the one that completes the transaction — looked exactly like the least important one.

The solution

Clarify first, simplify second — inside an agile sprint.

The software team worked in tight agile cycles. A structural change to a 15-year-old checkout needed planning and regression testing across browsers — time we didn't have while buyers were actively bouncing. So I split the fix into two moves: a safe one that could ship immediately, and the proper one that followed.

Milestone 1 · The band-aid

Change the words and the weight, nothing else.

For the first pass I was deliberately constrained to styles and wording — no layout or structure changes. That was enough to remove the ambiguity:

The checkout button became "CHECKOUT", restyled as the single primary action on the page.
Pagination controls were relabelled "← PREV 10 ITEMS" / "NEXT 10 ITEMS →" and demoted to a secondary, outlined style.
The result: one button that reads as "finish", two that clearly read as "keep browsing".

The cart after Milestone 1: pagination relabelled to 'PREV 10 ITEMS' and 'NEXT 10 ITEMS' as outlined secondary buttons with page dots, and a single solid primary 'CHECKOUT' button at the bottom right — Milestone 1: pagination relabelled and demoted to outline buttons with page dots; a single primary CHECKOUT button owns the bottom-right.

Final solution · Remove the maze

Question the pagination itself.

With the pressure off, we asked why the cart paginated at all. It turned out to be a constraint inherited from older technology, not a current one. The cart already capped at 1,000 items, so we tested a single long list at that limit:

Carts of 1,000 items rendered cleanly across all modern browsers — the old performance worry no longer held.
In collaboration with the software team, we removed cart pagination entirely.
User surveys confirmed buyers preferred seeing every item in one continuous, scrollable list.

The final cart design: a single continuous scrollable list of all items with no pagination, and one primary 'CHECKOUT' button at the bottom right — Final solution: pagination gone. One continuous list, one CHECKOUT button — no competing "Next" left to mistake.

The result

The complaint stream went to zero.

The customer success team never received another complaint of this nature again. No new feature, no rebuild — a wording-and-hierarchy fix first, then the discipline to delete a pattern that no longer earned its place.

100% of "broken checkout" complaints resolved — the pattern never recurred

70% → 0 stuck rate on large carts, eliminated

58% CSAT lift across the order-placement experience this work was part of

Lessons

What a legacy checkout taught me.

The simplest fix is often the right one.
Before rebuilding anything, I changed two words and one button style — and that alone recovered most of the lost orders. Reach for wording and hierarchy before architecture.
Question inherited constraints.
The pagination existed because of a technical limitation that had quietly expired years earlier. In legacy financial and procurement systems especially, much of the friction is old constraints that no longer apply — worth re-testing before you design around them.
Ship the band-aid, then ship the fix.
Working in agile let me validate the hypothesis with a low-risk change in days, prove it moved the number, and earn the room to do the structural work properly. Quick iteration de-risks the bigger bet.