Separating a valid Marketing need from an unproven change to the customer experience
Marketing needed to create campaign links that combined products from more than one category. The proposed solution was to make the Category filter multi-select across Flowtech's Product Listing Pages and Search Results.
I investigated whether that change would also help customers during product discovery, or whether it would add complexity to an interaction they were not using heavily. Over the 30-day period available, only around 1.7% of relevant sessions interacted with the Category filter on either page type. Mobile interaction was lower still, at less than or around 1%.
The evidence did not prove that multi-select had no value, but it did not provide a strong user-centred reason to introduce it across the website. I recommended separating the Marketing requirement from the user-facing filter and exploring curated campaign categories or landing pages instead.
This was a research and recommendation project. Multi-select Category filtering was not implemented or validated, and there is no measured outcome from the recommendation.
At a glance
Role: UX Designer
Product: Flowtech B2B e-commerce Product Listing Pages and Search Results
Scope: category-filter behaviour across desktop and mobile, the Marketing campaign-link requirement, UX complexity and lower-risk alternatives
Timeline: one week in late June 2026; report submitted 25 June 2026. The analytics covered a 30-day period
My contribution: problem framing, analytics review, page-type comparison, UX risk assessment, recommendation and further-research planning
Collaboration: marketing and e-commerce; the original request was raised by marketing
Status: research completed; recommendation not to implement multi-select across PLPs at this stage; no implementation or outcome data
Reframing the request
Most Flowtech filter groups already allowed multiple selections. Category behaved differently: customers could select one Category at a time, and choosing another replaced the previous selection. The proposal would allow several Category values to be combined using OR logic, while the existing AND logic between Category and filters such as Brand, Price, Size or Thread Type remained unchanged.
That appeared consistent at an interface level, but Category was not necessarily behaving like a standard product attribute. It often acted as a navigation or scoping step: a customer could use it to narrow a broad result set to one product family before applying more technical filters.
The known driver was also a Marketing use case rather than an observed customer problem. Marketing wanted links that could take campaign recipients to combined product sets spanning several categories. That was a valid business need, but enabling every visitor to manually multi-select Category values was only one possible way to solve it.
I therefore separated the investigation into two questions:
Measuring current behaviour
I reviewed the available 30-day analytics separately for standard PLPs and Search Results PLPs.
Category represented a greater share of filtering activity within Search Results: 14.9% of filter-interaction sessions, compared with 9.5% on standard PLPs. If multi-select were explored further, this suggested that Search Results could be a more relevant place to test it because search result sets are often broader and may benefit more from category-level scoping.
Mobile usage was lower. Category interaction was less than 1% across 3,188 mobile standard-PLP sessions, and around 1% across 1,076 mobile Search Results sessions.
The data showed that Category was a relatively low-use interaction. It did not show whether customers were satisfied with the single-select behaviour, whether they attempted to compare sibling categories, or whether the filtering experience itself discouraged use. I treated the figures as evidence about observed behaviour, not proof that no unmet need existed.
Assessing the cost of added flexibility
Multi-select could help some comparison journeys, but it could also make an already demanding filter more difficult to manage.
In one example, searching for Hydraulic Adaptors and viewing all products returned 9,301 products and 128 Category options. Combining several categories could create a broader mixed result set. Where those categories had different technical attributes, the remaining filters could also become longer or less relevant.
That risk was more pronounced on mobile. Customers already had to open a filter drawer, scroll through options, review their selections, apply changes and return to the results. Adding selection behaviour to a long, lightly used Category list would increase interaction cost without clear evidence that customers needed it.
The question was therefore not simply whether the system could support multi-select. It was whether making that behaviour available everywhere was proportionate to the evidence and the problem being solved.
Recommending a lower-risk route
Based on the available evidence, I did not recommend introducing multi-select Category filtering across standard PLPs and Search Results at that stage. Instead, I proposed exploring campaign landing pages or curated bespoke categories. This would allow Marketing to promote combined product groups without changing the default browsing behaviour for every customer.
The recommendation deliberately preserved both sides of the problem. It recognised that Marketing had a real requirement while avoiding the assumption that a site-wide customer feature was the only way to meet it. It also left room for the filtering idea to be reconsidered if later behavioural evidence showed genuine demand.
What still needed validation
The analytics showed how often customers interacted with Category, but not what happened around that interaction. The next research questions were:
- How often did customers select one Category and then replace it with another in the same session?
- Did customers move between related or sibling categories during one journey?
- After using Category, did they view products, refine further, add to Basket, clear the filter or abandon?
- Was low mobile usage caused by limited relevance, or by friction in the mobile filtering experience?
At the time of the report, I planned to review OpenReplay recordings once playback was reliable enough to observe these behaviours. No further evidence or validation is included here, so the recommendation should remain presented as the conclusion of the available research rather than a final verdict on future customer needs.
What I learned
This project reinforced that a stakeholder requirement and a proposed interface feature are not the same thing. The Marketing need was valid, but it did not automatically establish demand for changing the Category filter for every customer.
It also showed the importance of interpreting low interaction carefully. A low-use feature may have limited value, but low usage alone cannot reveal frustration, failed intent or the reasons customers avoid it. The most useful conclusion was not that customers definitely did not need multi-select; it was that the available evidence was not strong enough to justify the additional complexity.
Most importantly, the work demonstrated that good product design can mean recommending that a feature should not be built yet. By reframing the request, quantifying current behaviour and proposing a more targeted route, I could support the underlying business goal without presenting an unproven solution as a customer need.