How Many Questions Should an Ecommerce Product Finder Ask?

Count decision-changing questions, not screens

A short finder can still feel difficult when every question uses unfamiliar language. A longer finder can feel straightforward when each answer is easy, clearly relevant and visibly moves the customer towards a result. The useful measure is therefore not the total screen count but the amount of justified effort required from each buyer.

For every proposed question, write down what each possible answer changes. If no answer removes an unsuitable product, changes the order of valid products, changes the evidence shown or triggers a support path, the question probably does not belong in the finder. It may be useful later as a preference on the result page.

Keep different customer paths separate. A buyer who knows an exact manufacturer reference should not be forced through the same journey as somebody who only knows the application. Both can reach the same catalogue, but they need different questions.

Write the stopping rule before the first question

A finder without a stopping rule tends to collect information because it is available, not because it improves the decision. Define what a successful result must contain: a valid set of products, the confirmed requirements, the evidence used, any distinction between variants and the conditions the customer still needs to check.

The finder can stop with one product, several valid alternatives or a human hand-off. A single result is not automatically better: it may create false certainty when two products remain valid. A shortlist is not automatically safer: it may simply transfer an unresolved technical decision back to the customer.

• Stop with a product when the confirmed facts support that match.
• Stop with a shortlist when every item is valid and the remaining differences are preferences.
• Stop for support when a required fact is unknown, conflicting or absent from the approved catalogue.
• Stop with no result when the confirmed requirements exclude every available product.

Ask the highest-value easy question first

The first question should usually be something the customer is likely to know and that meaningfully separates the catalogue. Product type, application, machine make, intended use or a known reference can be strong opening questions. An obscure measurement that requires tools or a manual is rarely a welcoming first step unless every valid decision depends on it.

Estimate the value of a question by testing it against real catalogue records. Does it remove many unsuitable products? Does it prevent a serious mismatch? Can customers answer it reliably? A question that creates an even split is not necessarily valuable if buyers guess the answer.

Explain why an unfamiliar fact is needed before asking for it. If the customer must measure a diameter, show where to measure, specify the unit and state whether an approximate value is acceptable. Good guidance reduces both abandonment and confident-but-wrong answers.

Separate eligibility, ranking and presentation

Eligibility questions decide whether a product can be included. Ranking questions order products that are already valid. Presentation choices change how results are displayed without changing the underlying match. Mixing these roles can let a preference override a compatibility rule.

For example, working pressure or an approved application relationship may be an eligibility condition, while brand preference, delivery speed or colour may rank valid options. Price can help a customer compare suitable products, but a lower price must not make an unsuitable product appear acceptable.

• Hard requirement: excludes products that cannot meet the confirmed need.
• Preference: reorders products that remain valid.
• Display choice: changes how the shortlist is viewed or compared.
• Unverified input: cannot safely confirm or exclude a product until reviewed.

Use branching so customers only see relevant questions

A good finder is a decision tree, not a fixed questionnaire. A customer selecting a known model may not need to enter dimensions. A customer selecting an application with several unresolved variants may need a follow-up question. Branching keeps the path proportionate to the decision.

Write each branch as an explicit rule and test what happens when data is missing. Do not infer a required answer from a later preference. Preserve earlier answers when the customer goes back, but recalculate every dependent result when an answer changes.

Avoid progress indicators that promise a fixed number of steps when the route can branch. Use wording such as “a few details” or show progress within a known section. A customer should not be told they are on step four of five and then receive three unexpected follow-ups.

Treat “I do not know” as a designed answer

Customers often lack the exact information a catalogue uses. Removing the unknown option encourages guessing, which can be worse than abandonment. Decide in advance whether an unknown answer can be resolved through another question, an illustrated measurement, a reference lookup or human support.

Unknown must not silently mean “all products”. If the missing fact controls eligibility, explain that a safe recommendation cannot yet be made. Show what evidence would resolve it and preserve the answers already supplied so the customer does not need to start again when support responds.

Keep each step clear and group only related details

The GOV.UK Design System presents question pages as a way to focus users on a decision and says user research should determine when related questions can share a page. That is a useful starting point for a product finder: one clear question per step works well when the answer changes the next branch, while tightly related dimensions may be easier to enter together.

Use the question itself as the main heading, provide a visible back action and keep help close to the control it explains. On smaller screens, avoid long grids of tiny choices. Large controls, short labels and a single obvious continue action make the route easier to scan and correct.

Test grouping with real customers rather than assuming fewer pages means less effort. Three measurements on one labelled diagram may be simpler together; three unrelated commercial preferences may be easier after the valid shortlist is visible.

Make instructions and labels accessible

W3C's Web Accessibility Initiative recommends identifying required and optional input, expected formats and other relevant instructions. It also warns that placeholder text is not a replacement for a label because it disappears and is not consistently treated as a label by assistive technology.

Give every control a persistent label. Associate help and error messages with the relevant input, support keyboard operation, preserve visible focus and do not rely on colour alone. If a diagram explains a measurement, provide an equivalent text explanation. Test the complete journey with zoom, keyboard navigation and a screen reader.

Accessibility testing belongs in the acceptance criteria. A finder that technically returns the right products but prevents some customers from answering the questions is not functioning correctly.

Build every answer on approved catalogue facts

Question logic and product data must use the same definitions. Normalise units, attribute names, option values and compatibility relationships before relying on them. Keep the customer-facing wording separate from the stored value so a clearer label does not change the rule.

Carry stable product and variant identifiers through matching and hand-off. Never use an editable title as the identity of the recommended item. When a required field is missing for some products, send those records to review or exclude them with a recorded reason; do not invent a value to keep the finder moving.

M.I.A.I Product Finder is intended to guide buyers from requirements to a relevant, explainable shortlist. That explanation should name the confirmed facts that affected the result and distinguish them from preferences or unverified information.

Connect guided questions to Shopify filters and variants

Shopify's Search & Discovery guidance explains that storefront filters can be based on product options, metafields, category metafields and variant metafields. A guided finder can ask customer-friendly questions over the same approved attributes, then hand the customer to the correct live product or variant instead of creating a disconnected copy of the catalogue.

Shopify also documents that values from different filters normally combine as an AND condition, while multiple values inside the same filter normally use OR logic. Translate that behaviour deliberately into the finder. “Red and size 8” is different from “red or green”, and a hidden logic mistake can produce a plausible but wrong shortlist.

Only ask about attributes that the authorised store data can support consistently. Keep price, availability and product-page details current through the live Shopify integration, while treating compatibility or requirement rules according to their approved source.

Prevent dead ends and make answers reversible

Every route needs a useful outcome, including no result. Show which confirmed requirement removed the final products and let the customer change that answer without losing the rest of the journey. Do not reset the finder to the beginning after a validation error or back action.

Before showing results, consider a short answer summary for decisions where mistakes are costly. Let the customer edit any value and recalculate the shortlist. On the result page, repeat the important requirements so the customer can recognise whether the recommendation reflects what they meant.

A support route should carry the structured answers and candidate records. Sending a generic “please contact us” message without context wastes the customer's work and recreates the same repetitive questions for the support team.

A concrete example: selecting an industrial hose

Imagine a store selling industrial hoses across water, air, oil and chemical applications. Asking every visitor for material, internal diameter, length, working pressure, burst pressure, temperature, connection and regulatory requirements would create a long fixed form. Some answers are unnecessary for many routes, while others are critical.

The finder starts with the substance being moved because that determines which approved material-compatibility records can remain. It then asks for working pressure and internal diameter. Temperature appears only when the selected application has more than one valid material range. Connection and length are asked when they identify a purchasable variant rather than a later configuration.

If the customer selects a chemical that has no approved compatibility record, the finder stops and requests expert review instead of ranking hoses by popularity. If three hoses remain valid, the result page explains their pressure, temperature and connection differences and lets price or delivery preference order them. The shortest route uses three answers; another route uses five. Both are correct because every question changes the decision.

Measure whether each question earns its place

Review the journey by branch, not only as one overall completion rate. Record where customers leave, choose “I do not know”, change an earlier answer, reach no result, request help and select a product. Connect that evidence to support questions, corrected orders and confirmed wrong-product returns where the business can do so lawfully.

A high exit rate does not prove the question should be removed. It may reveal unclear language, unavailable information, a catalogue gap or a genuine incompatibility. Watch customer sessions or conduct usability tests to understand the cause before changing a hard requirement.

Retire questions that do not change results. Reorder questions when customers can answer them more reliably earlier. Improve the catalogue when the same unknown field blocks many journeys. The finder should become shorter or clearer because the evidence supports the change, not because a target screen count was imposed.

Test every branch before launch

Create a test matrix from real customer cases and approved product records. Include each opening route, every hard exclusion, multiple valid results, missing data, unknown answers, back navigation, changed answers, no result and support hand-off. Confirm that the final link opens the correct live product or variant.

Test on mobile and desktop, with keyboard navigation and assistive technology. Check translated labels and values if the store is multilingual. Repeat the tests whenever product data, matching rules or Shopify option and metafield structures change.

1. List the customer decisions the finder must support.
2. Map every question to the rule or ranking change it controls.
3. Define stop, no-result and human-review outcomes.
4. Build representative branch and data-quality test cases.
5. Run usability and accessibility checks with real users.
6. Monitor evidence and remove questions that do not improve the decision.