God I hate designing filters.
I hate designing filters (also known as faceted search) not because I don’t know how to craft kickass filters, but because to be really effective at it, I need three things I almost never get offered by the person asking me to add filters:
- 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
Time is important because depending on the cyclical nature of the business, the filters customers use during holiday shopping season might not be the same ones they use during the spring doldrums. (Also true: if in fields like financial, the filters customers use when the market is up might not be the ones they use when the market is down.) If no one is using a specific filter set over the course of a year, it’s worth asking why it’s there… but you’ve got to have a year’s worth of data (or the cyclical time field appropriate to the business) to analyze.
Note that “time” also implies “someone has realized we’re going to need this and put the appropriate hooks into the appropriate components so the web metrics software of choice is actually capturing the filters being used on a regular basis by session so I know what peeps are choosing in the filters and in what combinations.” Which really only happens if you’re rebuilding an existing flow and the previous team liked building metrics hooks.
If I don’t know what filters are useful, I might rip out the rare useful ones. (I don’t have the data to prove it because it’s locked up at my last job, but we found in repeated analysis and tests that the majority of people don’t filter at all.)
Research is important because there’s a weird thing I’ve noticed about people: everyone thinks that everyone else uses the same search techniques and mental map as they do. Just like most people wipe their butts the way they were taught and don’t realize half the population does it a different way (strangely pretty ok for work link), most people either were taught or stumbled into a few ways to search and use them most of the time.
Recently I had to explain to a younger designer how Boolean search works. Developers over a certain age were gobsmacked; all we had when the internet was invented was Boolean search.
I regularly stump my developers with “but what if the user doesn’t know what the thing is named?”, I think because the bulk of a developer’s searches are for named functions, features, etc. of programming languages and “There was a dog book out a few months ago with a blue cover, do you know what it’s called?” isn’t their normal pattern.
Because they are so different, the user’s search behavior patterns impact not only what I allow filter but the interactions of the filters themselves. So when the only information I have about filters is that the project manager or the quality engineer or the developer thinks we need a Boolean faceted search that includes seventy six facets, I get suspicious.
And data about the data set is important because I have lost count of the number of times I’ve been asked to add filters to a table or data set that — for the vast vast majority of customers — will have four items in it.
Four.
Which the team acknowledged would all be visible at once.
And, in some cases didn’t need to be compared or used together.
Eventually they’d come around (through some discreet questioning) to the idea that filters might be overkill.
So to review: the following three things make designing filters better.
- Time to find out what filters users are currently using (or a previous design team that thought ahead and made sure that data was being captured).
- Research to tell me what users would like to filter on but can’t (because we don’t all search the same way).
- The number of items that could be in the unfiltered results (to determine if this filter thing is needed at all).
And without them, no matter how well I think I’ve designed my filters, what I’m really asking my users to do is figure out how to gauge the usefulness of the data we’ve provided based on my own conjecture, gut instinct, and the instincts and conjecture of my team.
The result too often is that my users land in a place where the filters are useless, and the results doubly so.
Side note: this isn’t what I set out to write about. But we’ll get there, starting with the next post, Designing filters: or, now you know where and how anne shops.
