Ecommerce checkout UX needs diagnosis, not imitation.

A checkout redesign is not the first fix for a checkout problem. First find out where shoppers have to stop, guess or start again.

That diagnosis also needs to reflect South African buying conditions. Copying a pattern from a US or European benchmark may provide a useful starting point, but it does not test local delivery services, payment providers, data constraints or lower-spec phones. A neat interface can still fail at the awkward moment when an address is rejected or a payment response takes too long. These 5 checks are a practical diagnostic. They will not explain every abandoned purchase or predict a conversion result. They will show the team what to inspect, reproduce and compare with its own analytics and customer feedback.

Delivery details create friction before payment begins

The first 2 checks happen before the shopper reaches payment. They concern the true cost of the order and what the store requires from the person buying it.

1. Make delivery costs, timing and options clear early. A fee or arrival estimate that appears only at the final step changes how the shopper understands the purchase. Review the product page, cart and checkout together. Can someone find the likely delivery cost, timing and available options before entering a long set of details?

We have encountered friction around hidden delivery costs, rejected address formats and unclear delivery details in ecommerce work. The integration matters here. We tend to recommend a small number of delivery services we know, including Bob Go and The Courier Guy, rather than choosing from a long list based on features alone.

Test what happens when the address changes. If fees depend on location, explain when the final amount will be calculated. If collection is available, make it easy to compare with delivery. Labels such as “standard” are not useful unless someone can find out what standard means.

Try this: Place test orders using different delivery areas and options. Record where the cost and timing first become clear, whether the total updates correctly and whether a reasonable address format gets rejected. Do not stop after the postcode you use at the office works once. That is not much of a test population, even if the office is lovely at this time of year.

Account and form requirements should earn their place

2. Make guest checkout and account requirements obvious. An account can help with order history and repeat purchases, but shoppers should know whether they need one before they are deep into checkout. If guest checkout exists, give it a clear route. If registration is compulsory, explain why and keep the process proportionate to the purchase.

If someone can create an account after buying, say so. Keep sign-in and password recovery available without making them the only prominent route forward. Then ask someone unfamiliar with the store to find the guest path. Watch for hesitation instead of coaching them through it.

3. Explain form fields and phone-number requirements. Every field asks for time and personal information. Keep the ones needed to fulfil the order, support delivery or meet a genuine operational requirement. Mark optional fields clearly and explain less familiar requests in plain language.

A phone number may be needed by the courier or for an order update. Put that explanation next to the field. Check that address fields accept the formats customers use and that browser autofill works where possible. Then complete the form on a phone with autofill enabled and disabled. Look for unclear labels, rejected formats and information requested more than once.

A shorter checkout can help, but fewer screens do not automatically mean less friction. WooCommerce commonly spreads checkout across 3 or 4 steps. For Lever Arch Lab, we used a two-step checkout: first the customer’s details, then payment. The decision reduced the number of stages while retaining the information needed to process the order. The store is live, but we do not have conversion data proving that the two-step structure caused an uplift.

Recovery matters more than a perfectly clean first attempt

4. Make payment errors specific and recoverable. A message such as “Payment failed” leaves the shopper to diagnose the problem. Review declined, cancelled, interrupted and timed-out states. Each message should offer a safe next step without exposing sensitive payment information.

Can the shopper retry, choose another available method or return to the order without entering everything again? What happens when a payment provider takes time to respond, the connection drops or the page gets refreshed? Confirm that the order status remains understandable and that the interface does not invite a duplicate payment.

Payment access in South Africa has changed. Apple Pay, Google Pay and Samsung Pay did not always work through local payment providers, but providers have started integrating them. Availability still depends on the provider and implementation, so confirm what works in the actual store rather than copying a payment row from another checkout.

Try this: Use the payment provider’s test mode, where available, to reproduce declined, cancelled and delayed responses. Check the message, recovery route and order status for each state. Include an interrupted connection and an accidental refresh.

A checkout is not proven by the path where every service responds immediately and every field is completed correctly. The useful test is not whether checkout works when everything goes right, but whether the shopper can recover when something goes wrong.

South African stores need local tests, not imported assumptions

5. Test the full flow on mobile and slower connections. A checkout can look tidy on a large desktop screen and become difficult on a lower-spec phone. Test product selection, cart, delivery, payment and confirmation. Check text size, tap targets, keyboard behaviour, field visibility and whether the main button remains reachable when the keyboard is open.

Data use and device capability are real constraints in South Africa. Keep pages light enough to remain usable on slower connections and lower-spec phones. Show progress during loading, preserve entered information where feasible and provide a clear retry state when something fails. Accessibility practices also help people use services across different devices and situations; the W3C introduction to web accessibility explains how barriers appear in varied contexts.

The September 2026 Online Retail in South Africa 2026 report summary says internet access reached 79.1% of South African adults while 34.2% shopped online in 2025. It identifies trust, delivery costs, payment access and local-language services among the factors affecting the next phase of ecommerce growth. Those figures do not prove that checkout design explains the difference. They show why a local buying journey deserves investigation. Read the Mastercard and World Wide Worx report summary.

Start with a real-device checkout on a smaller screen. Repeat it with network throttling in the browser’s developer tools. Record where the task becomes slow, difficult to read or loses state. A screenshot of the first screen is not a mobile checkout test.

Turn the findings into a test plan rather than a redesign wishlist. Combine observed problems with checkout-step analytics, support questions, usability sessions and feedback from customers who match the audience. Prioritise each issue by how many people encounter it, how severely it interrupts the task and how confidently the team can test a change. Make one change at a time where practical and agree on the measure before release. If no reliable performance data exists, say so rather than attaching a hopeful percentage to the work after the fact. Baymard’s 2025 checkout research provides examples from leading US and European ecommerce sites. Use them as prompts to investigate, not as South African performance targets. A familiar pattern still needs to work with the store’s products, delivery setup, payment mix and customers. If the team needs to understand behaviour before changing the flow, UX research and strategy can frame the questions and test the journey. UI and product design can turn the evidence into interface changes, while web and app development can implement and test the agreed direction.

On Monday, place an order on the store using a phone and an address outside the team’s usual test area. Use a slower connection. Trigger a failed payment in test mode. Write down every point where the cost, requirement, status or next step becomes unclear.

Choose the most disruptive issue and verify it against analytics, support records or a short usability session. Fix and measure that problem before turning the whole checkout into a redesign project.