Making an Ecommerce Storefront Work on Mobile

Storefronts are usually designed on a large monitor and then squeezed down. The result is a smaller version of a desktop layout rather than a mobile experience, and it shows in the numbers.

Underneath that there is a second problem, which is about sequence rather than size. On a desktop the purchase is spread across roomy pages; on a phone it becomes a run of small decisions made under time pressure, on a connection that may be unreliable, by somebody who is one notification away from leaving. Layout changes help. Rethinking the order of the decisions helps more, and that work has to happen before the design does.

Design the mobile decision, not the mobile layout

A phone session usually contains four things: someone arrives, finds something, looks at it closely, and either adds it to a basket or leaves. Everything else a store offers is optional and competes for the same limited attention. Write those four steps down for your own catalogue and check each one on a real phone before anyone opens a design tool.

The question each step has to answer is narrow. Can they find the right product from where they started? Can they identify the correct version of it? Do they know the price, the availability and when it will arrive? Is the next step obvious without scrolling back up? Stores tend to lose visitors at the first or second of those, and both are search and variant problems rather than styling problems, which is why a visual refresh leaves them where they were.

The storefront design work at SmartEdge IT Solutions usually starts from a list like that, because it keeps the discussion about a sequence of decisions rather than about a preferred colour.

Navigation has to collapse properly

A category tree that works on desktop becomes unusable on a phone. Decide the small number of things a mobile visitor needs to do — browse, search, view a product, check out — and make those obvious. Menus can be hidden behind a single control; they cannot be a nine-level accordion.

Filters, sorting and search break first. A faceted sidebar with checkboxes communicates what can be narrowed quickly on a large screen; the same control on a phone becomes a wall of small targets with no margin for error. Filters generally work better as a panel that opens from the bottom of the screen and applies when it closes, and sorting works better as an ordinary selection than as a strip of options.

Search deserves more attention on mobile than it usually receives. A long catalogue is tedious to scroll through on a phone, so a search field that is visible without scrolling does more work than any amount of navigation improvement. Make sure it opens the correct keyboard on the device, that suggestions are quick to load, and that recently viewed items cover the case where the visitor knows roughly what they want but not what it is called.

Fixed elements need deciding deliberately. A basket control that is always within reach saves scrolling, and a persistent filter or search bar on a list is useful right up until it covers the price or the add-to-basket button. Check the layout on the smallest screen you intend to support.

Back behaviour counts as well. Menus that do not close when the hardware back button is pressed, or a category link that drops people out of the catalogue on the first tap, are common and easily missed in testing. Mobile navigation should be designed around the back gesture, because customers use it constantly and treat it as navigation rather than as an interruption.

Product pages are where most sessions end

If a visitor arrives from a search result or a shared link, this is the first screen they see, and it has to answer a short set of questions: what is this, what does it cost, is it available, and which version should I pick.

Variants are the usual failure. A dropdown containing twelve sizes is a poor way to choose a size with a thumb, and a row of small swatches is hard to hit accurately and impossible to read if the colours are similar. Where the options can be shown as labelled buttons in a sensible number of rows, that beats hiding them. Where an option is unavailable, say so and keep it visible; removing it leaves people convinced that version does not exist, and they go back to the search results. Designing those controls for a thumb rather than a cursor is a UI and UX design problem, and it is decided long before anyone writes markup.

Availability and delivery belong beside the add-to-basket button rather than in a tab further down the page. An estimate for the destination the visitor actually gave, and a plain statement about stock, remove the reason to leave the page and go and check elsewhere. On a phone that detour is expensive, because closing a tab to check something is a decision most people will not reverse.

Images do two different jobs. The first view has to load at once and describe the product; the rest of the gallery can wait its turn. Make sure the leading image is not lazy-loaded, since a blank rectangle where the product should be is the most damaging single thing that can happen to this page. Allow zooming where detail decides the purchase, and give images explicit dimensions so that text and buttons do not jump as they arrive.

A persistent add-to-basket button, reachable without scrolling back up a long page, is worth more on mobile than anywhere else. On a small screen it is the difference between a sale and an exit.

Page weight is the performance problem

Mobile connections are slower and less consistent. Large unoptimised images are usually the single largest cost on a storefront. Serve appropriately sized images in a modern format, defer what is not needed for the first view, and treat third-party scripts as a cost rather than a free addition.

The weight rarely comes from one large file. It accumulates: the theme, a page builder, a slider, a search extension, review widgets, a recommendations carousel, a chat tool, analytics, and the tags used for advertising and remarketing. Each was added for a reason and each is asked to load on every page. A full website audit should produce a list of everything the page requests, with the owner and the purpose of each entry, because the entries nobody can explain are the ones worth removing.

Third-party scripts deserve particular suspicion. They run on somebody else’s schedule, you cannot fix them when they break, and they are often loaded ahead of the content they were meant to support. Deferring them until after the main content has rendered, or loading them only where they are used, changes the experience more than most redesigns and costs nothing to design.

For imagery, send sizes that suit the screen rather than the largest file you have, use a modern format where the browser will accept one, and set width and height on every image. That last detail sounds trivial and prevents the layout shifting under a visitor’s thumb while they read — the problem customers describe as the page jumping and developers struggle to reproduce.

Checkout is where the design effort belongs

Every additional field, every extra page and every redirect is an opportunity to lose the sale. Ask for the minimum, offer the payment methods your customers actually use, and make guest checkout the default rather than the alternative.

Structure matters as much as field count. A single-page checkout is easy to leave and come back to, provided each step has an address of its own so that a back gesture or a link in an email does not empty the basket. That one detail removes a category of abandoned orders which no amount of visual tidying will fix.

Forms should ask only for what delivery genuinely requires, and ask for it in a form the phone can help with: the right keyboard for a pincode, a date picker instead of a text box for a date, and autofill attributes on the fields a browser already knows. Autofill matters more than it appears, because typing an address on a phone while somebody is watching is precisely the moment a customer gives up.

Error messages belong beside the field that caused them and should say what to do rather than what went wrong. A summary at the top of a long form is invisible to somebody looking at the bottom of it, which is where they are when the failure happens.

Which payment methods to offer is a business decision as much as a design one, and the useful set is whatever customers in the market actually use. Four methods nobody chooses is worse than the one that gets chosen. Where mobile wallets are expected, supporting the platform’s payment sheet usually means integrating fields the provider hosts rather than building anything, and that choice belongs with the provider agreement rather than the design.

That leads to the data question, which belongs in writing rather than in implication. The merchant and the payment provider should have an agreed, documented answer to several questions: which card and account details the store holds itself, which are typed into fields the provider hosts, which the provider stores on its own side, who handles refunds and chargebacks, and who reconciles a payment that settles differently from the order. Keeping the store’s own copy minimal, keeping it out of logs and support tools, and deciding who inside the business may see it are ordinary responsibilities between a merchant and its provider, and far easier to agree at the start than to unpick after a dispute. The payment and order integration work at SmartEdge IT Solutions is easier to build when that boundary is drawn before any code is written.

Measure the journey, not only the page

Speed and conversion get discussed as though they were one number. They are two measurements, and the second lags the first by weeks, which is enough time for a genuine improvement to be written off as a failure.

Split the funnel by device and compare steps rather than totals. Where do mobile visitors drop out relative to desktop visitors? A drop concentrated on product pages points at variants, availability or page weight; a drop at checkout usually means fields, steps or payment methods. The same overall conversion rate can conceal two unrelated problems on two devices, and only the split exposes them.

Check the events themselves while doing this. Mobile sessions end for reasons that have nothing to do with the store, so a low completion rate may partly be a measurement artefact rather than a design fault. Comparing the same journey across devices and across different times of day tells you considerably more than a single figure.

After a change, watch the intermediate steps before the final number. If a lighter product page shortens the time to the first interaction, that is evidence the work helped, even before revenue reflects it.

Test on the devices your customers use

Analytics will tell you which devices matter. Test on those, on real networks, with a thumb rather than a cursor. The problems that emerge are rarely the ones visible in a desktop browser window.

Begin with the list rather than a guess, because the devices that matter are usually a small number of models with a long tail behind them. Testing anything outside that list spends effort on an audience that may not exist.

Then imitate the network. A phone on an office connection behaves nothing like one on a patchy mobile connection, and failing to reproduce the second is why performance work so often disappoints. Throttling in developer tools is not the same thing, but it reliably exposes the pages that cannot cope.

Finally, place a real order on the device. Use the keyboard a customer would use, go through payment as they would, and check that the confirmation arrives in that same phone’s inbox. A portion of checkout problems exist only in that final stretch, and some appear only on a second order from the same account, where a saved address and a stored payment method change the flow entirely.

A pass like this is routine at SmartEdge IT Solutions before launch on our Shopify builds, run against the catalogue and payment methods the client has confirmed rather than the ones used in the demonstration.