Design the Parts of Your Store Shoppers Actually Use

How to Design an Ecommerce Search Bar

Around half of shoppers reach for search rather than your menu, and they are the ones closest to buying. The field they land in decides whether they get there.

Why search traffic behaves differently

A shopper who searches has already made a decision. They know the product, or at least the category, and they are using your store to locate it rather than to discover it. That makes search sessions the most valuable on your site and the least tolerant of friction: someone browsing “Bags” will happily wander through three subcategories, while someone who typed “black leather crossbody” and got shoes will leave within seconds.

It also means the search field carries a burden the menu doesn’t. The menu is a list of what you have. The field is an empty box, and an empty box tells a shopper nothing about what will work in it. Almost every decision below is about reducing that uncertainty.

The field itself

Open, not hidden. A visible input area outperforms a magnifying-glass icon that expands on click, because an icon asks the shopper to know search exists before they can use it. On desktop this is close to non-negotiable. On mobile, where header space is genuinely scarce, an icon is acceptable, but it should sit in the header at all times, not inside a menu.

Wide enough to read back. A field showing only twenty characters means anyone typing a longer query loses sight of the start of their own sentence and can’t proofread before submitting. Aim to display around thirty characters. This matters more than it sounds: long queries are usually the most specific and most valuable ones, and they’re the ones this truncation hits.

Placeholder text is free advertising. The word “Search” tells a shopper nothing they didn’t already know from the icon. The same space can say what your catalogue contains and teach query format at once; “Search shirts, sarees, jackets” communicates both that search works and roughly what vocabulary it expects. Keep the contrast low enough that nobody mistakes it for text already typed; a dark grey placeholder is read by some shoppers as a query in progress.

A submit button on mobile. On desktop, Enter is universally understood. On mobile it is not: without a visible control next to the field, some shoppers hunt for a way to run the search, and the keyboard’s own “Go” key isn’t reliably recognized as belonging to this field. A visible button removes the question at the cost of a few pixels.

Keep the query after submitting. The field on a results page should still contain what the shopper typed. Clearing it forces anyone refining their search to retype from nothing, and it removes the only on-screen record of what was asked. This single detail does more for repeat-search behavior than most autocomplete improvements.

Scope: the one most stores skip

A shopper deep inside “Bags” who searches for “leather” almost always means leather bags. Very few stores offer any way to constrain a search to the current category, so the query silently escapes to the whole catalogue and returns shoes, belts and jackets. The shopper reads that as a bad search engine rather than a missing feature.

Three solutions work about equally well. Pick one and be consistent:

Field decisions at a glance

The commonest failure

Not any of the above, but treating search as a feature that ships once. A search field is a channel that reports on itself: every query is a shopper telling you what they expected to find. Stores that review that log monthly find synonym gaps, stock gaps and naming errors that no amount of design work would have surfaced.

Where the field sits within the header is covered in the homepage guide.

Predictive Search and Search Suggestions

Autocomplete isn’t a convenience feature. It steers what shoppers search for, which means a poor one actively sends people towards results you don’t have.

Shoppers read suggestions as an inventory

Most stores have autocomplete. Far fewer get the details right, and the gap between those two facts is where the opportunity sits.

The reason it matters more than it appears is shoppers treat the dropdown as a statement about your catalogue. Someone typing “wint” who sees “winter coats” concludes you sell winter coats. Someone who sees nothing concludes you don’t, and a meaningful share abandon search altogether rather than finish the word. The dropdown is being read as a catalogue index, not as a typing shortcut, and it changes what people go looking for.

That reframing is the whole discipline. Autocomplete’s job is not to save keystrokes. It’s to show a shopper the shape of what you sell, before they’ve committed to a query that will fail.

Suggest three things, and make clear which is which

Mixing all three in one unlabeled list is the most common failure. A shopper clicks what they read as a search term and lands on a product page or clicks a product expecting a list and gets one item. Separate the groups with headings, or at minimum give products a thumbnail, so their type is obvious at a glance.

Order matters. Query completions first, because they are what the shopper is trying to do. Products last, because they’re a shortcut for the minority who typed in an exact name.

Handle misspellings inside the dropdown

This is the single biggest weakness in the field, and it’s structural rather than technical. Most stores correct spelling only on the results page, after submission. But a shopper who mistypes and sees no useful suggestions often revises the query in the field several times, or abandons search entirely, and never reaches the page where the correction lives.

The correction has to happen while they’re still typing. “Area ruf” should surface “area rugs” at the top of the dropdown, not after a submit and a redirect.

Keyboard, latency, and the things that feel broken

Keyboard behavior is not optional. Arrow keys move through suggestions; Enter selects the highlighted one; Escape closes the list without clearing the input. Highlight the matched portion of each suggestion so the shopper can see why it appeared.

Debounce the input. Firing a request on every keystroke produces a list that reorders as characters arrive, which causes mis-clicks, the shopper aims at a suggestion and something else moves under the cursor. Wait until the typing pauses.

Never let a slow response overwrite a newer one. Out-of-order responses are the reason suggestions sometimes appear to be for a query two letters ago.

Show something on focus, before anything is typed. Recent searches for returning shoppers, popular queries for new ones. An empty dropdown is a wasted moment at the exact point of highest intent.

On mobile

The dropdown competes with the keyboard for space, and the keyboard usually wins. Show fewer suggestions rather than a scrolling list that’s mostly hidden. Make each row a full-width tap target. And don’t put a close button where the keyboard’s own controls sit.

What good looks like

A shopper types three characters and sees: two or three query completions in their own words, one category jump, two products with prices. They can tell those apart at a glance, arrow down to one, press Enter, and land where they expected.

Designing No-Results and Empty Search States

“0 results found” is not an answer, it’s a dead end. And it’s usually wrong, you almost certainly have something relevant.

The page is making a claim, and the claim is false

A zero-result page is the clearest possible signal that a store doesn’t stock what the shopper wants. Most of the time that signal is inaccurate. The catalogue has the product; the query just missed it.

That gap is the entire problem. A shopper doesn’t distinguish between “we don’t sell this” and “our search didn’t understand you”, both look identical from their side, and both end the session. So the first job of a no-results page is to make the difference visible.

Diagnose before you respond

Four things cause it, and each has a different fix.

The third case is worth designing carefully because it’s the most common and the least handled. A shopper who applied four constraints doesn’t want to start over; they want to know which constraint was the expensive one. “No exact matches. Showing black leather crossbody bags, ignoring the price limit, 6 results” answers that in one line and keeps them on the page.

Three rules for the page itself

Never return an empty screen. Whatever the cause, the page must contain something actionable: the nearest category, popular products, best sellers. A page with nothing on it ends the session; a page with imperfect products at least keeps someone looking.

Show them what you searched for. Print the interpreted query back; “No exact matches for leather crossbody”, because that’s frequently the moment a shopper spots their own typo. When you’ve auto-corrected, show both the correction and a one-click way to insist on the original spelling. Some queries really are unusual brand names.

Keep the field filled and prominent. The most likely next action is a revised query. Making someone start from an empty box, or hunt for the field again, turns a small failure into an exit. On a no-results page, the search field should be the most prominent thing on screen.

Say what you can’t do, honestly

When a product genuinely isn’t stocked, a store that says so keeps more trust than one that pads the page with unrelated items. “We don’t currently carry hiking poles” plus a link to the nearest category and a notify-me option is a better outcome than four pages of tangentially related results that waste the shopper’s time and then still fail.

The log is free research

Your zero-result queries are the cheapest source of truth you have about the words your customers use and the products they expect you to carry. A query that repeatedly returns nothing is either a synonym you should add or a product you should stock.

Review it monthly. It takes fifteen minutes and it tends to be more useful than a customer survey, because it records what people did rather than what they say they’d do. The same log feeds directly into naming your categories.

Ecommerce Filters and Facets

Filters look like an interface problem and behave like a data problem. Most broken filter panels are working exactly as built on attributes that were never designed to be filtered.

Four kinds of facet, and they don’t work alike

Range facets deserve particular care. A price slider looks elegant and is genuinely difficult to operate precisely on a phone, especially at the low end where most products cluster. Preset bands like under $5, $5–10, and $10–20 are faster for most shoppers, and you can derive sensible bands from your own price distribution rather than guessing.

The logic rule that surprises people

Within one facet, selections combine with OR. A shopper ticking Red and Blue wants both colors, not products that are somehow both.

Across facets, they combine with AND. Red and Leather and under $20.

Get this backwards, as some platforms do out of the box, and every second selection empties the page. It’s worth testing explicitly, because it looks like a data problem and isn’t.

Counts are a promise

“Leather (34)” tells a shopper whether the filter is worth applying, and it’s one of the highest-value additions to any panel. But the count has to be calculated against the filters already applied, not against the whole catalogue. A count that says 34 and delivers 6 is worse than no count at all, because it was read as a commitment.

Counts must also update as other facets change, which is computationally awkward and why some stores quietly drop them. Dropping them is the right call if you can’t keep them accurate.

Related rule: options that would return nothing should be disabled rather than hidden. Disabling shows the shopper the boundary of your catalogue; hiding makes the panel appear to change shape unpredictably.

Facets are per-category, not global

Screen size means nothing in a category of kettles. A global filter set applied everywhere produces panels full of facets that don’t narrow anything, and the useful ones get buried among them.

Define facets per category. And hide any facet with only one value in the current result set, it can’t narrow anything, so it’s pure noise.

The URL is part of the design

A filtered view someone can copy, share, bookmark or return to via the browser’s back button is a filtered view that works. If applied filters live only in page memory, a shopper who opens a product and comes back finds their work gone, and, importantly, usually concludes your catalogue is smaller than it is rather than that your filters reset.

Encode filter state in the URL. Decide separately, with the listing page guide, which of those URLs search engines should be allowed to see; the two questions are often conflated, and they’re independent.

Ordering values inside a facet

1. Alphabetical for brands — people scan for a name they already know
2. Logical for sizes — S, M, L, XL. Never alphabetical, which produces L, M, S, XL and is the clearest possible sign nobody checked
3. Frequency for colors — the ones you actually stock in quantity first
4. Ascending for ranges — always

Where a facet has more than about eight values, show the most common few and a “Show all” control rather than a scrolling sub list.

Announce changes, don’t just make them

When a filter drops the result count from 248 to 31, that change needs to reach a screen reader as well as an eye. A live region on the result count is a two-line fix that makes the entire panel usable without sight, and it also helps sighted shoppers who are looking at the panel rather than the grid.

Checkboxes need real labels, not styled divs. A filter panel is one of the densest interactive areas in a store and it’s usually the least tested with a keyboard.

Sorting Options for Product Listings

Sorting is the control shoppers understand least. Many believe it filters and then act on a list they think is narrower than it is.

Relevance is a recipe, not a sort order

Every other option is objective. Price ascending is price ascending; there’s nothing to decide. Relevance is whatever you define it to be, and because it’s almost always the default, it is the single most consequential piece of merchandising logic in your store.

A workable blend weighs four things: how well the product matches the current context, whether it’s actually available, how well it converts, and how recently it arrived. The proportions depend on your catalogue. What matters is that someone owns the recipe and can explain it. An unexamined relevance sort drifts towards whatever the platform shipped, which is usually alphabetical or by creation date wearing a better label.

Test it the honest way: open your three biggest categories and look at the first six products under the default sort. If they aren’t the ones you’d hand a customer who walked in and asked, the recipe is wrong.

Availability belongs in the sort

Out-of-stock products at the top of any sort order waste the most valuable screen space you have. Push them down universally, whatever sort is applied, rather than relying on the shopper to find and tick an “in stock” filter.

Whether to show them at all is a separate call. For a product that’s returning, keeping it visible with a notify-me option is worth more than hiding it. For a discontinued line, hiding is cleaner.

Ties need a second key

Sort a category where forty products cost $12 by price and you get an arbitrary order, one that often reshuffles between page loads, because the underlying query has no stable tiebreak. To a shopper comparing two visits, that looks broken.

Always define a secondary sort key. Popularity or product ID both work; what matters is that the order is deterministic.

Sorting has to survive the journey

A shopper who sorts by price, moves to page two, opens a product, and comes back should find the same sort applied and the same scroll position. This is the same requirement filters have and it breaks in the same place, state held in memory rather than in the URL.

It’s worth being specific about the cost. When sort resets on return, the shopper doesn’t know it reset. They see a different first product and quietly conclude the store is disorganized.

The confusion with filtering

Because sort and filter usually sit next to each other in one toolbar, a real share of shoppers apply a sort and believe they’ve narrowed the list. They then behave as though the twelve products visible are the only ones that match.

The result count is what corrects them: if the number doesn’t move after a sort, they can see it didn’t filter. Keeping the count adjacent to the sort control does most of this work for free. Labelling the control “Sort by” rather than a bare icon does the rest.

Alphabetical is nearly always wrong

It exists in most platforms by default and serves almost no ecommerce purpose. Nobody shops for a jacket alphabetically. The genuine exception is reference catalogues; spare parts, chemicals, books by title, where shoppers arrive knowing an exact name and are scanning for it.

On mobile, sort deserves its own control

Burying sort inside the filter drawer means a shopper who only wants to reorder must open filters, find sort, choose, and apply. A separate button costs one slot in the toolbar and removes three taps from a very common action.

Show the current sort on the button; “Sort: Price, low to high”, rather than a bare label. It’s the only place the shopper can check what’s applied.

Anatomy of an Ecommerce Product Card

The card is the most reused component in your store, and it appears in five places that need different things from it.

This page is about the card as a component; how it changes by context, and what has to stay constant.

Same component, five jobs

The mistake is building one card and using it everywhere. A cross-sell card carrying four badges and a star rating pulls attention away from the page it’s sitting on, which is the page you actually want them to act on.

Information order follows the decision

A shopper scanning a grid asks three questions in sequence: what is it, is it for me, what does it cost. Image, then distinguishing detail, then price.

Where price leads, clearance, grocery, spare parts, that’s a deliberate reversal for a catalogue where price is the primary variable, not a default to copy.

Lead the title with the distinguishing word. In a grid of jackets, every title starting “Men’s Jacket —” burns the first line on all of them identically. The word that separates this product from its neighbor has to arrive before the truncation does. This usually means restructuring product titles, not the card.

Constants that hold everywhere

Fixed line counts. Truncate titles to the same number of lines on every card. Variable-height cards break grid alignment, and a misaligned grid is measurably harder to scan than an aligned one, the eye loses its horizontal rhythm.

Reserved image space. A card that grows when its image loads shifts everything below it, and shoppers mis-tap during the shift. Declaring the aspect ratio in advance fixes it. See choosing image ratios.

Same element in the same place. If price sits below the title on one card and beside it on another, comparison stops working. This is the single rule that matters most and the one most often broken by “featured” card variants.

Decide what the whole card does

Making the entire card one link is the simplest option and usually right. The moment you add a second action; quick add, wishlist heart, you have a card with nested interactive regions, which needs deliberate handling rather than a div with a click listener.

Practically: the card is a link, the secondary controls are buttons inside it, and each is reachable by keyboard in a sensible order. Getting this wrong makes the entire grid unusable without a mouse, and it’s invisible until someone tries.

What to leave off

Long descriptions. Multiple calls to action. Every badge you have. Star ratings where you have three reviews.

The card’s job is to earn a click, not to make the sale. Anything that doesn’t help someone choose between this card and the one beside it is noise, and on a grid of twenty-four cards, noise multiplies.

A useful test

Print a screenshot of your grid, cover the images, and try to tell the products apart. If you can’t, your titles or your card content aren’t doing their job, and that’s exactly the position a shopper is in when every product photograph looks similar, which in most catalogues is most of the time.

Product Badges and Promotional Labels

A badge is an interruption you’ve chosen to place. One works. Four cancel each other out and make the grid look like a sale bin.

Badges flag the exception

That’s the whole job. Their value comes entirely from scarcity, a badge means “this one is different from the others around it”, and if every card has one, none of them says anything.

Which makes this a discipline problem rather than a design problem. The visual design of a badge is trivial. Deciding which products don’t get one is the work.

Four kinds, competing for the same corner

That last row deserves scrutiny. “Bestseller” applied by hand to whatever needs a push isn’t a badge, it’s advertising wearing a badge’s clothes, and shoppers who notice one arbitrary bestseller stop believing the rest of the page. If you can’t compute it from sales data, don’t show it.

Rank them and enforce one

Decide the order once; state, then promotional, then attribute, then social, and let the card display only the highest-ranked badge that applies.

Without a rank, a product that is on sale, organic, and low in stock ends up wearing all three, and the shopper reads none of them. With a rank, the low-stock badge shows, which is the one that changes their behavior.

Two badges is the practical ceiling, and only when they’re from different families and both genuinely matter.

Color cannot carry the meaning

Red for sale and grey for sold out reads clearly to most people and not at all to some. Every badge needs a word.

Contrast is the quieter failure. Badges sit on top of product photographs, and a semi-transparent white badge that looks fine on a dark product vanishes on a pale one. Test against your lightest and darkest images, not against a grey box. A solid background behind the badge text is unglamorous and reliable.

Placement collides with everything else

Top-left is conventional, and it’s also where the wishlist icon often sits. Bottom-left runs into swatches. Bottom-right runs into quick-add.

Pick one corner and hold it across the catalogue. Then check the worst case: a product with a badge, a wishlist heart, a swatch row and a quick-add button, all on one card, on the narrowest phone you support. That combination exists somewhere in every catalogue and it’s rarely designed for.

Sale badges have to be true

“20% off” against a price raised the week before is the one badge carrying real risk. Several markets now require the comparison price to be the genuine lowest price of a preceding period, and enforcement has been increasing.

Beyond the legal point, an invented discount is exactly the kind of staged information that costs you every other claim on the page. Persuasion without dark patterns sets the standard.

Write them short and plain

Two words at most. “Only 3 left” works. “Limited availability, order soon!” is a sentence, and a badge that needs reading isn’t a badge.

Avoid stacking a percentage and a label: “SALE 20% OFF” says one thing twice.

Choosing Product Image Ratios

Which ratio you pick matters far less than picking one and holding it across every product you will ever list.

This page is about choosing the ratio and living with it.

Three ratios cover almost everything

If your catalogue is broad, or likely to broaden, choose square. The stores that regret their ratio are the ones that picked portrait for a clothing line and later added bags, candles and homeware, every one of which now sits in a tall frame with air above and below it.

Declare the ratio in the markup, always

An image with no reserved space collapses the layout until it loads and then pushes everything down. That shift is what makes a shopper tap the wrong product, and it counts against you in page-experience scoring.

Reserving the box costs one attribute and is the single highest-value change in this whole topic.

Card and detail view don’t have to match

A card can crop tighter than the product page, a closer crop reads better at small sizes, where a full-length shot becomes a smear.

But the card ratio must be identical for every product. The eye reads a ragged grid as a broken one, and it does so faster than it reads any individual product.

Plan for images you don’t control

Supplier-fed catalogues arrive in mixed ratios, and the fix is a padding rule rather than a cropping rule: fit the image inside your ratio on a consistent background, rather than cropping to fill, which cuts the tops off shoes and the sides off sofas.

Decide the background color once. White is safe. Any tint has to work behind every product you’ll ever stock, including white ones; a pale grey background and a white shirt is a photograph of nothing.

Leave a safe area

If badges sit top-left and swatches bottom-left, the crop needs margin in those corners or the badge lands on the product.

Set the safe area at the same time you set the ratio, not after the first collision. Retrofitting it means recropping the whole catalogue.

One practical note on file size

The ratio decision often gets made alongside a resolution decision, and it’s worth separating them. The card image needs to look sharp at its rendered size on a high-density screen, roughly twice the CSS dimensions, and no more. Serving product-page-sized images into a grid of twenty-four cards is one of the most common causes of a slow listing page.

Product Page Information Hierarchy

A product page has one job: answer every question standing between a shopper and a decision, in the order they ask them.

The order shoppers actually work in

Most shoppers open a product page and go straight to the images. Not the title, not the price, the pictures. Only after establishing what the thing looks like do they check whether it’s the right one, and only then what it costs.

That’s a useful correction to how these pages usually get designed, which is title-first because that’s how a document is structured. The image is not decoration at the top of the page; it’s the first thing being read.

The sequence that follows the shopper:

The critical boundary is between 6 and 7. Everything a shopper needs to press the button should sit above it. Everything that supports or reassures sits below.

The buy section is where most pages fail

The area holding price, variants, availability and the button is the highest-value real estate in the store, and it’s routinely the messiest, because every team wants something in it. Finance wants the EMI option, marketing wants the badge, logistics wants the delivery promise, and the wishlist wants a heart.

Two rules keep it usable. One primary action, visually dominant. Add to cart is one color and one weight; wishlist, compare and share are quieter. Nothing between the variant selector and the button, a shopper who has chosen a size expects the button next, and an inserted banner reads as a step they’ve missed.

Answer the cost question completely

A price that isn’t the price is the most expensive omission on the page. If delivery is chargeable, if tax is added, if there’s a minimum order, the product page is where to say it, not the cart, and certainly not checkout. Many stores show only the item price and let the shopper discover the rest two pages later, which is the single most-cited reason people abandon.

Long pages are fine, hidden information is not

There’s no prize for a short product page. Shoppers scroll willingly when the first screen has earned it. What loses them is information that exists but can’t be found, a returns policy three clicks away, a size guide behind an unlabeled icon, specifications collapsed by default with no indication of what’s inside.

The test: for every question a shopper might reasonably ask, can they find the answer without leaving the page? If not, that’s a hierarchy problem, not a content problem.

On mobile

The single column makes the order above literal, and the buy section drops below the images. That’s the reason for sticky add-to-cart, not to be aggressive, but because on a phone the action is otherwise a scroll away from every decision that leads to it.

Ecommerce Product Image and Media Galleries

Images are the first thing most shoppers look at, and the only way they can inspect a product they can’t hold.

The gallery replaces picking it up

In a shop, a customer turns the thing over, checks the weight, looks at the stitching, holds it against themselves. Online, the gallery does all of that or nothing does.

Which reframes what “enough images” means. It’s not a number, it’s a checklist of what a shopper would physically do.

The scale shot is the one most often missing and the one that generates most returns. A ring photographed alone tells you nothing about its size; the same ring on a hand tells you everything.

Use thumbnails, on mobile too

Desktop galleries almost universally use thumbnails. Mobile galleries mostly use dot indicators or nothing, and the result is that shoppers miss images entirely, or swipe past the last one into a dead end and don’t know whether they’ve seen everything.

Thumbnails work on both. They show how many images exist, let someone jump to the one they want, and remove the guessing. If space is tight, a partially visible next thumbnail at the edge of the strip signals more without needing a full row.

Zoom that actually works

Roughly a quarter of stores either don’t offer usable zoom or supply images too low-resolution to reward it. Both are the same failure: a shopper tries to inspect the material and gets a blurred rectangle.

Zoom needs images with real resolution behind them, enough that a detail crop stays sharp. On desktop, hover-to-zoom or click-to-enlarge both work. On mobile, pinch-to-zoom must not be disabled, which happens by accident more often than by design.

Video answers a different question

Static images explain what a product looks like. Video explains how it behaves, how a fabric moves, how a mechanism opens, how large something is when a person handles it. It’s worth the effort for products where behavior is the purchase question and unnecessary where it isn’t.

Keep it in the gallery rather than in a separate tab, muted by default, and never autoplaying with sound.

The rules that hold across all of them

Match the image to the selected variant. A shopper who picks green and still sees blue doesn’t trust anything else on the page.

Keep the aspect ratio consistent across the gallery so the page doesn’t jump between images. Consistent with the card ratio is a bonus, not a requirement, see choosing image ratios.

Write real alt text. “Product image 1” is worse than nothing. Describe what’s shown, because it serves both assistive technology and the search engines reading your page.

Load the first image eagerly and the rest lazily. The primary image is the most important thing on the page and should never be behind a lazy-load threshold.

Designing Product Variant Selectors

The variant selector is the last decision before the button. Every ambiguity in it becomes either an abandoned cart or a return.

Match the control to the data

The dropdown is the default in most platforms and is almost always the wrong choice. It hides the options, requires a tap to discover them, and gives no indication of how many there are, a shopper can’t see at a glance whether you stock their size until they open it.

Show what’s unavailable, don’t remove it

An out-of-stock size struck through or greyed tells a shopper the product exists in their size and might return. Removing it silently tells them you don’t make it, which is a different and worse message.

Better still, pair it with a notify-me. A shopper who wanted a sold-out size is the highest-intent email address you’ll capture all week.

Never let a shopper select an impossible combination

For products with two or more variant axes; color and size, capacity and finish, the second selector must update against the first. If Green is only made in Medium, choosing Green should immediately show Small and Large as unavailable.

The alternative, where a shopper picks a valid-looking combination and gets an error on add-to-cart, is one of the most frustrating experiences on a product page, because they’ve done everything right.

Require a choice, and say so clearly

When nothing is selected, the add-to-cart button should either be disabled with a visible reason or enabled with a clear prompt on click, “Please choose a size”. What it should not do is add an arbitrary default to the cart, which produces a specific and painful kind of return.

Pre-selecting is acceptable in one case: where the shopper arrived from a link that specified a variant.

Label the selection, always

“Size: M” beside the selector, not just a highlighted button. The highlight is a visual state that some shoppers can’t perceive and that assistive technology may not convey. The label is unambiguous and it’s the only thing a shopper can check before pressing the button.

The URL should carry the variant

A shopper who has chosen green in size M and sends the link to a friend expects the friend to see green in size M. If the URL doesn’t carry the selection, they get the default and a confused conversation.

This also matters for returning shoppers, browser back, and anything that reloads the page.

Update everything together

Selecting a variant should update the image, the price, the availability, the SKU and the delivery estimate, as one change, immediately. A page where the image updates but the price lags is one where a shopper sees a price they may not be paying.

On mobile

Buttons, not dropdowns, for the reasons above, and each one needs a tap target around 44 pixels square. A row of small size buttons packed tightly is one of the easiest mis-taps in a store, and a mis-tapped size that isn’t checked is a return.

Size Charts and Specification Information

Nine in ten apparel stores leave shoppers unable to judge fit properly. It’s the most expensive gap on a product page, because the cost arrives twice, first as a lost sale, then as a return.

Fit uncertainty is a conversion problem before it’s a returns problem

A shopper who can’t work out whether something will fit does one of two things: buys two sizes intending to return one or doesn’t buy. Both are expensive. The first is usually treated as a logistics problem and is actually a content problem.

A large share of benchmarked stores provides sizing information that’s unusable or absent entirely. That’s not a design failure, most of them have a size chart. It’s that the chart doesn’t answer the question the shopper is asking.

A size label is not sizing information

“M” means nothing across brands. What a shopper needs is measurements, and ideally two kinds:

Give both, labelled clearly as which is which. Stores that give only one leave half their shoppers unable to use the chart, measuring a favorite shirt is easier for some people than measuring themselves, and vice versa.

Add fit notes in words. “Runs small, consider sizing up”, “relaxed through the body”, “model is 175cm wearing M”. Those sentences do more work than the table, because they’re the answer rather than the raw data.

Put it where the decision happens

A size chart linked next to the size selector gets used. One in a tab below the fold, or in the footer, does not.

Open it in place, an overlay or an inline expansion, rather than a new page. A shopper who loses the product page to check a measurement often doesn’t come back to the same scroll position, and every friction here compounds because they’re already uncertain.

Specifications are the same problem for non-apparel

For electronics, tools, furniture and parts, the specification sheet is the equivalent of the size chart, and it fails the same way: present but unusable.

Use a table, not a paragraph. Specifications buried in prose can’t be scanned or compared.

Use consistent labels across the catalogue. If one product says “Weight” and another says “Item weight” and a third says “Mass”, nothing can be compared and nothing can be filtered, the same attribute discipline that makes filters work.

Include the dimension people actually need. For furniture, that’s often the doorway dimension rather than the product dimension. For appliances, the clearance required rather than the cabinet size.

Write units explicitly and give both where your market is mixed.

Compatibility deserves its own treatment

Where a product only works with certain other products, phone cases, printer cartridges, spare parts, a specification table is not enough. A shopper needs to check their item, and a list of two hundred compatible models is not a check.

A search or filter over compatible models converts far better than a list, and it prevents the return that follows a guess.

How to Write and Structure Product Descriptions

A description isn’t an essay about the product. It’s a set of answers, arranged so that a shopper who reads only the first two lines still gets the important ones.

Almost nobody reads it top to bottom

Shoppers scan a description looking for a specific fact, will it fit in my bag, is it machine washable, does it come with the cable. They read in fragments, and they give up quickly.

Which means structure carries more weight than prose. A beautifully written paragraph that buries the washing instructions in its fourth sentence has failed a shopper who came for the washing instructions.

The structure that works:

The opening lines are the only part you can assume gets read. They should contain the thing that distinguishes this product from the near-identical one on the next tab.

Write features as consequences

“Water-resistant coating” is a feature. “Survives a monsoon commute” is what the shopper is buying. Neither works alone, the first is checkable, the second is meaningful, so pair them: Water-resistant coating, so a monsoon commute won’t reach your laptop.

This is the difference between a description that reads as a specification and one that reads as an answer.

Answer the questions you already know about

Your support inbox, your product reviews and your returns reasons contain a list of what your descriptions fail to say. If four people asked whether the strap is adjustable, the description should say whether the strap is adjustable.

This is the cheapest description improvement available and almost nobody does it systematically. Review the questions monthly and fold the answers back into the copy.

What not to do

Don’t paste the manufacturer’s copy. Every store selling that product has the identical text, which helps neither the shopper nor your search visibility.

Don’t write for keyword density. “Buy leather bags online” repeated five times reads as spam to a person and adds nothing for a search engine that’s been ignoring that tactic for a decade.

Don’t hide the deciding fact in the middle. If a product doesn’t include batteries, that belongs in the key points, not sentence nine.

Don’t over-claim. A description that oversells produces returns, poor reviews, and a support burden that costs more than the sale.

Length follows consideration

A $5 phone case doesn’t need four paragraphs. A $500 sofa does; someone spending that much wants to know about the frame, the fill, the fabric rub count, and what happens if it doesn’t fit through the door.

Match the depth of the description to the depth of the decision.

Format for the scanner

Short paragraphs. Real bullets for lists. Bold on the words that carry the fact, not on whole sentences. Subheadings if the content runs long.

And where a description is genuinely long, an expandable “read more” is fine, provided the first section standing alone still contains the deciding facts. A collapsed description that hides essential information is a hierarchy failure, not a space saving.

Ratings and Reviews on Product Pages

Shoppers go looking for the bad ones. A page of unbroken praise is read as a page of filtered praise.

What shoppers are actually doing

Reviews are near-universally read before a purchase, but the behavior is more specific than “reading reviews”. A large majority deliberately seek out negative reviews, not to be talked out of the purchase, but to find out what the worst case looks like and whether they can live with it.

That changes the design brief entirely. The job is not to display praise. It’s to let someone assess risk quickly.

Which is why a perfect five-star average performs worse than a slightly imperfect one. Shoppers read a flawless score as suspicious, and the trust sweet spot sits a little below perfect. A store showing 4.4 with a handful of critical reviews it has replied to is more credible than one showing 5.0.

Count matters as much as score

A 5.0 from two reviews carries less weight than a 4.3 from four hundred, and shoppers weigh it that way instinctively. Always show the count next to the score, at the same size, a bare star rating without a count invites the assumption that the count is small.

Below a handful of reviews, consider not showing a score at all. An average of two ratings is noise presented as a number.

The summary is what most people read

Most shoppers never scroll into individual reviews. So the summary block has to carry the load:

The distribution bars are undervalued. An average of 4.2 built from mostly fives and a few ones is a different product from one built entirely from fours, and only the distribution shows that.

Make individual reviews assessable

Show the date. A glowing review from four years ago says little about the current version.

Show what they bought. Which size, which color, verified purchaser or not. A negative review about fit is only useful if you know which size they ordered.

Structured attributes beat free text for fit. A simple “runs small / true to size / runs large” slider aggregated across reviewers answers the most common apparel question in one glance, and it feeds back into size charts.

Sort by helpfulness by default, not recency. And let people sort by lowest rating, because that’s what a large share came for.

Reply to the critical ones

A negative review with a considered reply from the store reads better than no negative reviews at all. It demonstrates that problems get handled, which is the actual question behind “let me read the bad reviews”.

Reply to the substance, publicly, without defensiveness. Shoppers are reading the reply as much as the review.

Never filter out criticism

Removing or suppressing negative reviews is both increasingly regulated and self-defeating, it produces exactly the flawless page shoppers distrust. Moderate for abuse and irrelevance, never for sentiment.

If you have no reviews yet

Don’t fake them, and don’t show an empty five-star widget. Ask recent buyers directly, seed with genuine feedback you already hold, and in the meantime lean on the other reassurance you can honestly offer, clear returns terms, real photographs, a visible contact route.

Delivery, Pickup and Return Information on Product Pages

Delivery cost and returns terms decide the purchase, and most stores make the shopper find them two pages later. By then a share of them have gone.

These are product page facts, not policy page facts

A shopper deciding whether to buy is asking four questions: what will delivery cost, when will it arrive, can I collect it, and what happens if it’s wrong. All four are part of the price and the risk of this specific product, which makes the product page the right place for them.

Most stores put them in the footer, and the result is that unexpected cost at checkout becomes the most-cited abandonment reason in the industry. The cart is often described as where that gets fixed. It’s actually where it gets measured; the fix is here.

Give a date, not a duration

“Ships in 3–5 business days” requires the shopper to do arithmetic including weekends and holidays, and they will do it pessimistically. “Arrives by Thursday 14 May” requires nothing.

Where delivery varies by location, a pincode or postcode field that returns a real cost and a real date is one of the highest-value additions to any product page. It converts an unknown into a fact at the moment the decision is being made.

Say what free delivery actually means

If free delivery has a threshold, state the threshold. “Free delivery over $12” on a $6 product is honest and useful, it tells the shopper what to do next, and it’s the sentence that turns a single-item cart into a two-item one.

“Free delivery available” with no condition is the version that produces a surprise later.

Returns: the window, the cost, and the method

Three facts, and shoppers need all three:

Who pays for return shipping is the one most often left out and the one that most affects a hesitant purchase. If returns are free, that’s a strong selling point and belongs near the button. If they’re not, saying so plainly costs you some sales and saves you the disputes.

Non-returnable items need saying loudly. Personalized goods, hygiene products, final-sale items. On the product page, near the button, not in a linked policy.

Pickup, where you offer it

If a shopper can collect, show whether this product is available at a nearby location, not merely that pickup exists as a service. “In stock at Banjara Hills, ready in 2 hours” is a conversion event. “Click and collect available” is a hyperlink.

Placement

Near the buy button, a compact block of three or four lines, each expandable if the detail runs long. Not a tab at the bottom of the page, and not an icon strip with no words.

This is the same content the cart shows later. Showing it in both places is deliberate, not duplication. The product page version informs the decision, and the cart version confirms it.

Sticky Add-to-Cart Design

On the phone, the buy button is a scroll away from every piece of information that justifies pressing it. A sticky bar closes that gap, if it carries enough to act on.

The problem it solves

A product page on a phone is a single long column. The shopper reads the description, checks the specifications, works through the reviews, and the button is now several screens above them. To buy, they must scroll back up, find their place, and possibly re-confirm a variant they can no longer see.

That’s the gap. Sticky add-to-cart isn’t a growth tactic; it’s a fix for a layout consequence.

It needs more than a button

A bar containing only “Add to cart” is a trap. A shopper who scrolled down to read reviews and taps it may not have chosen a size, may not remember the price, and may not have the product they think they have if they scrolled past a related item.

A useful sticky bar carries four things:

Where no variant is selected, the button should open the selector rather than add a default.

When it should appear

Not immediately. A bar that’s present when the real button is also on screen shows the same action twice and eats vertical space on the smallest screens.

Trigger it when the main buy section scrolls out of view and let it disappear when the buy section comes back. The transition should be quick and unobtrusive, a slide is fine, a bounce is not.

What it must not do

Don’t cover content. The bar occupies permanent screen space, so pad the bottom of the page by its height. Otherwise the last section of the page, often the reviews, sits permanently underneath it.

Don’t stack it with other sticky things. A sticky header, a sticky bar, a cookie banner and a chat bubble leave a phone showing about a third of a page of actual content. Decide which one wins.

Don’t make it tall. One row. Anything more is a panel that follows people around.

Don’t put it on desktop by default. On a wide screen the buy section usually stays visible in a column beside the content, which solves the problem already. A sticky bar there is redundant, and a sticky bar plus a visible button is two of the same thing.

Accessibility

The bar must be reachable in the keyboard tab order at a sensible point, not appended to the end of the document. And a fixed element at the bottom of the viewport can obscure focused form fields when the on-screen keyboard appears, which is worth testing specifically.

Where it’s less useful

High-consideration purchases where the shopper is genuinely researching rather than deciding. On a $1,000 laptop page, a bar urging Add to cart during the specification comparison is noise. Consider a quieter version; save, compare, or a jump-to-buy link, for those catalogues.

Where Should the Discount Code Appear?

A prominent discount box asks every shopper a question most of them can’t answer and sends some of them away to look for the answer.

This page is about why, and what happens around it.

The mechanism is simple and expensive

A large “Promo code” field tells a shopper two things at once: discounts exist, and you don’t have one.

A meaningful share respond by opening a new tab to look. Some come back with a code, some come back later, and some don’t come back at all, the coupon sites they land on are optimized to capture the sale, not return it. Several will also arrive at a competitor’s product in the process.

The field’s prominence is what triggers the search. So prominence is the lever, and the fix is not removing the field but shrinking it to a link that only the people already holding a code will look for.

Placement changes by page

In the cart, a collapsed link near the summary is right. The shopper is still working out the real cost, and a code is legitimately part of that calculation.

At checkout, the case for showing it at all is weaker. Someone who has entered payment details is committed, and interrupting them to consider a discount they may not have is a poor trade. If you keep it, and there are good reasons to, including customer service telling people to use one, put it after the payment section rather than before, so it isn’t in the path.

Apply automatically wherever you can

A code arriving from an email link or a campaign URL should already be applied when the shopper reaches the cart, with a visible line confirming it. That removes the field’s job entirely for the people who legitimately have a code, which is most of the point of having one.

The same applies to automatic promotions, a threshold discount, a bundle price. If the shopper qualifies, apply it and show it. Making someone type a code to get a discount you were always going to give is a needless step.

Show the result, not just the acceptance

“Code applied” is weaker than “SAVE10 applied, you saved $5.”

The saving is what the shopper wanted to see, and it belongs as a named line in the summary rather than folded silently into the total. A discount that changes the total without appearing on its own line reads as a pricing error.

Design the failure carefully

Rejection is common, because codes expire, have minimums, and get mistyped. “Invalid code” with no explanation, on a cart someone has already committed to, is a needless exit.

The minimum-not-met case is worth the engineering. It converts a failure into a next step, and shoppers act on it.

Order Summary Design

The same component appears four times across a purchase, and shoppers compare them. Any number that changes between them without explanation costs you the order.

This page is about the summary as a component across the whole purchase.

Four appearances, four jobs

The second one is where stores lose orders. A shopper who saw $28 in the cart and finds $30 at checkout does not scan for the delivery line; they conclude something was hidden, and that conclusion is very hard to reverse.

If a figure has to change, name the change on the line that caused it, and consider a brief note: “Delivery calculated for 500034.”

Order the lines the way people check them

Subtotal. Then each addition or subtraction, named plainly. Then the total.

Never fold delivery into the subtotal, a subtotal that already includes shipping makes the arithmetic uncheckable. Never show a total that includes something not itemized above it. And avoid vague labels: “Other charges” is the line that generates support tickets.

One number carries weight

The total is what the shopper is deciding on. Everything else is supporting arithmetic. Making four numbers all look important means someone has to read the whole block to find the one they want.

Larger, heavier, and visually separated from the lines above it.

Savings on their own line, and true

“You saved $10” is worth showing, and only when the comparison price is genuine, the same standard that applies to sale badges. An invented saving in an order summary is worse than one on a card, because the shopper is about to pay and is reading carefully.

Tax display is a market decision

Some markets expect prices inclusive of tax throughout; others show tax as a line at the end. Getting this wrong doesn’t read to a shopper as a formatting convention, it reads as a price change at the last moment.

Decide by where your customers are, not by where your platform defaults, and be consistent from product page to receipt.

On mobile the summary competes with what it summarizes

The common fix is collapsing it to the total with an expand control, which works, provided the total itself stays visible while line items scroll.

What doesn’t work is collapsing it so thoroughly that a shopper reaches the pay button having never seen the delivery cost. The collapsed state should always show the total and the fact that delivery is included in it.

Keep the totals live

Any change to quantity, delivery method or discount code updates the summary immediately. A summary that requires a separate “update” step is the reliable way to have someone pay for a quantity they had already changed, and that’s a support ticket and often a refund.

Estimates must be labelled as estimates

If delivery cost is provisional until an address is entered, say so on the line. “Delivery: calculated at checkout” is honest. A number that later changes without having been marked provisional is the specific thing this whole topic is trying to prevent.

Loading, Empty and Error States in Ecommerce

These three are the same design problem wearing different clothes: the screen has nothing useful on it, and the shopper needs to know why and what to do next.

The screens between the screens

Every store has these states and almost nobody designs them. They exist between the pages, which is exactly why they get skipped in design reviews, and why they’re where sessions quietly end.

Loading

Match the indicator to the length of the wait

Skeletons are not automatically better

The claim that skeleton screens always feel faster is weaker than it’s usually presented. The evidence is genuinely mixed, and at least one controlled comparison found skeletons perceived as slower than plain spinners.

The defensible reason to use one is narrower and more useful: a skeleton lets a shopper start reading the layout before the data arrives, so their wait becomes active rather than passive. That only holds if the skeleton matches what follows. If your skeleton shows three cards and you render seven, you’ve broken the thing that made it worth using, and a spinner would have served better.

Never let a skeleton loop forever

If the request fails, a shimmering placeholder hides the failure indefinitely and the shopper waits for something that will never arrive. Every loading state needs a timeout that becomes an error state.

The best loading state is often none

A grid with its card dimensions already declared simply fills in as images arrive. No indicator required, no layout shift. Reserving space beats indicating a wait.

Empty

Four different empties, four different messages

The last row matters most. A failed request rendering as “No products found” tells the shopper your catalogue is empty. It’s untrue, it’s the version they’ll remember, and it’s one of the most common bugs in ecommerce front-ends because both states render the same component.

No empty screen should be a dead end

Whatever the reason, offer one route onward: recently viewed, popular categories, a way back to browsing. An empty screen with a single suggestion recovers a meaningful share of sessions that would otherwise end.

Write them as sentences, not labels

“Your wishlist is empty” is a label. “Nothing saved yet, tap the heart on any product to keep it here” is an explanation and an instruction. The second one teaches a feature at the only moment someone is looking at it.

Error

Three things, in this order

What happened. Why. What now.

“Payment failed” is one of three. “Payment failed, your bank declined the transaction. Try another card, or contact your bank.” is all three, and it’s the difference between a shopper who retries and one who leaves.

Put the message where the problem is

A form error at the top of a page, referring to a field further down, makes the shopper hunt. Errors belong beside their field, and the field should be scrolled into view.

For forms with multiple errors, a summary at the top plus inline messages works, the summary tells them how many, the inline ones tell them what.

Never blame the shopper, never show them the machine

“Invalid input” blames. “Error 500” exposes. Write what a helpful person standing beside them would say.

Preserve what they typed

An error that clears the form is the fastest way to lose a checkout, and it’s an entirely avoidable one.

Distinguish what they can fix from what they can’t

A declined card is theirs to solve. A payment gateway outage is yours. Telling a shopper to check their card details during your own outage sends them to their bank for no reason and loses the sale twice.

All three

They have to be announced, not just displayed

A shopper using a screen reader gets no signal from a spinner appearing, a count dropping, or an error rendering visually. A live region on the changed area makes all three states work without sight, and it’s the same two lines of markup each time.

Design them once, use them everywhere

These states appear dozens of times across a store. Building them as three reusable components with defined content slots means they’re consistent, they’re all tested, and the next feature gets them for free. Building them ad hoc means most of them will be the platform default, which is usually a blank div.