Most mobile carts are not abandoned because the price was too high. They are abandoned because the checkout page asked for too much, in the wrong order, in a layout that fights the way people hold a phone. The good news for designers: a large share of those losses can be recovered with front-end decisions only. No new payment provider, no backend refactor, no developer sprint on the order API.
This guide is a hands-on walkthrough of mobile checkout design at the layout level. Every fix below is tied to a specific abandonment cause, so you can argue for it in a design review with something stronger than “it looks cleaner”.
The abandonment cause behind every layout decision
Before touching Figma, map the symptom to the cause. This table is the short version of the whole article.
| Abandonment cause | Design-level fix | Where it lives |
|---|---|---|
| Form feels endless, user loses orientation | Single-column fields, grouped sections, step indicator | Form layout |
| Too much typing on a small keyboard | Autofill attributes, correct input types, no split fields | Input markup |
| “What am I actually paying?” anxiety | Persistent order summary with full total breakdown | Header or sticky bar |
| Forced account creation | Guest checkout as the first, most visible option | Top of step 1 |
| Hard-to-tap or hidden pay button | Full-width sticky CTA in the thumb zone | Bottom of viewport |
| Unexpected costs discovered late | Shipping and tax placeholders shown from step 1 | Summary module |
| Errors that appear only after submit | Inline validation with errors under the field | Field component |
| Trust doubts at the payment step | Security and return cues next to the CTA | Payment block |
| User drifts away through a stray link | Stripped navigation, no promo rabbit holes | Global header |
1. Use one column, always
Two-column form rows are a desktop habit that survives into mobile through careless responsive rules. On a 390px viewport, side-by-side fields become cramped, labels truncate, and the eye has to zigzag instead of scanning straight down.
What to do
- One field per row, full width, no exceptions for “small” fields like postal code or house number.
- Labels above the input, never inside it as a placeholder that disappears on focus.
- Minimum field height of 48px with at least 8px of vertical spacing between rows.
- Group fields into clear blocks: Contact, Delivery, Payment. Three short blocks feel shorter than one long list of twelve inputs.
One permitted exception: card expiry and CVC can sit side by side because they are mentally a single unit and both are short. Even then, keep tap targets wide.
Single step or multi step?
Both work. What matters is that the user always knows how many steps remain. If you use a single long page, add anchored section headers and a sticky progress line. If you use steps, cap them at three and label them with nouns (Information, Shipping, Payment) rather than numbers alone.
2. Make every input autofill-friendly
Typing an address on a phone is the single most expensive action in the whole funnel. Browser and OS autofill can complete a full address block in one tap, but only if your markup lets it. This is a design decision with markup consequences, so specify it in your handoff.
The attributes that actually matter
| Field | autocomplete value | inputmode / type |
|---|---|---|
| type=”email” | ||
| Phone | tel | type=”tel” |
| Full name | name | type=”text” |
| Street address | address-line1 | type=”text” |
| Postal code | postal-code | inputmode=”numeric” |
| Card number | cc-number | inputmode=”numeric” |
| Expiry | cc-exp | inputmode=”numeric” |
| One-time code | one-time-code | inputmode=”numeric” |
Design rules that protect autofill
- Never split a value across inputs. One box for the card number, one for the phone, one for the postal code. Four-box card number widgets break autofill and look clever only to the person who built them.
- Avoid custom dropdowns for country and state. A native select is ugly but fillable. If you must style it, keep a real select underneath.
- Keep the DOM order logical. Autofill engines read sequence. Email, then name, then address lines, then city, then postal code.
- Design a visible autofill state. Browsers paint filled fields with their own background colour. Test your light and dark themes so the text does not become invisible.
- Set font size to 16px minimum on inputs. Anything smaller triggers zoom on iOS and the layout jumps, which users read as a bug.
Also design the address lookup pattern if the project allows it: one field, type three characters, pick from a list. It removes four inputs from the visual load even if the backend is untouched because most lookup services are drop-in front-end widgets.
3. Keep the order summary visible, not buried
On desktop the summary sits in a right-hand column and is always on screen. Responsive templates usually push it to the very bottom of the mobile page, where nobody scrolls. The user then fills in a payment form without being able to confirm what they are buying, and hesitation turns into exit.
The pattern that works
- A collapsed summary bar at the top showing item count and the current total, with a chevron to expand.
- Expanded state shows thumbnails, quantity, unit price, shipping, tax and discount lines.
- The total stays visible in the sticky bottom bar next to the CTA so the user never has to scroll up to check.
- Show shipping and tax as labelled placeholders (“Calculated at next step”) from the first screen. Unexpected costs are the most cited reason for abandonment, and the cure is early disclosure, not clever wording.
Editable without leaving
Let users change quantity or remove an item inside the expanded summary. Sending them back to the cart page resets their mental progress and frequently ends the session. If removal is not possible without backend work, at minimum link back in a way that returns them to the same checkout step.
4. Put guest checkout first, and make it look like the default
Forced account creation is a classic conversion killer, and the fix is almost entirely about placement and visual weight.
Hierarchy to apply
- Express wallets at the very top (Apple Pay, Google Pay, PayPal, Shop Pay). For returning mobile shoppers this is a two-tap checkout and it bypasses the entire form.
- A thin divider with “or continue below”.
- Guest checkout as the primary path: a single email field and a full-width continue button. Do not label it “Guest” in a way that implies a lesser experience. “Continue to delivery” works better.
- Login as a small secondary link (“Already have an account? Sign in”) placed above the form for people who want it, not as a competing button.
- Account creation offered after payment, on the confirmation screen, as a single checkbox or a “Set a password” prompt. Conversion first, relationship second.
If your stakeholders insist on account creation, a compromise that preserves mobile checkout design quality is a pre-checked “Save my details for next time” box inside the guest flow. Same outcome, zero friction.
5. Build for the thumb zone
Phones are held in one hand most of the time. The comfortable reach arc covers the bottom half and centre of the screen. The top corners are the hardest to reach, which is exactly where many templates park the “Place order” button after a responsive collapse.
Button rules
- Full-width primary CTA, sticky at the bottom, minimum 48px tall with 56px being safer for large thumbs.
- Respect the safe area inset so the button is not hidden behind the home indicator or the browser chrome.
- Put the amount inside the button: “Pay 89,90 EUR”. It removes the last moment of doubt and eliminates a scroll back to the summary.
- One primary action per screen. Secondary actions become text links, not outlined buttons of similar size.
- Minimum 8px gap between any two tappable elements so mis-taps do not delete an item when the user meant to edit it.
- Design the loading and disabled states. A pay button with no feedback produces double submissions and support tickets.
Keyboard behaviour
When the soft keyboard opens it eats roughly half the viewport. Make sure the sticky CTA either rises above the keyboard or temporarily hides while an input is focused, and that the focused field scrolls into view with the error area still visible. Test this on a real device, because emulators lie about keyboard behaviour.
6. Validate inline, explain errors in plain language
An error summary at the top of a long form on a phone is a dead end: the user cannot see the field and the message at the same time. Instead:
- Validate on blur, not on every keystroke, and never only on submit.
- Place the message directly under the field, in a colour plus an icon so it is not colour-only.
- Say what to do: “Enter a 5 digit postal code” rather than “Invalid input”.
- Preserve entered data after any error. Nothing ends a mobile session faster than a cleared card form.
- Show a success tick on correctly completed fields in long sections so progress feels real.
7. Remove every exit you did not design on purpose
Checkout is the one page where navigation is a liability. Strip it down:
- Logo only in the header, linking either nowhere or back to the cart.
- No menu, no search, no footer link farm, no newsletter popup, no live chat bubble covering the CTA.
- Promo code field collapsed by default behind a small “Add a code” link. An open, empty promo box sends people to coupon sites and they do not come back.
- Keep legal links present but small, in the footer of the page, since removing them entirely creates its own trust problem.
8. Place trust cues where the doubt happens
Trust badges in the footer are decoration. Trust cues work when they sit next to the action that triggers anxiety, which is the payment block.
- Card brand icons and a lock glyph inside or directly above the card field.
- A one-line reassurance under the pay button: free returns within 30 days, or secure encrypted payment.
- Delivery estimate as a date, not a duration. “Arrives Thursday 22 October” beats “3 to 5 business days”.
- A short note on what happens next: “You will see a confirmation screen before anything is charged” removes fear of a premature charge.
9. Design the confirmation screen as part of checkout
The last screen is often an afterthought, yet it decides whether the customer returns. Include the order number, the summary, the delivery date, a support contact, and the optional account creation prompt. Keep it in the same visual system as the rest of the flow so the transaction feels finished rather than dropped.
Pre-launch checklist for your mobile checkout design
- Every field is full width and 48px tall or more, with a 16px font.
- Every input has a correct autocomplete value and input mode.
- No value is split across multiple boxes.
- Order total is visible at all times without scrolling.
- Shipping and tax are disclosed or flagged on the first step.
- Guest path is the visual default; login is a text link.
- Express wallet buttons appear above the fold.
- Primary CTA is sticky, full width, shows the amount, and survives the soft keyboard.
- Errors appear under the field with actionable wording.
- Header contains no distractions and the promo field is collapsed.
- Tested on a real low-end Android device on a slow connection, not only on a flagship.
How to measure whether the redesign worked
Do not judge a checkout redesign on total conversion rate alone, because traffic mix moves it around. Track these instead:
| Metric | What it tells you |
|---|---|
| Step completion rate per screen | Which step still leaks users |
| Time spent in the address block | Whether autofill is actually firing |
| Field-level error frequency | Which label or format is confusing |
| Share of express wallet payments | How much form friction you removed |
| Rage taps near the CTA | Tap target or sticky bar problems |
| Mobile versus desktop conversion gap | Whether the gap is closing after each release |
Ship one change at a time where traffic allows it. Bundling nine fixes into a single release means you will never know which one earned the lift and which one quietly hurt.
FAQ
Should mobile checkout be one page or multiple steps?
Either converts well when executed properly. Multi step suits long forms because each screen stays short and the keyboard does not fight the layout. Single page suits short forms with few fields. The deciding factor is clarity of progress, not the number of pages.
Does guest checkout really reduce cart abandonment?
Yes. Forced account creation is one of the most frequently cited reasons shoppers leave a checkout. Offering guest checkout as the default path and inviting account creation after payment captures both the order and, often, the account.
Where should the pay button go on mobile?
In a sticky bar at the bottom of the viewport, full width, at least 48px tall, with the amount written inside it. That position sits in the natural thumb arc and stays reachable regardless of page length.
How many fields should a mobile checkout have?
As few as the order genuinely requires. Many checkouts can be completed with email, name, address, postal code, city, country and payment details. Remove company name, second address line, phone number and other optional fields, or hide them behind an expandable link.
Can a designer fix checkout abandonment without developers?
Not entirely, since markup changes such as autocomplete attributes need implementation. But every fix in this article is front-end only: layout, order, spacing, copy and component states. None of them require changes to payment processing, inventory or the order API.
Do trust badges still help?
They help when placed next to the moment of doubt, meaning the card field and the pay button, and when paired with concrete information such as return windows and delivery dates. A row of generic badges in the footer has little measurable effect.
Final thought
Strong mobile checkout design is rarely about inventing something new. It is about removing the desktop assumptions that survived the responsive breakpoint: two column rows, a summary pushed to the bottom, a login wall, a button in the top corner. Fix those four and the rest of the list becomes refinement rather than rescue.