Over-Categorization: Avoid Implementing Product Types as Categories (54% Get it Wrong)

During our usability studies of how users navigate e-commerce sites, one of the most severe issues observed is over-categorization. This occurs when a site wrongly implements its product types as mutually-exclusive category scopes when instead they should have been implemented as combineable filters.

Testing showed over-categorization to cause severe usability issues, including:

• “Siloing” users into overly narrow category scopes,
• Making users overlook the entire site selection of a broader product type, and
• Preventing users from combining product types to match their purchasing preferences.

Unsurprisingly such critical usability issues can have serious business implications, and over-categorization proved a direct cause of site abandonments during testing. So while this may appear like a subtle implementation detail on the surface – if a given product tagging are implemented as mutually-exclusive categories or as combinable filters – it has very serious implications on the user experience.

The sometimes minute interface differences between product type categories and product type filters may help explain why during our Product List & Filtering benchmark study we found that 54% of major US e-commerce sites suffer from over-categorization at one or multiple points in their category hierarchy – having wrongly implemented product attributes as sub-categories rather than filters. (Although on a positive note, we can report that this has improved slightly, with 10% fewer sites suffering from over-categorization compared to 2013.)

In this article we’ll therefore present our test findings on the severity of over-categorization, and present a simple rule on when a product attribute should be implemented as a filter or a sub-category.

Categories vs Filters

The frequent misimplementation of a filtering attribute as a category is likely because a filter and a category tend to a) work in very similar ways, b) are often found displayed next to one another, and c) can technically be almost the same thing. However, filters and categories are in no way interchangeable implementations, as they come with important differences:

• Categories constitute the hierarchy of the site and product catalog, and are mutually exclusive. The user can only select one category at a time, for example, “Sofas” over “Armchairs”. Typically, each category will have its own unique page and a set of filters specific to the category, e.g., “number of seats” might be an option in the “Sofas” category but not on the “Armchairs” page. In other words, categories not only determine the products listed on the page but often also control the features available for browsing those products (including filters!), which is why categories need to be mutually-exclusive.
• Filters, on the other hand, are tools to adjust and narrow down the list of displayed products within a category (or a set of search results). Filtering values are not mutually exclusive and therefore allow users to combine multiple filter values to narrow down their product list. For example, within the “Sofa” category, a user might combine a wide range of filters to get a uniquely tailored product list, applying filters such as “size: 3 persons”, “material: leather”, “material: fabric”, “color: gray”, and “color: white”, in order to see “all 3-person sofas in leather or fabric that are gray or white”.

Because filters are combinable they afford the user much greater customization power over the product list, yet it is the user’s category scope that determines which filters are available to begin with. This interdependency between categories and filters can make them look all the more alike, yet actually just makes it even more important to correctly distinguish the two, as misimplementing one hurts automatically hurts the other.

The Issues of Over-Categorization

Hopefully the distinction between categories and filters is clear at this point. When we talk of over-categorization, we are thus referring to a product type or attribute that was wrongly implemented as a category rather than a filter. The problem of this is – as covered in the previous section – that categories are mutually exclusive, which means they cannot be combined and users therefore aren’t able to select and see products matching multiple values within that product type or attribute.

Over-categorization means a site’s category hierarchy has become too deep. The site has taken product types and attributes that should have been combinable filters and mistakenly implemented them as categories instead. The consequences of this misimplementation are manyfold and severe, with the three most important issues observed being:

1. It often makes it impossible for the user to see all products of a particular product type. For instance, users won’t be able to just see “all binders,” “all point & shoot cameras,” or “all sleeping bags” – instead they must select a sub-group of those. Thus, there’s a tendency for users to get “siloed” into an overly narrow category scope. For example, seeing only “Fun and Basic” Point & Shoot cameras, despite being interested in other types of compact cameras too – simply because the use of mutually exclusive categories forced the user to select one option over the other.
2. Even if it’s possible to see all products (e.g., via a separate “View All” function), only half of the issue is resolved, as users cannot combine the categories (since they are mutually exclusive). Notice in the earlier examples how users cannot get a product list with both “Long Zoom Cameras” and “Advanced Cameras”, or both “Square” and “Mummy” shaped sleeping bags. While obstructive in itself, this becomes even more problematic when users have a particular product attribute in mind, as they then have to repeatedly apply one or multiple filters (or sorting direction) within each of the sub-categories, instead of getting one combined list. (This exact sub-issue lead to the 80% abandonment rate in the earlier shown Go Outdoors usability test.)
3. If users don’t fully understand the product type or attribute implemented as categories, things get even more problematic because the user is now forced to select something they do not understand the implications of. As one subject explained during testing: “I’m not a mom, I don’t want a Square, I don’t know what Down is.. Synthetic, hmm…This is a really poor selection. It’s odd..” On the other hand, when product types are implemented as a filter, users can simply chosen the generic category scope (e.g. sleeping bags, binders, point & shoot cameras, etc.) and then apply any filtering options they do understand or are interested in (e.g. sleeping bag shape).

When to ‘Categorize’ and When to ‘Filter’

While it’s clear that the vast majority of product attributes should be implemented as filters, “product types” (and, in particular, “sub-product types”) are often difficult to correctly classify as either a category or a filter. To help determine whether a given product type should be a category or a filter, the “Shared Product Attribute Test” can be used.

The trick is to look at the potential benefits of turning a given product type into a set of categories rather filters. If the product attributes are the same across the different product types in question, then the set of product types should (typically) be implemented as filters, because there are no scoping benefits to implementing them as categories. On the other hand, if most of the product types have unique sets of product attributes, then it is worth considering if the product types should instead be implemented as a category scope to segregate the unique filtering options within them.

Let’s try to apply this for some of the previously mentioned examples:

• For “Sleeping Bags”, differently shaped sleeping bags generally will share all other product attribute types (bag length, color, filling, warmth, etc.) and “Sleeping Bag Shape” should therefore be implemented as a filter and not a category.
• For “Binders” the binder types can similarly be implemented as filters because all other product attributes are shared (while a presentation binder may have a “business card pocket” or a “transparent front pocket,” these are binary options, “yes/no” filters that will simply be “no” for a binders without it – e.g. most storage binders, although not necessarily all).
• For “Point & Shoot Cameras”, the usage-type is a product attribute that can be applied to all cameras and therefore doesn’t justify a separate sub-categorization. However, if we go one level up to the type of camera, “DSLR, Point & Shoot, Bridge, Videocamera” the type of product attributes within each camera type start to differ significantly. For instance, a DSLR camera has lens mount-type and sensor-frame size attributes that cannot be applied for the other camera types. The use of separate category scopes for camera types such as DSLR, Bridge, and Point & Shoot is therefore perfectly justifiable.
• If we look at living room furniture, “Sofas” have several attributes that “Armchairs” won’t have much use for, such as number of seats, modularity, integrated chaise lounge, etc., whereas an armchair can have attributes for being reclinable and swivel – thus having “Sofas” and “Armcharis” implemented as categories is suitable. However, if we look within the category “Sofas”, then an attribute such as type or size does not warrant further categorization, since all the sofa attribute types will be the same for “2-person” and “3-person” sofas – and these should therefore be implemented as filters.

A decent supplementary tool for quickly scanning a large and deep product catalog for any misimplemented categories is to programmatically query each category for the number of products it contains. If a category only contains a few products (5-30, depending on industry), it can be a sign of over-categorization, and thus warrant further manual evaluation using the prior mentioned “shared product attribute test.”

However, treat this scanning tool as a starting point, not the final destination – it can help you figure out which categories to look at first, but given the severity and frequency of misimplementations, all categories should ultimately undergo proper evaluation.

One reason we often see for over-categorization is ad-hoc product tagging, the all-too-frequent “let’s just create this ‘winter jackets’ category now because we don’t have the setup or time to do a proper ‘seasons filters’ at the moment.” There may be legitimate reasons for a “quick and dirty” fix every now and then – but any such fixes should be treated as temporary solutions. Yet in practice, we often see these seemingly innocent “one-off” fixes accumulate over the years, never getting fixed and slowly making their way into more and more of the site’s category hierarchy, greatly limiting users’ product list control.

Now, while ad-hoc product tagging certainly help explain some of the 54% of sites that during our benchmark study were found to over-categorize, there’s an even more common cause. When working with clients we often see important product types and attributes wrongly implemented as categories simply because their site design provides more exposure to categories than filters. While the underlying intent of this is good (users should be nudged towards important paths), our Product List & Filtering study revealed a much more effective design pattern to ensure exposure to important product type filters without (mis)implementing them as categories. These research findings will be the focus of our next article.

This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” e-commerce navigation experience.