Ecommerce product filters help shoppers narrow a catalogue by useful properties such as size, capacity, material or intended use. The important planning question is which choices actually help a customer find a suitable item in your store. Copying another shop's sidebar can create controls that look complete but do not match the products you sell.
Before commissioning an ecommerce website in Kenya, prepare a filter brief using a representative part of your catalogue. The brief should explain the options, their relationships and the behaviour a shopper should see on a phone. It gives the developer something more concrete to estimate than “add advanced filtering.”
This guide concerns browsing and product discovery. It is separate from preparing an import spreadsheet, setting checkout delivery rules or choosing a payment integration.
Start with customer selection questions
List the questions a buyer asks before opening a product. For an illustrative bottle catalogue, capacity and material may matter. For spare parts, compatibility may be the first question. For clothing, size may be useful, but only when the results explain which items are available in the selected size.
Talk to the staff who answer product enquiries. Ask which details customers repeatedly use to distinguish similar items. Treat those conversations as input for your own catalogue, not as proof that every possible question deserves a filter. Some details belong in descriptions or comparison information instead.
Choose a short initial set for each category. A single universal list can become confusing when unrelated categories share the same page structure. A capacity control makes sense for containers but may mean nothing in a stationery category. Show the proposed controls alongside the actual category they will serve.
Record the decision in ordinary language: who uses this filter, what it helps them exclude and which product field supplies the answer. If the team cannot identify the field, the design is ahead of the catalogue and needs a data decision before implementation.
Distinguish product attributes from purchase options
A product property and a sellable option can overlap, but they are not always the same thing. Material may describe the entire product. Size may distinguish variants with different stock. A category filter needs a clear rule for how those underlying records affect the results.
WooCommerce's variable product documentation explains that variations can have their own prices, stock and images, and that attributes can be used to create those variations. This makes the product-versus-variant distinction worth settling before promising a particular browsing behaviour. The implementation still depends on the chosen platform and configuration.
Consider an illustrative shirt with navy small and maroon large variants. If the shopper selects navy and large together, should that shirt appear even though neither available variant matches both selections? Ask the developer to demonstrate the agreed answer using sample data rather than assuming any filter widget handles it correctly.
Write the same question for availability. Decide whether the filter means that an item has ever existed in a size, is currently listed in that size or can currently be bought in that size. Those definitions produce different results and should not be hidden behind the same unexplained label.
Clean the values before designing the controls
Review a sample of the actual catalogue. Values such as “navy,” “navy blue” and “dark blue” may describe distinct products or inconsistent data entry. Have the product owner decide which is intended. A developer should not silently merge commercially different options because their names look similar.
Use consistent units where comparison requires them. If capacity appears in different units, agree the public display and underlying comparison rule. Keep uncertainty visible until someone can confirm the specification. Do not infer a measurement from an attractive product photograph.
Assign a controlled set of values for fields used in filters. Staff can still write descriptive copy, but a filter should not accumulate a new option every time someone changes punctuation. Include the agreed values in the product catalogue preparation process.
Define what happens to products with missing information. They might need to remain unpublished, appear only in broad browsing or be flagged for correction, depending on the field. Make this a business decision. Treating an empty value as “other” without review can conceal a catalogue problem.
Decide how selections combine
Describe the expected logic with small examples. If a shopper selects navy and maroon, do they want either colour or both colours on the same item? If they also select cotton, does that narrow the colour results? The interface labels and the result set should express the same rule.
Price needs similar care. Explain whether the displayed range concerns the lowest available variant price, the selected matching variant or another agreed value. Avoid a result card advertising a price that does not apply to the option responsible for including it in the results.
Decide whether counts will be shown beside filter options and what they count. Products, variants and available units are different quantities. A number that looks precise can still confuse a customer if it changes according to an unexplained rule.
Keep sorting separate from filtering in the brief. Filtering narrows the eligible products; sorting changes their order. Specify useful sort choices for your catalogue and ask how they interact with the current selections. Do not promise a “recommended” order without deciding what the business means by that label.
Design a usable phone interaction
Ask to see the closed state, open filter panel and applied-results state on a phone. A desktop sidebar scaled down can leave the product list too narrow. Decide how the customer opens the controls and how they return to browsing without losing their selections.
Choose whether results update immediately or after an apply action. Either approach needs clear feedback. If applying changes takes time, show an appropriate pending state and avoid letting repeated taps create a confusing sequence of results. Review this behaviour on a realistic connection during testing.
Make active selections easy to understand. A shopper should be able to remove one choice or reset the whole selection without hunting through several panels. Where a control uses a colour swatch, include an understandable label so the choice is not communicated through colour alone.
Ask the developer to include keyboard and assistive-technology checks for the chosen controls. The business reviewer can also perform simple observations: are labels readable, is the current selection clear, and can the panel be closed without accidentally discarding the intended choices?
Plan empty results and the return journey
Create a sample combination that produces no matches. Agree an explanation and a useful way to recover. Showing a blank grid gives the shopper little information about whether the selection is too narrow, the catalogue is incomplete or the page has failed to load.
Offer a clear reset or a way to remove selected restrictions. Do not quietly ignore one of the shopper's filters and display unrelated products as though they matched. If alternatives are shown, label them as alternatives so the browsing promise remains understandable.
Check the journey from results to a product and back. Should the selected filters, sort order and browsing position remain? Specify the expected behaviour and include it in acceptance. A customer comparing several items should not have to rebuild their selections after every visit to a product page.
Discuss shared links as a separate requirement. If the business wants staff to send customers a filtered range, ask how that selection can be represented and reopened. Have the developer separately review how filtered addresses are handled for search crawling and indexing; adding controls does not settle that technical policy.
Write acceptance examples before launch
Prepare a small fictional catalogue with deliberately different cases: a fully available item, an unavailable variant, a missing property and a product that matches only one of two selected values. Record the expected results before running the demonstration.
Use a worksheet with category, selections, expected included products, expected excluded products, displayed prices and visible messages. Add phone-panel behaviour, reset, sorting and return navigation. This makes disagreements easier to resolve than a general statement that the filter “feels wrong.”
Review the stored catalogue values when a result fails. The problem may be data, interpretation or implementation. Record which it is so the team does not fix incorrect product information by adding a misleading interface exception. Retest affected combinations after any correction.
Name who maintains the filter values after launch. Include instructions for new products and new options in staff training. A well-tested initial filter can become unreliable if later uploads bypass the agreed category and attribute rules.
Frequently asked questions
Does every category need filters?
Use them where the catalogue and buyer decisions justify them. A small range may be understandable through clear categories and descriptions. Agree the initial scope using representative products rather than adding controls purely to fill space.
Can we add filters before the product data is ready?
You can design and test a sample, but the live result depends on accurate fields. Identify missing specifications and controlled values early. Do not treat the visual design as evidence that every product will be classified correctly.
Should unavailable products disappear?
Agree the rule with the store owner. Some catalogues may show unavailable items with a clear status, while others may narrow to purchasable options. Ensure the filter label, result card and product page tell the same story.
What should we send for a development quotation?
Send representative categories, sample products and variants, proposed filter fields and a few expected result examples. Get a free quote and ask for catalogue preparation, mobile behaviour and acceptance checks to be scoped together.
