Search, Sort and Filter UX Tips
It’s often said that there are two types of internet user: the ‘browser’ and the ‘searcher’. While I’m not a fan of reducing the wonderfully unique human nature of each one of us to these two categories, the usability tests that I have conducted lead me to think that there’s some truth in this statement.
Browsing is an application-driven action meaning that we, the development team control the outcome while as searching is a user-driven action, meaning we have no control over what the keyword is. We’ll just have a search box there and it’ll do what search boxes do.
With limited budgets and timelines it’s often necessary to reduce the scope of the interaction design effort to the key functionality the new system will offer. This means there usually isn’t enough time to fully scope out the search unless it’s critical to the user journey. This also means that the internet is full of wonderfully crafted sites where you can browse to your heart’s content but as soon as you hit ‘search’ the whole thing turns into a flashback of the web in the ’90s. Basic styling, links and excerpts of the found content and not much else. We do this because we think the taxonomy of the website is so self-explaining that no human in their right mind would ever be using the search anyway. We have categories there, we have a clearly-worded navigation here, there’s no way anyone would ever be lost on our site right? Maybe not, but we’re forgetting something: searching is something many people do before they even bother reading the category titles. They’re in a hurry and they’re used to searching. That doesn’t make them any less important.
So, what can we do to improve the UX of searching on applications where searching isn’t part of the key user journey?
1) Don’t make it too complicated. Start with the very basics - a searchbox that suggests something as you start typing. Most people will only want that. Please, no category drop-downs, no complicated radio buttons or checkboxes. Keep it simple. That’s what search engines have taught us for the past few decades.
2) If you have more than one type of content, it’s a good idea to offer some separation in the results. Let’s say I search for “apple” products with apple in their name, people named apple, apple showing up anywhere else on the website. This simple separation makes the whole results page a lot more readable.
3) Allow sorting and filtering of results. This is essentially taking the first point a step forward - let people narrow down the search results after the initial search query. For example, If you’re a clothes retail site and someone searches for “sneakers”, it’s a good idea to offer some filters such as “men’s sneakers”, “women’s sneakers”, “sneakers under $50”, “blue sneakers” so on. Just remember one thing - make the filters narrow down the actual content, don’t display categories. There are only a few things more frustrating than clicking on “filters” and having “no results found” appear. Displaying the number of results found immediately after the filter label is a handy addition as well.
4) Don’t make people have to follow complicated instructions on how to use your search. As much as possible, avoid having instructions like “put multiple search strings in quotes to have the system search for them appearing together, use AND/OR in capital letters to combine multiple keywords in a single search, type -keyword to omit those results” so on. If your system requires you to do this, then have an advanced search somewhere and allow access to a graphical interface that does the job without requiring a wall of text that explains all the possibilities. This isn’t to say that you should not support the standard conventions in advanced searching - just that there should be another way of using it without having to read and follow complicated instructions.
5) Be forgiving to mistakes and support plurals of the same word. This is probably standard practice by now, or at least I would hope so but I will mention it regardless, because it’s such a frustrating experience when it’s not in place. If a user types “ctaegories” then it’s okay to have a “Did you mean categories? Here are the results found:” section just below the “No results found for ‘ctaegories’ “ message. Also, if a user types “blueberry” then you will definitely want to include results that have “blueberries” in them as well, at least in simple search mode and allow them to filter the results instead. If you are supporting an advanced search mode: when the settings performed by the user lead to no results, it is similarly a good idea to add a “We’ve found these in results for the keyword in other categories” section just below the results message.
6) Don’t make people have to remember what they searched for. The easiest way to do this of course is to keep the word/sentence in the search box itself after the results have been displayed. But if the query is performed via advanced search, this can get tricky. Offering a simple recap, saying something like “You have searched for blue shoes in the ‘All clothes and accessories’ section” will help avoid repeated queries for the same keyword, in the same sub-category. This is especially important when no, or very few results appear. The first instinct of most of us would be “oh, I must have made a typo”, instead of “let me double check those settings to make sure I haven’t ruled out the categories where this search query makes sense”.
No matter how well thought-out and logical your application’s information architecture seems, I strongly recommend keeping these above tips in mind when designing and building your product. Paying a bit more attention to the search path as a possible user journey goes a long way in keeping the “searcher” type of your users happy.