In a search environment, showing users not only the categories they can filter on but the sub options within provides better guidance than closed drop downs or panels that have to be manually opened. Compare these two new search experiences.
In the second screen, users can click and see the effect. As they make different selections, the larger information structure they are maintains visual consistency - no jarring transitions.
So when it comes to search, keep your options open - by default.
1 - Show all available filter categories with sub options already open.
2 - Refresh item set as customer makes filter selections.
3 - Make it easy to remove any applied filters - either one at a time or all at once.
When it comes to content, this standard eCommerce search experience is rare. For example, WordPress does not have something like this. WordPress uses categories and tags to allow users to organize their content. But there is no way to do a compound search for content in 1-x categories or with 1-x tags.
All you can do on WordPress is the equivalent of a Google search.
That's great if you're searching for a specific name or phrase. But it doesn't work well at scale. Imagine trying to do the search for skis on REI above with nothing but a search box.
So what could it look like to duplicate the excellent REI search experience in WordPress? Pretty simple. All you need to do is expose the available categories and tags (and maybe add a date range), and the user is off and running.
Here's a Spark with a quick survey of current search experiences on eCommerce and content sites.
In the realm of ecommerce, search and filter has gotten very, very good. Best practice has consolidated around a few simple principles that many people expect as standard. Yet when it comes to content sites like blogs or news, the same easy filter style has not been adopted widely. It could be.
If a Moore's Law existed for search and analysis tasks, it would be that everything will take half the time it used to the last time you tried it. Great user experiences surface key info sooner and show users the impact of possible choices faster.
On mobile, visibly displaying key areas of an app's information structure in the top level nav menu is usually better than making the user first click a hamburger or other icon. There's a good illustration of this principle in the difference between the native New York Times app on iOS and Android.
On iOS, a small arrow in the upper left is how you expose key information categories. If it's your first time in the app, it may take a moment to figure this out.
The iOS NYT app requires a tap on the arrow in the upper left corner to expose key information categories.
The experience on Android is noticeably better. Categories are out in the open on top in a nice scrollable ribbon and hard to miss. There is no question where you are, and it's easy to see other options.
In enterprise systems, a user may start a new journey with only the smallest piece of info. You may not even know where you're headed or what you need to do next. But you have a receipt or note or other scrap of data and you know there's something that needs to happen. So you turn to the screen.
In these scenarios, we can provide additional information structure to predictive search results by not only showing possible matches, but also where those things live in the taxonomy.
When you have a big internal system with many different connected dimensions and domains, the ability to show all these different types of data based on the user's entered text educates and informs.
We expect a web site to give us suggestions as we start typing in the search box. This feedback helps us learn the lay of the land and see what else we might be interested in. It's certainly more convenient to see results as you type vs. having to hit "go" first and then see if anything comes up.
But there's another piece of useful info that could be included with product names in predictive search results: the location where the items live in the site's taxonomy.
In any digital world the information architecture is the map new users need to reckon with before they can fully understand what goes where and what they can do in this place. But beyond a simple list of things, they also want to know where those things are and also how they relate to each other.
So why not include another column in results that shows where things live in the ecosystem?