Filters of nope

In my last two posts, I wrote about how much I hate designing filters (because I never get the time and data to get it right) and the things I’ve learned about filters to make them better (even if I’m not fully confident in their necessity).

And I told you all that so that you’d understand filters in general and why some filters are just nope. That’s right, we’re finally getting to the bit I meant to tell you in the first place.

At the time of this writing, I’m planning a trip to ReplayFX for the Pinburgh pinball tournament in Pittsburgh, Pennsylvania. (By the time you read this, the event will probably be over, because the other two articles are so freaking long.)

During my hunt for all the stuff that one requires to ship two adults to Pittsburgh for a week I decided I wanted to try packing cubes. I don’t know anything about packing cubes so I’m a hesitant consumer. I’m not sure what criteria I should be looking for, I’m sort of just eyeballing sizes, and I’m reading a lot of sketchy website blogs about the glories of packing cubes coincidentally published and or funded by packing cube companies.

Since I’d recently had a good experience with a luggage website called eBags, I gave them another shot.

So, strong top navigation to get to travel accessories, a nice mega-menu that includes packing cubes, and a four-category filter that helps me break down the 127 choices to a manageable 11 that will fit in a backpack.

And then I spot it.

The gender filter.

Product list with left filters that indicate we're filtered to packing cubes for travel backpacks (11 results), and one can filter by the gender of "women" (9 results)
I… I can’t even.

Now I’m trying to be honest and fair about the world even though I’m generally a raging feminist, because there are things like clothing that eBags sells that can definitely be sorted by gender. A woman’s jacket is cut very differently from a man.

It’s also true that when it comes to transporting things, there are places where products that both men and women could use are designed in such a way that men are more likely to use one and women the other. Women’s handbags are called purses or and men’s handbags are called messenger bags. Women’s laptop totes tend to be styled to look like very large purses, and men’s laptop totes are still messenger bags.

So, like, different. As long as you ignore that some men might like a tasteful women’s laptop tote, many women I know prefer messenger bags, the luggage really can’t be told apart one way or the other unless “creamsicle” is somehow only for women, and there are way way more categorizations for humans and their style preferences than the two genders of “women” and men”.

But here we are and this is a thing.

Maybe I would yield to the argument that “our research indicates that primarily women or only women are purchasing packing cubes” since I am a woman, and I am buying packing cubes, and the only people I hear talking about packing cubes are women, and I don’t have the site’s actual purchasing and marketing statistics.

Except, well, two of the packing cubes are missing from the “women’s” count.

This brought up all kinds of questions in my mind.

  • Which two products were not women’s packing cubes?
  • Was there something special about them?
  • Why couldn’t I simply identify the non-women’s packing cubes when I didn’t have the filter checked? Why did the non-women’s packing cubes look like the women’s packing cubes?
  • It’s 2019 just what the actual hell?

I hunted down the suspect packing cubes and discovered that they were single-pack and two-packs of a full set of packing cubes. The women were being offered the three-pack and four-pack of that exact same product.

Being me, I punched the little “chat” button on the screen and asked. That conversation went down something like this:

Edited for length and clarity, and to protect the representative, who doesn’t need to get shit about this…

11:59:45 [rep] Hello, this is [rep], and I will be assisting you today.

12:00:05 [me] Hi! I have a question about the packing cubes for travel backpacks

12:00:35 [me] When I first load the page there are eleven options, but if I choose the gender of “women’s” the number of results drops to 9

12:01:11 [me] So what makes the single hyper-light packing cube and the two-pack of the same cubes inappropriate for women?

12:02:08 [rep] Packing cubes is a unisex version, seems there should be an glitch on the filter. I’ll report this to our IT team for further review.

12:02:33 [me] You can let them know that unless they’re loaded with testosterone supplements or tampons, packing cubes don’t have a gender and the entire filter should be removed for this category because it’s 2019 🙂 thank you!

12:03:18 [rep] You’re welcome!

Frankly, the eBags representative was fully professional in this entire exchange and while I haven’t seen a change yet, at least I felt like I was heard.

But this is a design problem. It’s a content strategy problem.  At some point someone with design and architecture chops should have been involved in determining what filters were appropriate for what products. The filters that display on each of the major (and most of the minor) product pages throughout the architecture differ in presence and order, so the excuse isn’t that the same set of filters are being applied to all products.

And even if the decision of whether a filter appears is driven by “did the sales person stick it in the metadata when they loaded it into the system?” major categories where filters absolutely cannot apply should, well, not have that category available for tagging products.

You shouldn’t be able to tag a “shoe size” on the luggage, for example. It just doesn’t work. They are too big for shoes. Or shoes are too small to carry things. Either way, filter mismatch.

This could seem like a petty little thing to point out, but it actually carries a lot of meaning. To women it infers that we’re the packers and the organizers and the domestics. To men it infers that domestic tasks like packing for the whole family are women’s work. All the folks that identify as genderqueer or nonbinary or ace or trans are erased altogether, which either means they’re cleared from having to buy packing cubes if they don’t want to, or they’re subtly rejected if they do.

Bad filters do damage.

It’s not just gender damage. In a tweet I can’t find now, someone in the disability community recently pointed out that hundreds of restaurants have tagged themselves as having “accessible” locations… but when a wheelchair user arrived for dinner they discovered that “accessible” meant “only one step” or “the busboys will carry you” or “you can take the smelly service elevator up through the kitchen to get to your own birthday party.” That’s not accessible.

Gender, disability, race, and a few others are civil and social model risks, the ones that call out whether our organizations are good citizens or whether they couldn’t find their ethical ass with both hands and a flashlight. They harm people directly at the core of “do we see you as people?”

Beyond those models there are other tangible risks to getting filters wrong:

  • financial risks on financial websites, where a user might pick the wrong product without adequate information
  • medical risks on doctor’s tools and websites, where a poorly worded, missing, or additional filter could result in the wrong medication for patient or the wrong treatment, or even the wrong doctor availability for an appointment
  • science and engineering risks on space flight and bridge building and any number of other tasks where people are looking up parts or specs or blueprints and filters help limit the data to human-understandable ranges
  • business risks where a poorly-formed filter set discourages users from getting the information they need to do their task and thus don’t fulfill the business goal

The list goes on, in every industry, in every part of society, in every place that searching or filtering or managing complexity can be found.

So above and beyond everything I wrote about how to decide if you need filters, how to use data to analyze existing filters, how to research with users what new filters to add, what features of filters are effective, and how filters fit in with the larger site architecture, the most important guideline I want to impart to you is this:

If you can’t justify the existence of the filter with actual use cases that do no harm to customers that come from marginalized groups, if you can’t find cases where the filter answers a question that users have actually asked during usability testing, if you can’t find a way that the filter actually adds good to the world, take this critical step:

Delete it. Filter it from your filter list. Make it a non-filter. Nope it back into the hole it stepped out of.

And document the hell out of “why we are not doing that again good god it’s 2019” so your organization learns the skills necessary to think before they filter.

Designing filters: or, now you know where and how anne shops

Last post, I talked about how I hate designing filters because my projects rarely give me adequate resources to explore three things:

  • Time to find out what filters users are currently using
  • Research to tell me what users would like to filter on but can’t
  • The number of items that could be in the unfiltered results

But there are a few tips I’ve picked up over the years that make designing filters and meeting users’ expectations easier, even if my personal confidence in my work isn’t what I’d like it to be.

  • If the data displays on the search results, you should be able to filter by it. (Corollary: if the data is a filter, it should display in the search results.)
  • If the data is time-based, provide time filters. (Correlary: if the data is not time-based, please do not provide time filters.)
  • Filtering is only the first step; showing the results in a sorted and organized manner is the second. “Random” is not a search results or filter results sorting method.
  • The shittier your information architecture and navigation are, the more your search and filter better work exactly the way the user expects.

Data that displays consistently with the filters is important because it confirms to the user that the filter is working correctly. We’ve all been on sites where the filter doesn’t work correctly.

For instance, Amazon.  (At one point in my comics-making life, Amazon was the source of something like 20% of the comics)

The search term (aka “text string filter”) was “backpack with seat”  and and the intention was this:

Three backpacks that let you unfold a metal frame so you can sit on top of the backpack, one backpack with a metal frame that lets you sit on a pad next to the backpack.
I’m playing 10 hours of pinball a day over the course of six days in a place with cement floors and no chairs. Easy-to-transport seating is a requirement.

This row of results was on the first page, and these aren’t sponsored results, which we all know are flaky anyway.

In order, a diaper bag backpack with seat, stroller straps and usb port, a backpack to stick a child's car seat into, another diaper bag with a child's chair, and my personal favorite, 100 toilet seat covers.
The sponsored results included a standing paddle board, a trolly bag with rolling chair, a couple of baby carriers you wear on your chest, and folding stadium seating pads.

When the filtered terms show up on the search results, the user can look at the filter, look at the term, and go “yes, these are at least in line with what I asked for.” When they’re not, the user has obvious questions about the quality of your results.

The search filter is set to sports and outdoors: sports and fitness: under $25 backpack with seat and the second search result is a $30 portable reclining seat that lacks a backpack
Some days I just look at the results and go, “welp, that’s screwed.”

So make sure the user can see your filters align with your results, so that it’s clear why something batty showed up. This also makes doing quality engineering easier on your testers. And you. And support.

The next tip is a little more subtle: use dates where dates apply, and don’t use dates where dates don’t apply.

Let’s say that we’re looking at a knowledge base for a printer.

We could be looking at a knowledge base because some news item somewhere on the internet tipped us off to a problem or a recall or something else that is time-related. In those cases, it makes sense to list the date the knowledge base item was last updated.

First of all the tab set wraps to two lines. Second, the technical service bulletin tab lists entries in date order starting with the most recent, with two columns: the title, and the date. The dates are in US format. The titles mostly start with Lexmark Security Advisory.
Do not get me started on the tabset.

On the other hand, we could be looking at a knowledge base because we can’t figure out why the damn printer won’t talk to the network and we want some instructions.  Instructions are generally viewed as evergreen content: content that doesn’t fall out of date like the news or the security updates, but instead is accurate for many months, years, possibly decades. [1]For a printer, probably not decades.

The How To tab is chosen and the articles are listed with the most updated first, same as before. There are 13 pages of results.
Well it’s a good thing I like to read instructions in the order they were most recently updated, not the order in which they make the most damn sense to do.

Content strategists and authors need to know when How To articles were last updated to support their content, because as Erin Kissane points out in The Elements of Content Strategy, good content is supported. These specific people probably want the ability to identify when a piece last got touched in a content audit. Stuff that’s old may be outdated and reviewed for accuracy.

And I know that some folks will argue that the user also wants to know when the last updates were for a particular page so that they can also decide if the article is crap, but the user lacks something the content strategist has access to: actual knowledge of whether the article is accurate. The content strategist has access to the people who can say whether the year-old device data security processes are out of date or need to be updated. The user can’t tell if they’re out of date or perfectly fine, even if they read the article.

So the only thing that sorting a knowledge base’s evergreen content does in a design is tell your user that your organization hasn’t updated the oldest articles anytime soon, and the only thing that knowledge can do for them is cast doubt on the accuracy of your content. Don’t advertise that. And don’t provide a filter for it!

Filtering is only the first step; sorting is critical too. Here’s a search for a pair of women’s jeans on Gap. The only four filters provided are category (which I’d call “style”), size, color, and price.  To generate the search results below, I filtered on “skinny” and “size 16”, which got me down to a respectable 33 items. Now I’ve got a pretty good idea of the things I want in a pair of jeans: must have pockets, can’t have holes, mid-rise is more comfortable, etc.

Eight search results with pictures: mid rise curvy true skinny, sky high skinny ankle with secret pockets, high rise ripped jeans with pockets, high rise true skinny jeans with pockets, sky high rise true skinny jeans with pockets, soft wear mid rise true skinny ankle jeans in dark blue, soft wear mid rise true skinny ankle jeans in light blue with working pockets, and soft wear mid rise true skinny ankle jeans with a hole in the knee. And that's eight out of thirty three results... sigh....
Gap’s product names are alphabet soup.

It’s bad enough that the things I actually care about like “real goddamned pockets” and “no really i need to wear these to work don’t rip them for me” aren’t filters.

But even the things I did filter on don’t appear to have set or even influenced the sorting criteria of the results. The first and second row both have mid-rise and sky high jeans, so we’re not sorting on rise. We’re not sorting on length because ankle jeans show on both rows. Holes are the same. Pockets are the same. (Pockets don’t always get mentioned either.) Sometimes two pair that appear to be identical except for color are next to each other, but not always.

This is a pain in the relaxed-fit.

It’s not enough to provide filters. You have to know how to sort once the filters are done.

Sometimes this can be inferred…. “the only filter is for items under $25” might also indicate the user would like to see them in price order. “The only filter is for customer review” probably indicates the user would like to see highest-reviewed items first.

If the user can compound their filters (and that’s when filters are the most powerful so, y’know, do that) then deciding whether the user cares more about price or the high reviews is literally guessing.

And let’s face it, a lot of our companies have specific things they want the user to sort on, like “featured items” that better meet business criteria, which we also have to take into account in our designs.

But this is one of the places I give Amazon props over Gap. Amazon definitely prefers that I sort by “Featured items” so they always default to it. But they also provide me other sorting options for when I really want the top result in a search for “outdoor dog houses” to be the $13,000 natural wood dog house with windows and a porch.

The filter on Amazon's mobile application provides the sort option as the top filter, and provides featured, low to high price, high to low price, average customer review (high to low) and newest arrivals, then gets into the other filters available.
Sometimes you have to start with “oh hell no” to decide what you’re willing to spend.

Gap, on the other hand, is either sorting by “featured” but doesn’t want users to be able to choose a different criteria, or they’re not sorting at all.  And to be clear: this is easy for developers to overlook! They’re busy just making sure that the query is right and the results display and the table doesn’t blow up! Which is why it’s on my testing list.

Finally, a little bit of self-awareness about the site in which the filter and search resides is critical to understanding how much work we need to put into our filters. When we have a really strong information architecture with really strong information scent, navigating the site is easy and effective.

When we have really weak information architecture and information scent, we force users to look for alternate ways to find what they want. Weak information architecture is surprisingly easy to make, especially if technical constraints, politics, marketing, and business goals are all in conflict.

A totally fake highway sign that offers the user the choice between route 417 East and West in Canada initially, but also adds signs for Vancouver being 44 hours away, Quebec is Nice, Do you really want to go to Ottawa?, how about toronto? new york?
A slide from Gerry McGovern’s talk “Designing an Intuitive Navigation” by Gerry McGovern from last year’s An Event Apart DC conference. Taken by Erin Fike. If we let the same people prioritize highway signs as homepage navigation, nobody would ever get anywhere.

This is one of the biggest complaints that Amazon has been battling for years: its catalog is too big and its products too cross-listed for a user to get a strong information scent to a specific product. I still have no idea if I’ve managed to see all of the backpacks with seats that would have met my needs, despite spending hours between navigation, searching and filtering results.

My Amazon homepage, which has a few task-based elements to get me right to recommendations and orders and accounts, but also giant ads for a door view camera, whole foods market, a security camera, Audible files, and janitorial supplies.
Not only does Amazon hide their entire category structure in a hamburger menu (boooo!), every major category of ads on this page from the janitorial supplies to the school supplies and the kitchen mixer are Totally Not My Thing. I’ve been an active member since 1999. So that machine learning thing is clearly coming along.

On the other hand, the IBM Knowledge Center knowledge base is absolutely loaded with information scent in the forms of a strong information architecture where every topic has one parent, a solid information scent in the form of organized topic lists, breadcrumbs, top tasks, and solid guidance that’s driven by something other than IBM’s org chart.

IBM's topic page for the web sphere application server traditional v9 edition - with sections for product family, getting started, troubleshooting and support, top tasks, related topics, more information , breadcrumbs for navigating up the hierarchy, and a link to an actual functioning table of contents.
One can often spot old-school technical writers by the presence of a Table of Contents in a knowledge base.

IBM is so confident in their information architecture that their search and filter options are severely underpowered compared to what most users experience, well, pretty much anywhere else. They have one filter set: a tabset containing documentation, videos, IBM Developer, Technotes, and RedBooks. The filters are exclusive: you can’t view two at once.The filter for Documentation in my search for “installing” has 1,717 results.

A search on the previously-mentioned page for the word installing, which displays a search results page with only five filters formed into a tabset: documentation, videos, IBM Developer, tech notes, and RedBooks. The Documentation tab has 1,717 results and no way to filter them short of changing the search string.
Perhaps “installing” was too vague? I’m thinking it was too vague.

Arguably, IBM is the polar opposite of Amazon. It relies so heavily on its browsable architecture that a novice user may not be able to find anything useful in the search architecture. But presumably (since my understanding is it’s been up for a while) it’s working for IBM.

Amazon could never use their confusing information architecture with a search architecture this weak on filters.

In summary:

  • If the data displays on the search results, you should be able to filter by it. (Corollary: if the data is a filter, it should display in the search results.)
  • If the data is time-based, provide time filters. (Correlary: if the data is not time-based, please do not provide time filters.)
  • Filtering is only the first step; showing the results in a sorted and organized manner is the second. “Random” is not a search results or filter results sorting method. (Test it!)
  • The shittier your information architecture and navigation are, the more your search and filter better work exactly the way the user expects. (And if you’re really brave, you can build a great information architecture but rob your search architecture of all usefulness.)

And believe it or not, this is STILL not what I set out to write… we’ll get to that next, in Filters of nope


1 For a printer, probably not decades.