Interaction design · Checkout · YourShelf Booksellers
Shoppers quit when the uncertainty rises. I designed a checkout where it can’t.
Problem
Seven in ten online carts are abandoned, and the top cause is extra costs that appear too late (40%, Baymard).
Made
A checkout for a bookshop: guest-first, the full total shown from the first step, and error states that keep what you typed, several failure paths and Includes a clickable prototype.
Status
A Uxcel challenge brief. The shop is invented, the research is real, and nothing shipped, so I'm not claiming a result.
1
The button says what you pay
Pay $43.38 comes from the same component model as the summary.
2
Every cost is named
Sales tax (CA 8.5%), not just "Tax". It changes with the destination country.
3
You know when you pay
Nothing is charged until you press Pay, and you can change or cancel free for 60 minutes after.
My role
Product designer, solo. Research synthesis, flow, UI, microcopy
Scope
Cart to confirmation, desktop, over four weeks
Built with
Figma for the design. The clickable prototype was built with Claude from my Figma file, flows, states and copy
Read time
About 12 minutes
Watch it run · no clicking required
The prototype, from Cart to Confirmation
A scripted run through the built prototype: a removal and its undo, format switching, a rejected postcode, a declined card, and the paid confirmation.
1
of 4 chapters
Removal
Remove is instant, with seven seconds to change your mind
No “are you sure?” dialog. The removal happens, and Undo sits in the toast for seven seconds.
Nothing here is a video. The pointer is a script clicking the same build embedded further down this page.
FAILURE STATES
The run above is the path that works. These are the paths that do not, which is where most of the design work went. Press one and the prototype loads in that state for you to look at.
01 · The problem
40% of shoppers leave because costs show up late, not because they’re high
Seven in ten carts are abandoned, and almost none of it is about how the page looks. Shipping, tax and fees that appear late are the largest single cause, ahead of forced accounts, trust and length. Baymard groups the causes into four fears, and that's how they became my brief.
Why people leave checkout
% of shoppers who left
The price is not the price
Extra costs too high: shipping, tax, fees
40%
Is my card safe here?
Don't trust the site with card details
19%
Forced to create an account
The site wanted me to create an account
18%
Too much asked
Checkout too long or complicated
17%
Baymard Institute, reasons for cart abandonment ↗, US online shoppers (latest survey, page updated Sept 2025). Multi-select, "just browsing" excluded. Another 12% couldn't see the total up front.
So the real problem is timing, and timing is a data problem
The data says
40% leave over extra costs
✕ The obvious read
Costs are too high
Changing the price isn't a solution we can use through design, and price isn't why people abandoned the cart.
My read
It's when a cost shows up, not how big it is
A fee on screen one is information. After you've typed your address, it feels like a trick.
So
It's a data problem, not a screen problem
If every page acts on its own, eventually it will break.
From research to screens
Each fear pointed to a place in the flow, and that told me what to build
For each fear I asked how it happens, why people leave, and where in the flow it happens.
40%
The price is not the price
How
Shipping and tax only show up after the address.
Why
A late cost feels like a trick, not information.
Where
CartDetailsDeliveryPaymentDone
One shared total
→ Decision 01
19%
Is my card safe here?
How
A card form with no sign it's safe.
Why
Handing over card details feels like a risk.
Where
CartDetailsDeliveryPaymentDone
Plain security line above the card fields
→ Decision 03
18%
Forced to create an account
How
An account is demanded before you can pay.
Why
It helps the business but not the user.
Where
CartDetailsDeliveryPaymentDone
Account offer after payment
→ Decision 02
17%
Too much asked
How
The shop's usual long list of fields.
Why
The effort starts to outweigh one book.
Where
CartDetailsDeliveryPaymentDone
Seven required fields, labels kept
→ Decision 02
What I made, in order
Before drawing any screens, I built the data
01
Research notes
I ranked every cause
02
Paper sketches
Ideation part
03
Flow diagram
Steps and detours, no screens yet
04
Money model
Items, tax, delivery and total in one place
05
Failure list
Discovering failure paths.
06
Wireframes, then build
Structure before style
What I got wrong
I kept testing the route I already knew it was working but when I used it like someone actually trying to buy a book, I realized that there are actually couple pathways that can make users really disappointed and be frustrated. (I prefer to make usability testing instead of relying on my judgment)
02 · The decisions
My first draft charged the wrong total. Fixing it gave me a lesson.
It was a prototyping problem. In Figma I linked screen to screen, but I never connected the book format and quantity options to the price container. Each screen showed its own numbers, so they drifted apart. It teached me how much depends on components being connected in the flow properly to distribute information and save time.
Decision 01
Answers fear 1 · the price is not the price
The Pay button and the summary can never disagree
✕ BeforeEach screen kept its own total
Paperback$19.99
Sales tax$2.99
Total charged$19.99
Format and quantity weren't linked to the price. Tax was shown but never charged. Reconstructed.
✓ AfterTax rate named, button repeats total
Screenshot of the working prototype. The button and the summary read the same number.
✓ After · UKTax follows the address
Currency stays USD.
The question
Where should the total live?
✕ I ruled out
Each screen calculates its own total
That's how it drifted. One order, taxed three ways.
Cart
$39.98
Review
$43.38
Pay
$41.20
✕ I ruled out
Fix the maths on each screen, one by one
It would drift again the next time someone adds a promo code.
Cart + promo
$38.10
Review
$43.38
Pay
$43.38
✓ What I chose
Every screen reads the total from one place
The summary and the pay button are the same number, always.
One order model · $43.38
Cart
$43.38
Review
$43.38
Pay
$43.38
The question
A UK address. What should change?
Olivia shops from San Francisco with her US card. The book is a gift for her sister in London, so she switches Country to United Kingdom.
Country
United States
Address line 1
City
State
ZIP code
Sales tax (CA 8.5%)$3.40
Total$43.38USD
She switches the country→
Country
United Kingdom
Address line 1
Town or city
County
Postcode
VAT (20%)$8.00
Total$47.98USD
Changes with the address: field names, formats, taxUSDStays the same: the currency of Olivia's card
✕ I ruled out
Switch the price to pounds
The payer may not be the receiver. Their bank would add a conversion nobody asked for.
Checkout showsLocal money for London, not for Olivia
£37.90
Her US bank convertsAt the bank's rate, plus a 3% fee
£ → $
Her statement saysNot the price she agreed to
$49.42
✓ What I chose
The form and tax follow the address. The price stays in USD
VAT is a real result of where the parcel lands. Currency isn't.
Checkout showsIncludes UK VAT, $8.00
$47.98
Her US bank convertsNothing to convert, no fee
$ = $
Her statement saysSame as checkout
$47.98
Evidence
40% leave over extra costs, the top cause. Another 12% leave because they can't see the total up front.
Trade-off
Weeks spent redrawing five screens I thought were finished.
Decision 02
Answers fears 3 and 4 · forced accounts, too much asked
Seven fields for guests, none for Google Pay, an account only after paying
Before
Which field was which?
After
Full name
City
Still labelled.
The question
How do you make a form feel shorter?
✕ BeforeField names vanish as you type
DeliveryIs the third box city or county?
Only empty boxes say what they want.
✕ BeforeFields the order doesn’t need
Delivery
Full name
Company nameNot needed
Street address
Phone *Required?
Two extra fields, and one blocks payment.
✓ What I chose
Only the fields this order actually needs
Delivery
Full name
Street address
City
State
ZIP code
Mobile (optional)
Every box keeps its name. Seven required, two optional.
The question
When do you ask for an account?
✕ BeforeA sign-up wall before payment
Create an account to continue
You need an account to complete your purchase.
Email
you@example.com
Password
At least 8 characters
Confirm password
Repeat password
Create account & continue
Already have an account? Sign in
No guest option. Shoppers have to make an account to pay.
✓ What I chose
Offer an account after payment, email already filled in for saving time and effort
Paid first, then one password.
Evidence
18% leave over a forced account. 17% because checkout is too long.
Trade-off
No company name, and phone is optional. This needs to be measured whether this cost sales or not, if it is, then company field will come back.
The words
Removing uncertainty by answering before letting user to start creating questions in their mind.
The shopper asks
“How much am I paying?”
Before
Pay
✓ After
Pay $43.38
The shopper asks
“When am I charged, and can I undo it?”
Before
Nothing under the button
✓ After
Charged when you press Pay. Cancel free for 60 min.
The shopper asks
“When will it arrive?”
Before
Standart Shipping
✓ After
Standard delivery, arrives Wed 5 Aug
The flow
What's in the basket decides which steps you see
Cart01
Google Pay jumps straight to Review.
Delivery02
E-books: just an email.
Collect: pick a shop.
Payment03
Review04
Card declined? Back to Payment, fields kept.
Confirmed05
03 · When it breaks
Decision 03
Answers fear 2 · is my card safe here?
When something fails, user's effort does not vanish and they informed appropriately
Each state says what happened in one line, and keeps everything you typed.
Declined card
“Did I lose my order?”
It says up front that nothing was charged. Everything stays filled in, and Google Pay is offered.
Out of stock
“Can I still buy?”
It names the one book that changed. The rest of the order is left alone.
Shop can’t fulfil
“Can I still collect it?”
It names the shop and the book. It stays a pickup: another shop with both books tomorrow, or the same shop a few days later. No order exists yet, so nothing to cancel.
Price changed
“The price is not the price”
It says why in one line and shows old and new totals. Nothing is charged without a fresh tap on Pay.
Payment timed out
“Was I charged or not?”
It checks with the bank and says plainly: not charged. One retry, and it can never charge twice.
E-books only
“Why do you need my address?”
The delivery step drops out. Just an email.
The question
How much belongs on the payment screen?
✕ I ruled out
Show only the card fields and the Pay button
No order total, no card logos, no CVV hint. Shoppers would have to remember what they're paying and guess what the form wants.
Card details
Card number
Expiry date
CVC
Pay
✕ I ruled out
Add every reassurance and nudge
All of it competes with the card number for attention.
Only 2 left at this price!
Card detailsAdd gift wrap? +$4.00
Card number
Expiry date
CVC
Sign me up for offers
Offer ends in09:59
Pay $43.38
✓ What I chose
Keep only what helps while typing a card number
Card detailsVisa
Your card details are encrypted. We never see or store your full card number.
Card number
Expiry date
Security code · 3 digits
Name on card
Total$43.38
Review order
From the prototype. The total stays in view while you type.
The question
What makes a card form feel safe?
✕ BeforePadlock hidden in the footer
It sits below everything else on the page, far from the card field.
✕ BeforeA badge most shoppers don’t recognise
Card details
Card number
Expiry date
Security code · 3 digits
Name on card
Only reassures people who already know Stripe.
✓ What I chose
Informing user about what happens to the card, in plain words, before they deciding to trust.
Card detailsVisa
Your card details are encrypted. We never see or store your full card number.
Card number
Expiry date
Security code · 3 digits
Name on card
Payments handled by Stripe
From the prototype. Read once, before typing. Stripe is a footnote.
Evidence
19% don't trust the site with their card. Another 17% have left over errors or crashes.
Trade-off
Much slower than drawing them. It's also how I found the two gaps below.
04 · How I worked, and what's next
Now I write the data model before I draw the second screen
I started with published research, because the first question was how often, not why
On an earlier project I ran ten interviews. They were great for understanding how people think, but not for showing how often a problem happens. Checkout abandonment is a question about thousands of shoppers, so I started with large published studies of real shoppers. Interviews come later, with a real shop and real cards, to explain why. They're step 04 in the test plan at the end of this section ↓
How I used AI
AI did
Built the working prototype from my specs, and helped me structure this write-up.
I did
Read the research, framed the four fears, made every decision and trade-off, wrote the copy.
Checked
Clicked through as a buyer, not as the author. That's how the two late gaps surfaced.
What I'd measure
Step-level drop-off
Does showing costs before the address form cut drop-off?
Google Pay vs card
Does putting it first raise completion?
Recovery after decline
Do more people pay on a second try?
Completion + sign-ups
Guest-first, without losing accounts?
Gaps I found late
Clicking through as a buyer found two gaps I’d missed
“Save for later” now confirms, and offers Undo
E-book: say how it arrives, drop the delivery line
With a real shop, I’d test in this order
Data finds where. People explain why.-
01 FramingAgree with the team on what counts as an abandoned checkout
-
02 AnalyticsUse the Google Analytics checkout funnel to find the step most people leave
-
03 AnalyticsSplit that step by device, country and payment method
-
04 InterviewsObserve six people buy a real book with their own card
-
05 A/B testRun the new step against the old one and compare completion
05 · What this brief taught me
Never take a flow for granted. There's always a gap.
01
Build the failure flows, then test them
A happy path that works proves very little. The gaps only showed up once I built what happens when things go wrong, and clicked through it the way a shopper would.
In this project
Building the declined card showed that every field had to survive it. Otherwise recovery meant typing the whole order again.
02
Prototyping shows how the parts connect
Once the screens were wired to real data, I could see how each component depended on the others. When you know what you're doing, a prototype gets you there faster than static screens.
In this project
Three screens showed three different totals. I only noticed when I applied a promo code: the cart total dropped, but Review and Pay still showed the old price.
03
Show information where it's needed, and again later
Telling the shopper something once isn't enough. They may need the same fact again further down the flow, so it has to appear on the pages where it matters.
In this project
The e-book says "Instant download by email" in the cart, and "Emailed after payment" at review. The total sits in the summary, and again on the Pay button.
