Designing checkout for a bookshop losing buyers halfway through
Published research points to unexpected costs, account friction and complexity as the major causes of abandonment. I used those findings, not my own, to rebuild a small bookshop checkout around one consistent order model, costs disclosed before they are charged, and recovery paths that keep what you typed.
A self-set brief. The bookshop, the cart and the order totals are invented, so there is something concrete to design against. The research is not: the four causes come from published work by Baymard Institute and Contentsquare, cited where I use it, rather than from participants I made up. Nothing here has been tested against a real shop, so every claim on this page describes the design and not how it performed.
The 60 second version
The whole project is on this screen. Everything after it is the reasoning.
The price never moves on you
Subtotal, delivery, tax and total all come from the same model, so two screens can't show different numbers. The pay button tells you what you're about to pay.
Or none, if you use Google Pay
Guest checkout, eight fields, labels that stay visible. The one-tap route sits above the card form, not below it.
Designed, not skipped
Decline, out of stock, validation and digital-only carts are built into the prototype, because that is where the sale is actually lost.
Just me, four weeks, desktop
Research synthesis, flow, interface, microcopy, and the prototype this page runs on.
The prototype, driven end to end
A scripted run through the built prototype: a removal and its undo, format switching, a rejected postcode, a declined card, and the paid confirmation. The pointer you see is the script clicking, not a video.
Press Pause at any point, or “Let me click it myself” to take over.
Why people leave
Seven in ten carts are abandoned. Almost none of it is about how the page looks.
I didn't run my own study. Four weeks doesn't leave room for it, and invented participants would make the whole thing worthless. So I used the abandonment research that already exists as my brief: Baymard Institute's checkout usability survey and moderated testing, plus Contentsquare's US behavioural data. None of the top reasons people quit are about how a page looks. They're about money moving unexpectedly, effort nobody signed up for, or something breaking.
I picked an independent bookshop on desktop on purpose. A paperback needs an address, an e-book needs an email and nothing else, so the checkout has to fork rather than being one form for everyone. And desktop is where you get that two-column layout — form left, summary right — which is exactly where the total stops getting looked at.
| Share | The fear | What the research says | What it demands |
|---|---|---|---|
| 48% | The price is not the price | Extra costs — shipping, tax, fees — appeared too late to be part of the decision. | Every cost visible before it is charged, and a total that cannot change behind your back. |
| 26% | A step that serves the shop, not me | The site required an account to be created before it would take any payment. | Nothing in the flow that's only there because it helps the shop, and every button tells you what happens when you press it. |
| 22% | Too much asked, too little settled | The checkout was too long or too complicated to be worth finishing. | The fewest fields the order actually needs, and the edition and a real delivery date settled before payment. |
| 18% | One error and I lose everything | They did not trust the site with card details, and a failure meant starting over. | Safety signals next to the card field, errors that point at the field, and failures that never discard what you typed. |
Figures: Baymard Institute's checkout usability survey of US adult online shoppers (n = 4,384), multi-select, with the “just browsing” group excluded. Contentsquare's US data puts unexpected costs at the same 48%. The qualitative detail behind fears 3 and 4 comes from Baymard's moderated checkout testing rather than the survey.
Whose thinking is whose
External evidence. Published checkout research names unexpected costs, forced account creation and length as the major abandonment drivers. Baymard Institute and Contentsquare — not my study, and not my finding.
My interpretation. The underlying problem is not “too many fields”. It is uncertainty about what you will pay and what you are committing to. Cost becomes a problem when it arrives late, not when it is large. That reframes it from a screen problem into a data problem.
Design response. Unify the order model, expose every cost before it is charged, cut required input, and design the recovery paths. Three decisions, in section 02. Each one traces back to a line above it.
Someone else's findings are not a brief until you interrogate them. I listed every cause the studies name and ranked them, rather than inventing a scenario and finding data to fit it. Then each finding went through the same three questions: how does this happen to someone mid-purchase, why do they leave instead of pushing through, and where in the flow does it hit them. Asking when a cost shows up rather than how big it is turned four percentages into four fears I could design against.
Where the checkout research ran out — on how to word an error, or how much fits on one screen — I leaned on Sweller's cognitive load theory and Miller's work on chunking. Those are still calls, flagged as calls: a principle I can defend is not the same as a result I have measured.
“People are dropping out” was all I had at the start. It ended up as four named fears, each one with a number behind it and a screen that deals with it.
- Four ranked causes with sources behind them, which is what I designed against instead of guessing.
- Scope kept to cart-through-confirmation on desktop, so I could actually solve the branching problem instead of half-doing it.
- Everything I decided later traces back to something someone's actually measured.
Three decisions
One per fear, in the order I made them. For each: what the research pointed to, what I picked, what changed on screen, and what I gave up to get there.
Decision 01 — One money model, and every screen only reads from it
Answers fear 1 · cost transparency
The evidence. Baymard: 48% of fixable abandonment is extra cost appearing too late in the flow. Contentsquare's US data puts it at the same 48%. It is the largest single cause in both.
What I picked. I wrote the model first — items, format, delivery choice, tax rate, total. Screens just read from it. Nothing calculates anything on its own, so the number on the pay button and the number in the summary are the same number.
The thinking. Tell someone the real number at the start and they will usually pay it; change it on them at step three and they are gone. The studies name the cause but not the fix, so I asked when a cost becomes unexpected, and the answer was timing. That made it a data problem rather than a screen problem. Country was the sharpest version of this: tax follows the address, because VAT is a real consequence of where the parcel lands. Currency does not follow it, because the person paying may be nowhere near the person receiving, and quietly re-pricing the basket hands their bank a conversion nobody asked for.
The trade-off I accepted: doing this properly meant redrawing screens I had already finished.
Decision 02 — Ask for eight things, and let some people answer nothing
Answers fears 2 and 3 · forced accounts and length
The evidence. Baymard: 26% abandon because the site required an account before it would take payment, and a further 22% because the checkout was too long or complicated to finish.
What I picked. Guest checkout only. Account creation moves to the confirmation screen, pre-filled, so saying yes costs you nothing. Google Pay sits above the card form, so anyone who's got it never sees the form.
The thinking. My first instinct was a single clean container — no labels, placeholders only. It looked good, and there's plenty online telling you that pattern's accessible. It isn't. Placeholders vanish as soon as you type, screen readers handle them badly, and the people who most need a label are the ones who lose it. So I dropped that and went at the problem differently: fewer fields instead of fewer labels.
The trade-off I accepted: dropping company name and address line 2 makes things harder for business buyers and anyone with a complicated address. I'd rather add them back if evidence shows I need to than make everyone deal with them by default.
Decision 03 — Build the failure states, do not just describe them
Answers fear 4 · trust and recovery
The evidence. Baymard: 18% abandon because they did not trust the site with their card details, and their moderated testing finds shoppers who hit a failure often restart or leave rather than re-enter everything.
What I picked. Four failure states built properly into the prototype instead of mocked up: declined card, out of stock, field validation, digital-only cart. Security cues sit on the card form now. And whatever you've typed stays there when something goes wrong.
The thinking. A checkout is mostly edge cases, so showing only the run where nothing goes wrong skips the exact parts people are nervous about, and a padlock in the footer is nowhere near the field causing the nerves. The hardest judgement in the project wasn't any single decision — it was working out how much can sit on a screen at once. I settled it by asking what someone can hold in their head while they're typing a card number.
The trade-off I accepted: building the failure states as real, clickable screens took far longer than drawing pictures of them — and that is exactly what surfaced the two problems I admit to in section 04.
Where the shop and the shopper disagree
| Tension | Shopper | Business | How I settled it |
|---|---|---|---|
| Guest checkout | Less friction, no account to buy one book. | Fewer accounts, so less repeat-purchase data. | Take the payment first, offer the account on the receipt, pre-filled. |
| Fewer fields | Eight instead of sixteen. | Loses company name and address line 2, which business buyers need. | Ship the short form; add fields back only if the data shows they cost sales. |
| Costs shown early | No surprise on the pay button. | Shipping is visible before anyone is invested in the order. | Show the price with the date attached, so the cost arrives as a service, not a fee. |
Supporting detail — the words
A line either answers a question the shopper is already asking, or it goes.
| Before | After | Why |
|---|---|---|
| “Pay” | “Pay $43.38” | The one action here you cannot undo had no amount on it. It should tell you exactly what is about to leave your account. |
| Nothing under the button | “Your card is charged when you press Pay. Change or cancel free for 60 minutes after.” | Answers the two questions people ask with a finger hovering over that button: when does this hit my card, and can I undo it. |
| “Standart Shipping” | “Standard delivery, arrives Wed 5 Aug” | A typo of mine, copied across five screens before I spotted it. While I was fixing it I added the bit people actually want from that line, which is the date. |
Three decisions, four fears covered. Whether they hold up is a question about the build rather than the argument, so the rest of this page is the working thing.
The checkout
Three named steps, and one of them can disappear. The basket decides the shape of the flow, so nobody is asked for an address that their order does not need.
| Entry | Step 1 | Step 2 | Step 3 | Exit | |
|---|---|---|---|---|---|
| Screen | Cart | Delivery | Payment | Review | Confirmed |
| What it settles | Format, quantity, undo | Address + speed + contact | Method + card + billing | Everything, then Pay $43.38 | Track, amend, create account |
Paying with Google Pay
It already holds your address and card, so tapping it in the cart skips both steps and lands you on Review, filled in.
Digital-only cart
If every line is an e-book, delivery has no meaning. Step 1 becomes “Contact” and the flow is two steps.
Collect in store
Pick collection and the address form turns into a shop picker. The delivery-speed choice goes too.
Declined card
Back to step 2 with everything still filled in, says plainly that no money moved, and offers Google Pay instead.
The four states that are not the happy path
| State | What happened | User risk | Design response |
|---|---|---|---|
| Declined card | Payment failed | “Did I lose my order?” | Preserve every value, lead with “nothing has been charged” |
| Out of stock | Inventory changed mid-checkout | “Can I still buy?” | Name what changed, keep the rest of the order intact |
| Validation | Input rejected | “What is wrong?” | Inline, on blur, with the format shown |
| Digital-only | Delivery has no meaning | “Why am I being asked this?” | Remove the step, drop the shipping charge |
Screen by screen, with the reason it looks like that
Two notes per screen: the decisions I would defend in a critique. Each frame below is the real build, deep-linked to that step — you can click around inside any of them.
The cart settles format, quantity and cost before anyone types a thing. Format switches inline with the price delta on each option — the e-book saves $15.00 and removes delivery entirely. Remove offers Undo for seven seconds rather than a confirmation dialog nobody reads.
You choose how you are getting the books before anything that depends on it appears. Choosing collection swaps the whole address block for a store picker. Change the country and the region, postcode and tax all change with it, each validated against that country's real format.
The step people are most nervous about, so the reassurance sits right next to the fields causing it. Card brand detected as you type; the security-code label becomes 4 digits for Amex. Billing address defaults to “same as delivery”, which my first flow omitted completely.
If I'm asking someone to review their order, I should show them all of it — my first attempt left out the delivery date and the billing address. Every block has its own Edit, returning to that step with values intact. Terms start unticked with a working link; Pay stays disabled until it is ticked.
The minute after paying is the right time to ask about an account, and it's also when people spot mistakes. “Change the address or cancel free for the next 60 minutes”, because this is when people notice. The order is snapshotted, so emptying the cart does not empty the receipt.
Five screens, three named steps you can click back into, and a flow that changes depending on what's in the basket. The whole thing runs.
- Two screens both claiming to be “confirmation” became three honest steps plus a real receipt.
- An all-e-book basket drops to two steps; collection swaps the address form for a shop picker.
- The tour at the top runs the same build, so the claims are checkable rather than asserted.
What I got wrong
In my first attempt every screen had its own copy of the order, which is how they drifted apart.
Before the version above there was one I thought was fine. Then I clicked through it start to finish: the same order came out taxed three different ways, and the confirmation screen had my books going to a city I'd never typed.
Paperback $19.99 · Sales tax $2.99 · Total charged $19.99 My first draft, on the pay button — and it was on all five screens
Anywhere else on a website that is embarrassing. On the button that moves money it is a chargeback, and it was there because each screen held its own copy of the arithmetic. Every frame was fine on its own, which is what happens when you build a checkout one screen at a time.
Three more things the first build got wrong
Instant validation on every keystroke — all reassuring the buyer that their form was fine, while completely ignoring the distraction and cognitive load it caused.
The security code was printed back. There was a “Reveal details” button showing the full card number, and the review step was displaying the CVV. You're not allowed to keep that once the payment's authorised.
Terms arrived pre-ticked, and unlinked. I had assumed consent instead of asking for it, and there was nothing to read anyway.
And two things the finished version still gets wrong
There is no live traffic behind this, so I have no conversion number to wave at you. What I could do was go looking for the places it still lets a shopper down.
“Save for later” tells you nothing after you press it
Press it and the line disappears. Nothing tells you where it went. My miss. It needs a confirmation line and a route back to the saved list, and that list sits outside the scope I set.
Switching to an e-book silently drops your express delivery
The behaviour is right and the delivery is rude. The line I'd put there is “Your basket is all e-books now, so delivery options no longer apply, and the $4.99 express charge has come off your total.” It's not shipped because I hadn't decided where it belongs — so it's an unmade decision rather than a missing one.
Most of what was wrong came from one root cause, so fixing that fixed the rest. Now I do the data model first, before the second screen exists. One place holding the items, the tax rate, the delivery choice and the total, with every screen reading from it. I got to that rule by breaking it first, which is why I'd rather show you this version of the story than a clean one.
What I'd do with a real shop
Everything above rests on other people's research. The gap, plainly: I designed against published averages, not one shop's numbers. Given their traffic and four weeks, this is the order I'd work in — cheapest signals first, and I'd look at the data before putting a question to anyone.
| Kind | What I'd do | What it gives me | |
|---|---|---|---|
| 01 | Framing | Agree what counts as failure: which step starts checkout, what counts as abandonment, which number we're trying to move. | A single definition, so every later figure means the same thing to everyone. |
| 02 | Analytics | Funnel and step-completion reporting, cut by device, payment method and cart contents. | Where people leave, and which audience is worst affected. |
| 03 | Behavioural | Session replays and form-field analytics, just on that step — which field people give up on, where the rage clicks are. | The specific field or moment behind the drop-off. |
| 04 | Ask the people | One open-ended question when someone bails, plus a short follow-up to carts I can still reach. No incentive. | Their reason in their own words, not my guess at it. |
| 05 | Moderated | Six to eight sessions where people buy something they actually want, with their own card, including one deliberate decline. | Why the drop-off happens, and whether a fix would land. |
Quantitative work finds where. Only talking to people explains why. Doing them the other way round is how you end up with confident answers to the wrong question. The rule I'd hold to
The bets, stated as hypotheses
A metric on its own doesn't commit you to anything. These are the four claims the design makes, each one falsifiable.
| Hypothesis | Measured by |
|---|---|
| If total cost is settled before the address form, drop-off at the delivery-to-payment transition falls. | Step-level drop-off |
| If Google Pay sits above the card form, eligible users complete faster and more often. | One-tap vs card completion |
| If a decline preserves form state, more of those shoppers pay on a second attempt. | Recovery rate after decline |
| If checkout is guest-first, completion rises without materially fewer accounts created. | Completion + post-purchase sign-up |
Stated once at the top and again here: the shop is invented, the research is not, and there is no result to claim. The mistake in section four was mine, and fixing it is what taught me the rule in it.