Skip to main content
Skip to article
Search UX 2026-07-298 min read

Mobile Ecommerce Search: Modal, Filters, Product Cards, and Return Paths

Mobile ecommerce search is not desktop search squeezed into a smaller column. The shopper has less visible context, a software keyboard that changes the viewport, touch instead of precise pointer input, and fewer products visible before scrolling.

The right mobile design preserves the same contract as desktop: query, match state, filters, sort, product identity, availability, and return path. It changes the order and containment of those elements so the next decision stays obvious.

Design each search surface for a changing viewport

Mobile changes the container, not the search job. Use the inline-search guide for in-flow responses and the search-layout guide for the surface decision. Use the modal UX guide for the desktop-to-mobile dialog handoff, the autocomplete guide for the suggestion pipeline, and the results-page guide for the committed comparison state. Whichever surface you choose must still survive changes to the visual viewport, touch input, drawers, the software keyboard, and the shopper's return path.

The hidden-context problem

Mobile search is a continuity problem, not a smaller layout

On a wide screen, query, result count, filters, sort, and several product cards can act as shared evidence. On a phone, those same facts are distributed across a keyboard, a suggestion view, a results page, a drawer, and a product page. The shopper has to remember what each view means while the interface changes around them.

Take the journey “black hiking boot” → size 9 → one product → back. If the query disappears when the drawer opens, the selected size is not summarised on the results page, or the product page returns to the top of an unfiltered list, the shopper must reconstruct the search before making the next decision. The repair is not to fit the desktop interface into the phone. It is to repeat a small, trustworthy explanation at each transition.

Desktop evidence

Several facts can be compared at once, so a hidden state is often recoverable by looking around the page.

Mobile evidence

Facts arrive serially. A drawer, keyboard, or product page can hide the evidence that made the previous decision understandable.

Continuity cue

Keep the query, applied values, result meaning, and return path visible enough that the shopper never has to guess what changed.

Worked mobile trace

Diagnose the “black hiking boot” journey before changing the layout

The following illustrative trace turns the familiar mobile journey into a decision. The buyer searches black hiking boot, applies size 9, opens one product, and returns to compare.

MomentExpected stateIf it failsLikely owner
InputThe query remains visible while suggestions load.Older suggestions replace the current text.Request identity and input state
FilterSize 9 is applied and summarised outside the drawer.The drawer closes and the grid gives no clue why it changed.Filter state and URL
ProductThe card opens the product and preserves the chosen variant or asks for options.The parent product opens with size unresolved or the wrong variant selected.Card projection and product handoff
BackQuery, size 9, sort, result segment, and useful position return.The shopper lands at the top of an unfiltered list.History and scroll restoration

This is a test fixture, not a claim about every mobile storefront. Change one layer at a time and replay the same journey so a denser grid is not mistaken for a repaired query, filter, or handoff.

Mobile contract

Keep the search task stable while the viewport keeps changing

Opening the keyboard can reduce the usable height. Browser controls can expand and collapse. Rotation changes the column count. A modal or drawer should therefore use the current visual viewport, keep primary controls reachable, and avoid placing the only close or apply action below content the shopper cannot reach.

Viewport behaviour differs between browser and operating-system combinations. The Chrome viewport guidance describes cases where the on-screen keyboard resizes the visual viewport, the layout viewport, both, or neither. Test the visible outcome rather than assuming one CSS viewport contract.

The mobile constraint is not simply less space. It is less simultaneous evidence. A desktop shopper can see the query, filters, result count, and several cards together; a mobile shopper may see only one of those states at a time. The interface must preserve the hidden context through clear summaries, applied values, predictable drawers, and a return path so the shopper does not mistake a change of view for a change of search meaning.

MomentPreserveMake visible
OpenReturn focus and the page position behind searchFocused search input and a clear close action
TypeExact input while responses updateGrouped suggestions and visible loading
SubmitQuery, correction state, and historyResult count, filter access, sort, and first products
FilterCurrent query and previously applied valuesPending or live selection semantics and a clear way back
Open productQuery, filters, sort, and result positionThe exact product or variant represented by the card
ConditionExpected resultIf it fails
The software keyboard opensThe focused input and the only close or apply action remain inside the visible area.Check the overlay’s viewport model and fixed or sticky controls before changing card density.
Rotation or browser controls change the available heightThe surface recomputes its usable space without clipping the query, status, or primary action.Treat it as a viewport and containment failure, not as a reason to hide the state.
The filter drawer closesApplied values, result meaning, and a direct removal path remain visible; focus returns to the trigger.Check whether the drawer uses immediate or Apply semantics and whether state is serialised for return.
The shopper returns from a productQuery, filters, sort, loaded segment, and useful position return together.Inspect history and restoration before changing the product-card layout.

Input and modal

Put the query, close action, and current response in one visual frame

A search takeover should focus the input when opened, retain the element that launched it, and return focus when closed. Keep the query visible while suggestions and products change below. Do not replace typed text with an active suggestion before the shopper selects it.

Group query, product, content, and destination suggestions by consequence. A shopper should be able to predict whether a tap submits a query, opens a product, or navigates elsewhere. Shopify’s predictive-search UX guidance also keeps a submitted search route available rather than making suggestions the only path.

replacement filter
×

Queries

replacement water filter
replacement air filter

Products

  1. 1

    Open

    Focus the input, identify the dialog, and keep the close action visible.

  2. 2

    Type

    Show loading without clearing the input or presenting stale suggestions as current.

  3. 3

    Navigate

    Make suggestion groups and consequences clear to touch and keyboard users.

  4. 4

    Submit

    Carry the exact query into a stable results route with history and reload support.

Filters and sort

A closed drawer must not hide why the result set changed

Move large facet lists into a drawer on narrow screens, but keep the applied values and count visible near the result grid. The shopper should be able to remove one filter without reopening the drawer and should know whether selections apply immediately or only after an Apply action.

When the drawer opens, move focus into it and contain keyboard focus until it closes. On close, return focus to the filter trigger. Preserve the current query, sort, and previously applied values. The deeper data, logic, count, URL, and crawl contracts are covered in the faceted navigation guide.

Query

table under 2000

Drawer

Price ≤ 2000 · Type: table

Grid

Query + 2 active filters

Cards and actions

Spend scarce card space on the next purchasing decision

Mobile cards need less decoration and more decision evidence. The useful fields depend on the catalogue: apparel may need colour, size, price, and swatches; replacement parts may need model, compatibility, identifier, and pack size. Do not remove the field that explains the match simply because the title already occupies two lines.

Card fieldJobFailure
Image and titleRecognitionThe differentiating words disappear below truncation.
Matched evidenceExplain relevanceA variant or identifier match looks like an unrelated parent product.
Price and availabilitySet purchase expectationsA range, market price, or sold-out state is hidden until the product page.
Variant contextPreserve intentThe shopper must repeat size, colour, model, or pack selection.
ActionContinue safelyQuick add bypasses required choices or adds the wrong sellable item.

Quick add is safe

The sellable item is fully specified and the displayed price and availability belong to it.

Choose options first

Required variants, compatibility, subscriptions, or other purchase decisions remain unresolved.

Loading and return

Preserve progress through slow requests, product visits, and back navigation

Reserve card geometry before images arrive, retain the old stable layout while a scoped update loads, and show which operation is pending. A filter update should not replace the entire page with a skeleton. A new query should not leave old products looking current.

The return path is part of conversion UX. When a shopper opens a product and comes back, restore the query, filters, sort, loaded segment, and scroll position. Requiring the shopper to rebuild the result set makes every product comparison expensive.

Pending

Name the operation and preserve stable context.

Return

Restore query, state, and position.

Settled

Announce the result and move no focus unless the action requires it.

Mobile QA

Test behaviours and catalogue extremes, not device names alone

Narrow phone

One-hand reach, keyboard resize, two-column cards, drawer fit, long filter values

Large phone

Density, card hierarchy, sticky controls, landscape rotation, browser chrome changes

Tablet

Breakpoint choice, sidebar versus drawer, touch targets, mixed pointer and keyboard use

Zoomed desktop

Reflow at 200% zoom, no horizontal page scroll, controls still reachable

Use long product titles, missing images, sale prices, price ranges, sold-out variants, many filters, long filter values, no results, request errors, and the software keyboard. The W3C target-size guidance is a useful floor for small controls, but touch comfort still needs testing in the composed interface.

ParticleSearch fit

ParticleSearch treats mobile as the same search journey with a deliberate narrow-screen composition

ParticleSearch provides the modal, full results page, responsive result grid, filter drawer, active filter state, sorting, product cards, availability states, and product actions as one storefront system. Merchants can choose the search layout, card information, filter placement, quick-add behaviour, and whether out-of-stock products are shown, pushed down, or hidden.

After installation and store-level verification, a merchant should not need separate mobile patches merely to keep the query, filter state, sold-out policy, and product handoff coherent. ParticleSearch cannot decide which product fields matter to a particular catalogue, and a theme can still create integration conflicts. Test the published theme with the real acceptance set.

See the complete interaction contract in the ecommerce search UX pillar, then use the ParticleSearch storefront feature page to review the merchant-visible surface.

A responsive native theme may already be sufficient when this acceptance path passes. Mobile alone is not a reason to install a search product. ParticleSearch becomes relevant when the store needs one maintained contract across modal, results, filters, product evidence, and return state, and the published theme cannot reliably preserve it.

The durable rule is simple: mobile search may change shape, but it must not change meaning. At each handoff, the shopper should be able to explain what the query means now, which constraints are active, and how to return without reconstructing the journey from memory.

Evidence checked July 29, 2026

The judgement to carry forward

A good mobile search experience changes the arrangement of evidence, not the meaning of the search. Choose a drawer, modal, inline response, or full results route according to the next buyer decision, then prove that query, state, action, and return path survive the transitions that real phones introduce. If a breakpoint makes the next decision harder to explain, it is the wrong breakpoint even when the layout looks tidy.