Product managers and UX professionals who manage e-commerce sites often struggle with how to approach the use of categories, filters, and products to increase sales and revenue. The biggest issues we see when talking about e-commerce are:
- Poor quality tagging to support a taxonomy,
- Brittle category structures, and
- Lack of clarity about who is responsible for various parts of the retail value chain.
One approach to this problem is moving your data model to a product-driven taxonomy instead of a category-driven taxonomy.
In category-driven taxonomies, products are defined by where they live on a website. Product attributes are often associated with and created by the categories.
In product-driven taxonomies, categories and filters are populated after the fact by the unique qualities of the products themselves, while reserving the essential qualities of the product catalog.
Why it Matters
If your organization wants to manage any sustainable growth beyond a small, custom e-commerce footprint, you need a product-driven taxonomy. Product-driven taxonomies:
- Are more flexible and durable than category-driven structures.
- Reduce dependencies and conflict across the value chain.
- Create a common language for talking about work.
Flexibility and durability
Separating navigable product category structures from the product catalog allows product teams to:
- Quickly and easily explore building categories,
- Innovate new merchandizing opportunities, and
- Support discoverability, particularly with search.
Product-driven structures make it easier to:
- Add products to categories
- Manage filters
- Reorganize categories and create polyhierarchies
Reducing dependencies across the entire value chain
Explicit separation between product catalog and navigable categories is a common result of using a product-driven taxonomy. This means you can introduce new products quickly. You can develop and populate new categories quickly. This is because the essential “aboutness” of any given product is independent of the category design. Retail teams can focus on product description quality. Department teams can focus on merchandising and branding. Store teams can focus on development of specific new storefronts or domains—all without worrying about what each activity will do to the other parts of the chain.
Creating a common language for talking about work
One of the most challenging things about e-commerce is the afore-mentioned value chain, which is made up of elements that are essential to someone at that point in time but might not be relevant later. For example, people in fulfillment think about a product in very different ways than a site manager or a designer. Yet ultimately they all are talking about the same thing. If a structure relies too heavily on the metaphor of a specific domain, those metaphors will not work elsewhere. Frankly, the fulfillment team doesn’t really care about the organization of the website. (And in fact, it can cause serious problems if there’s too strong a relationship, because then the site starts to feel like a warehouse).
What all users in a group have in common when talking about the business are the products themselves, and agreement that there are various things that describe them. If the other structures exist only in the parts of the value chain where they are relevant, then everyone can use the common language to talk to each other. This helps with understanding intent and facilitating management.
How it Works
Product-driven taxonomies have all the same characteristics as any e-commerce structure with categories and filters; it’s just derived in a different way. The elements include:
- A product
- Product attributes
- A category
- A category structure
Product and product attributesAnything of value that can be acquired for purchase. Generally speaking, products are physical things but on some sites it might be an electronic item or a service. The key thing about products is that they are “tangible,” but its “aboutness” is described by the product’s attributes.
Product attributes are associated with products because they describe their core “aboutness.” Common attributes are a name, a price, reviews, and images. The key thing to understand about product attributes is that they are used for all other elements in this model: filters, categories, and the on-page product descriptions.
What attributes explicitly lack is an understanding of a product IN RELATION TO other things. Attributes are lists of descriptions, but they don’t exist in a hierarchy or a tree. This is important because it allows the product and its attributes to exist in different places in 1 or more category structures.
The place where product attributes are most commonly seen are in the product details, as seen in a product listing or product detail page.
FiltersFilters are sets of product attributes that help users narrow the list of products in that category.
Filters allow for easier, more flexible exploration of a product set than navigation by category allows, because multiple separate filters can be selected and combined by customers without changing contexts (pages).
The category a customer selects determines which filters are displayed in that context. On lowest level nodes, all the selected filters should display. On higher-level nodes, showing the filters assigned to all, or a majority, of the subcategories.
On a search result listing, if no category has been selected, the filters shown can be drawn from all the filters assigned to the categories in which the result set products are found. Consider at least showing the filters assigned to all, or a majority, of the categories in which the result set products are found.
A categoryA category is a place, page, or context that are related together in navigable structures to create maps for way-finding.
User selection of a category is a mutually exclusive selection in the context of the parent category (a customer can only select one category at a time).
Categorizing by what a product IS (vs. what it is FOR), is a powerful approach to selecting a category’s “aboutness.” This is especially true for the core categories supporting general use cases. This is both because customers already know to shop by the type of product they they are looking for, and because a common information-seeking behavior is to pre-process a solution to one’s problem (“what thing will help me?”) before seeking.
Category structureCategory structure is the way that categories of products are organized in increasing levels of specificity. Top level categories may contain multiple different categorization themes; multiple sets of categories based on different “aboutness” or ways of categorizing (i.e. by what products are, by what they are for, by event, by time of year, etc.). When multiple categorization themes are used at one category level, it is critical that each subcategory group under each theme be clearly labeled (or completely self-evident).
Once you choose a theme, adhere to that theme within the context it was established (i.e. all sub-categories in that group should be meaningful in the same way). Amazon’s Departments are a good example of a well-formed category structure. It’s notable that it is deep or narrow depending on how much complexity exists in the space, with some category branches only going 1 or 2 levels deep, and others going as much as 5.
Put it All Together and Supercharge your E-Commerce
The separation of product catalogs from e-commerce categories makes the management of structure very straightforward. Basically product attributes drive all the organizational aspects of where products are presented, and the filters that are available. Now site managers can focus entirely on content structure and merchandizing.
One of the biggest objections to this model is that a given filter is explicitly associated only with a particular category and therefore shouldn’t exist at the product level. In our experience, that is due to insufficient metadata tagging for the products. Because almost any attribute that seems specific to a category is actually a description about a product or group of products that extends beyond the scope of the category itself.
Moving From Principle to Execution
Wasn’t that GREAT?! I love this stuff, and I hope you do, too. Now here’s the thing: the fundamentals I’m describing here are actually the easy part. Many books about category organization are very long, but the principles they describe can usually be summarized in a few pages. The rest of those books are made up of examples and considerations. You will find that applies to you as well: every site is different, and every business is different, so applying the fundamentals still requires thought and effort.
As a product or UX manager, the best thing you can do is get agreement on these basic concepts so you can start on the details of the work. That part is a blast, though. So go out there and organize! Why let the librarians have all the fun?
If you want to learn more about the academic thought on organization, I heartily recommend Robert J. Glushko’s The Discipline of Organizing, which is probably the best reference guide for understanding the elements of organized systems I’ve ever read. If you are more concerned about the mechanics of actually managing the organization process, Abby Covert’s How to Make Sense of Any Mess gives some very useful concepts and exercises for thinking about organization as a process without going into too much detail about the underlying tools.