Back to Blog
Design

The Product Taxonomy Hiding Inside Commerce Filters

Commerce filters expose the quality of product taxonomy. Audit category scope, attributes, normalized values, and ownership before redesigning the UI.

By Ilias Bikbulatov 7 min read
Glossy black funnel outlined in blue light on a dark background, representing commerce filters and product taxonomy.

A filter drawer is easy to blame. It is also late in the chain.

Shoppers cannot narrow a product list. Search results feel noisy. Category exits are high. The obvious response is to add another facet, promote popular filters, or redesign the mobile controls.

Sometimes the interface is the problem. Often, however, the filter drawer is the last mile of a much larger system. It can only expose categories, product types, and attributes that the catalog already knows how to describe consistently.

If the underlying product data cannot distinguish fit from style, compatibility from brand, or dimensions from marketing copy, a cleaner set of controls will not create those distinctions. Product leaders need to look upstream.

Commerce filters are a product-taxonomy problem before they are a UI problem.

The Filter Drawer Is the Last Mile

Baymard’s updated 2025 Product List UX benchmark reports that 58% of desktop ecommerce sites and 78% of mobile sites in its benchmark had poor-to-mediocre product-list UX. Baymard describes product lists, filtering, and sorting as the tools that determine how easy or difficult it is to browse a catalog.

Those percentages are benchmark snapshots, not promises that one filter change will lift conversion. The more useful point is structural: buyers need a manageable set of products before they can evaluate an individual product page.

Baymard identifies five broadly useful filter types when relevant: price, rating average, color, size, and brand. These are familiar because they express common buying constraints. But a useful filter system cannot stop there. Each category has its own comparison language: compatibility for accessories, capacity for storage, dimensions for furniture, temperature rating for outdoor equipment.

The controls are visible. The model behind them is not.

The Catalog Sets the Limits

For this article, product taxonomy means more than a navigation tree. It includes the category hierarchy, product types, attribute schema, normalized values, and the mappings that feed list cards, filters, and sorting.

Each layer answers a different question:

LayerDecision
Category scopeWhich products belong in one comparison set?
Product typeWhat kind of object is this?
Attribute schemaWhich traits matter for this kind of product?
Normalized valuesWhich different supplier terms mean the same thing?
List informationWhat must buyers see before opening a product?
Filter and sort mappingWhich traits can buyers use to narrow or order the set?

Baymard’s product-listing information research reports that 50% of benchmarked sites did not display adequate list-item attributes. Its research argues that essential and category-specific attributes help users decide which products to open, skip, and compare.

This creates a direct dependency. If size, material, compatibility, capacity, or another deciding attribute matters in the list, it needs a reliable representation in the catalog. Otherwise, the product team can neither show it consistently nor let buyers use it to narrow the set.

Categories and Filters Solve Different Problems

One of the most consequential taxonomy decisions is whether a distinction becomes a category or a filter.

Baymard’s overcategorization research reports that 75% of sites in its benchmark suffered from overcategorization. The article describes categories as scopes in which products share enough attributes to support useful filtering. Filters then let buyers combine values to narrow the products inside that scope.

When similar products are split into narrow, mutually exclusive categories, comparison breaks. Buyers have to move between scopes, reapply criteria, and remember what they saw elsewhere. A product type, style, or brand that could have been a combinable filter becomes a wall between comparable products.

The inverse problem also exists. A category can be too broad if its products share too few meaningful attributes. A generic filter set then appears because the catalog has no stable comparison model for the mixed products inside it.

The decision is catalog-specific, but the test is concrete: does this scope put products together that buyers reasonably compare, with enough shared attributes to narrow the list meaningfully?

Missing Attributes Become Missing Choices

Baymard’s filter and list-item research reports that 38% of ecommerce sites lacked filters for all the information displayed in product listings. Its testing found that once users see an attribute in a list item, many expect to filter by it.

The article also points to the data work behind that expectation. Harmonized filters may require vendor data and branded feature names to be post-processed into common attributes. That is taxonomy and catalog operations, not interface decoration.

A checkbox cannot fix null values. A redesigned drawer cannot reconcile conflicting attribute names. A promoted facet cannot help if half the products in the category were never classified against it.

This is why the first question in a filter audit should not be “Which controls should we add?” It should be “Which buyer-relevant distinctions can our catalog represent reliably?”

The Buyer’s Mental Model Is the Test

Internal structures have a way of leaking into customer experiences. Supplier departments become categories. Merchandising teams preserve historical labels. Product types reflect database inheritance rather than how buyers compare.

NN/g’s card-sorting guidance describes card sorting as a method for understanding how users group and label information, helping teams build information architecture that better matches user expectations. For commerce teams, cards can represent product types, category labels, or product offerings.

Card sorting is not a complete taxonomy validator. NN/g notes that it lacks the full context of the site and does not reveal complete navigation hierarchies. It should be combined with buyer interviews, product-finding tasks, search and filter behavior, and catalog data analysis.

The important product principle is simpler: a taxonomy should help buyers form useful comparison sets. It should not merely reproduce the organization that supplies the products.

The Taxonomy Audit

Product leaders can make the upstream problem visible with a compact audit.

1. Check category scope

Look for categories that are too narrow, too broad, redundant, or overlapping. Ask whether products in the scope share enough meaningful attributes to compare.

2. Inventory deciding attributes

For each category, identify the attributes buyers use to include, exclude, and compare products. Separate universal attributes from category-specific ones.

3. Measure attribute coverage

Determine how many products have a valid value for each important attribute. A filter with weak coverage can hide relevant inventory or produce misleading result counts.

4. Normalize values

Find duplicate terms, supplier-specific labels, inconsistent units, and values trapped in free text. Decide which common names and formats the product will support.

5. Compare list cards with filters

If an attribute is important enough to show in the list, buyers will often expect to act on it. Check whether the list, filters, and product detail use the same concepts and language.

6. Test the buyer language

Use card sorting, interviews, and product-finding tasks to test category groupings and labels. Use behavioral data to find reformulated searches, abandoned lists, unused filters, and zero-result combinations.

7. Assign operating ownership

Taxonomy changes cross product, merchandising, catalog operations, design, engineering, analytics, and supplier management. Define who creates an attribute, approves its meaning, normalizes incoming values, monitors coverage, and handles exceptions.

Without ownership, the interface gradually becomes a record of unresolved catalog disagreements.

Taxonomy Does Not Excuse Bad UI

Good catalog structure does not excuse poor interface design.

Filters still need to be discoverable. Applied criteria need to remain visible. Mobile controls need to be usable. Multiselect logic, result counts, empty states, and response speed still matter.

Baymard’s promoted-filter research shows that bringing important filters into the product list can shorten the path to a useful selection. The same article is explicit that promoted filters do not compensate for poor taxonomy. Overly broad, narrow, redundant, or overlapping categories continue to hamper product finding underneath the shortcut.

Small, curated catalogs may not need an elaborate filtering system at all. Marketplaces may have to improve supplier data progressively rather than normalize everything at once. The answer is not maximum taxonomy. It is enough structure to represent the distinctions buyers actually use.

The filter drawer is where the model becomes visible. When it feels generic, incomplete, or strangely organized, the problem often began long before design opened the component library.

Useful filters are evidence of a catalog that knows what its products are, how they differ, and which differences matter to buyers.

Frequently asked questions

What is product taxonomy in ecommerce?
Product taxonomy is the system that organizes a catalog: category hierarchy, product types, attributes, normalized values, and the mappings used by product lists, filters, search, and sorting.
Why can adding more filters fail?
New controls cannot expose attributes that are missing, inconsistently named, weakly populated, or attached to the wrong category scope. Adding filters before fixing the catalog can create empty, misleading, or generic choices.
What is the difference between a category and a filter?
A category creates a product scope whose items should share enough attributes to compare. A filter narrows products within that scope and can usually be combined with other filter values.
How should product leaders audit commerce filters?
Start with category scope, deciding attributes, data coverage, value normalization, list-card and filter parity, buyer language, behavioral data, and operating ownership. Review the interface after confirming that the catalog can represent the comparison criteria reliably.
Written by

Ilias Bikbulatov

Senior Product Designer specializing in fintech trading terminals, design systems, and data-rich B2B products. 10+ years of experience. More posts

Related

Comments