The catalogue filter is the dominant pattern for product discovery on retail sites; it is also, on a substantial fraction of the catalogues I have worked with, a pattern that consistently underperforms the conversion-rate expectations the retailer holds for it. The dominant alternative — site search — is, on most retail sites, even worse, for reasons that are well documented in the search-experience literature and which I will not rehearse here. Between the filter and the search lies a third pattern, which goes by various names in the retail-UX literature (guided selling, consultative discovery, decision tree, product wizard) and which I have come to refer to, somewhat prosaically, as the product finder.
Product Finder is the tool I built to implement the pattern across multiple client sites. This post is an account of what the pattern is, the catalogue conditions under which it earns its development cost, and the implementation decisions that distinguish a useful guided-discovery tool from an expensive piece of UI theatre that produces no meaningful conversion uplift.
The catalogue conditions that make the pattern viable
Not every retail catalogue benefits from a product finder, and the catalogues that do are reasonably well-defined. The pattern works best for catalogues with three properties in combination: a meaningful number of products in a single category (typically more than thirty), a small number of decisive variables that determine which subset of the catalogue is appropriate for a given visitor (typically between three and seven), and a visitor population that does not, in the great majority of cases, arrive on the site with a clear specification of what they want.
The third condition is the one that is most frequently missed in the procurement conversations I have about the tool. A retailer whose visitors arrive on the site already knowing the product they want — by SKU, by model number, by direct referral from a comparison site — does not need a product finder, because the visitors are not, in any meaningful sense, performing the discovery task that the finder is designed to assist with. For these retailers, the conventional filter and search patterns are sufficient. For retailers whose visitors are, by contrast, in the early stages of considering a category — bedding for a child whose age and sleep behaviour are the relevant variables, garden equipment for a garden whose dimensions and exposure determine the appropriate product, footwear for a sport whose specific requirements the visitor does not yet fully understand — the finder pattern produces conversion uplifts that the filter and search patterns do not approach.
The clearest signal that a category is suitable for the pattern is the behaviour of visitors who do not convert. If the bounce rate from category pages is high and the search query log shows visitors using natural-language phrasings rather than product names (“waterproof boots for hiking”, “duvet for hot sleepers”, “lawn mower for sloped garden”), the finder pattern is, on the basis of the projects I have shipped, very likely to produce a measurable conversion improvement. If the search query log shows visitors using product names and SKUs, the finder pattern is unlikely to add anything that the existing search and filter cannot already provide.
The decision-tree implementation
Product Finder, in its first version, implemented the pattern as a decision tree. The visitor was presented with a sequence of questions; each question was a multiple-choice selection from a small set of options; each option, when selected, narrowed the available product set and determined which question was asked next. The decision tree was authored in a JSON-shaped configuration file that the retailer’s content team could edit directly, with tooling that visualised the tree’s branching structure and which branches led to which products.
The implementation had two properties that distinguished it from the off-the-shelf decision-tree plugins I had examined before building it. The first was that the tree was non-linear; a visitor who selected a particular option early in the sequence could be routed to a different question further down the tree than a visitor who had selected a different option, and the tooling explicitly supported this branching rather than treating the tree as a flat sequence of questions with a single ordering. The second was that the tree’s leaves were not single products but product sets; the visitor, having completed the sequence, was presented with a small number of products that matched the path through the tree, ranked by an explicit ranking rule that the retailer’s content team could configure separately from the tree’s structure.
The non-linearity is the property that, in my experience, makes the difference between a useful finder and one that visitors abandon halfway through. A linear sequence of questions accumulates cognitive load on the visitor at a uniform rate; a non-linear tree adjusts the cognitive load to the visitor’s actual decision context, asking the questions that are relevant given the choices already made and not asking the questions that are not. The implementation cost of the non-linear tree is somewhat higher than the linear sequence; the conversion uplift is, in the data I have collected, considerably higher.
The conversion uplift in some specific terms
The first deployment of Product Finder, on a UK garden equipment retailer’s site, produced a conversion uplift of approximately twenty-one per cent on the visitors who completed the finder, measured against a control population of visitors who used the conventional category filters. The figure is, considered in isolation, encouraging; it is also, considered alongside the corresponding figure for visitors who began the finder but did not complete it, somewhat misleading. The conversion rate of visitors who began the finder and abandoned it was approximately twelve per cent below the control rate; the net effect, weighted by the proportion of visitors in each population, was a conversion uplift of approximately seven per cent across the visitor base as a whole.
The seven per cent figure is, in my view, the figure that retailers should consider when evaluating whether the tool is commercially defensible. The headline figure of twenty-one per cent applies only to the visitors who reach the end of the finder, and the proportion of visitors who do so is sensitive to the design of the finder itself; a finder with too many questions, or with poorly worded questions, drives visitors to abandon, and the abandoned-visitor population converts at a lower rate than the control. The implementation decisions that determine the abandonment rate — the number of questions, the wording of the questions, the visual design of the answer options, the visibility of an “I don’t know” option — are therefore commercially significant in a way that a casual reading of the headline figure would not suggest.
The implementation decisions that determined the abandonment rate
The decisions that, in my observation, made the largest difference to the abandonment rate were the following.
The number of questions was held to between three and five for the great majority of the trees I deployed. Trees with more than five questions produced abandonment rates that increased disproportionately with each additional question; the cognitive cost of each successive question was higher than the cognitive cost of the questions that preceded it, in a manner that is consistent with the general literature on multi-step form abandonment. Trees with fewer than three questions produced product sets that visitors found insufficiently specific; the absence of the third question was felt as a failure of the finder to actually narrow the catalogue.
The wording of the questions was held to a register that the visitor’s stated decision context could plausibly produce. A visitor selecting bedding for a hot sleeper was asked “How warm does your sleeper run?” rather than “What thermal-overlap rating do you require?”; the latter, while more technically precise, presupposes a familiarity with the category’s vocabulary that the visitor does not, by hypothesis, have. The technical wording is appropriate for a product specification page; it is not appropriate for the discovery flow, and using it there increases the abandonment rate considerably.
The “I don’t know” option was made available on every question, with the consequence that the visitor could complete the finder without committing to an answer that they did not feel confident enough to commit to. The provision of the option might be expected to increase the proportion of visitors who reach the end without genuine engagement; in the data I collected, the opposite was the case. Visitors who selected “I don’t know” on one or two questions were considerably more likely to complete the finder than visitors who would otherwise have abandoned at the question they did not know how to answer; the tree’s branching logic treated “I don’t know” as a request for the broadest applicable product set, and the visitors so treated converted at rates broadly comparable to those of visitors who had answered all questions definitively.
What the tool does not do
The principal limitation of the tool, in its current form, is that it does not learn from the choices of previous visitors. The decision tree is authored explicitly by the retailer’s content team and remains static unless they edit it. There exists a class of guided-discovery tools — typically more recent and considerably more expensive — that learn the tree’s structure and weights from the behaviour of previous visitors, adjusting the questions, the order and the recommendations on the basis of an ongoing observation of conversion outcomes. The case for such a tool is real, but the case is not, in my view, applicable to the great majority of retail catalogues; the explicit-tree implementation, authored once by the retailer’s content team and updated occasionally as the catalogue evolves, produces the great majority of the conversion uplift that the learning implementation produces, at a small fraction of the cost.
(For the related question of how filter UX itself behaves differently across visitor demographics, see Why Gen Z bounces off your filters and millennials don’t.)
An advisory close
The product finder is, when deployed against a suitable catalogue, one of the most reliable conversion levers available to a retailer; when deployed against an unsuitable catalogue, it is at best a piece of UI theatre that produces no measurable improvement and at worst an additional source of abandonment in a discovery flow that was already adequate without it. The retailer’s first task, before the tool is even procured, is to determine whether the catalogue is suitable; the catalogues for which it is suitable have, in my experience, a recognisable signature in the existing analytics, and the retailers who pay attention to that signature before commissioning the work consistently produce better commercial outcomes than the retailers who do not.