Sometimes including a search box in your application feels like the right move, even when it could actually be detrimental.
Over the course of my career, I’ve several times found myself talking a client out of including search functionality in their product. I wouldn’t say it’s a frequent occurrence, but it’s definitely been a recurring theme.
Sometimes product owners include search as part of the product scope when the feature simply isn’t necessary. Other times search is requested when the feature would actually be detrimental to their goals. Either way—and especially in the latter case!—the project is better off without search.
In my experience, the search/goals mismatch phenomenon is more common on web projects. I’ve also encountered this for at least one desktop application. (But not on any mobile app projects—yet?)
When facing this urge to include search functionality—whether its coming from you or from a product owner who is not you—it helps to understand where the motivation comes from.
Why would a client request search functionality if they don’t need it?
There are, of course, many possible reasons, but I’ve noticed it’s often some combination of the following.
The client:
- Assumes they need search for their product;
- Tends to think of a search element as “standard”;
- Knows that their CMS supports search, so might as well include that feature, right?
Let’s start with last item first.
My CMS supports search, so we might as well include a search box, right?
No.
No to the general idea that if our third-party tool supports feature X, then we might as well include that feature in our application.
For one thing, even if the implementation and integration of said feature is as simple as flipping a switch and requires zero configuration—and how often is that, really?—you will still need to test it, let alone investigate it to mitigate risk, etc. Feature X is never free. It’s always worth considering whether you actually need pre-fab functionality before adding it to your product.
For another thing, feature X might actually be detrimental to your goals. And that’s often the case with search.
A short list of how search might be detrimental:
- It circumvents your messaging and presentation – a detriment to your business goals
- It invites your users to abandon your well-designed navigation and try to figure out their own way through your site – leading to a bad user experience
- Search functionality is often bad out of the box – leading to a bad user experience
- Users having a bad experience with search will flee – bad for everybody
- Good search can be difficult to design and implement – an unneeded expense
The idea of search as “standard”
It may be that when the client thinks of the “prototypical website”, that site includes a search box in the upper-right corner of the screen.
Or it might be that the client’s vision for the website or web app they want to build is based on specific existing examples, and those examples include search.
Either way, the search feature sneaks in through the side door and finds itself part of the product vision. It becomes part of bulleted system requirements or rough design sketches to communicate desired functionality at the start of a project.
But soon the client and I (or you!) will be talking through what he or she wants to build, the business goals behind it, and the users the product is meant to serve. It’s not until that point (and hopefully this is early in the project lifecycle) that we discover that search might not actually be needed or desired.
The assumption that search is needed for this product
A mistaken assumption that search is needed may simply come from the idea, as discussed above, that it’s “standard” — a staple of good websites.
Or it might come from the product owner’s experiences with other sites and applications. Bad content organization and/or badly designed navigational systems can make people presume that these aspects are always problematic, and that search needs to be there as a fallback. But this is not a good strategy.
In this case, your job (or the job of the appropriate member of your team) is to convince the product owner that good design of content and navigation elements is both possible and essential. And then actually make that happen through user research, design, and testing.
Another reason search may be on the menu when it shouldn’t be: someone has simply prescribed the wrong solution (search) for a legitimate goal. This happens all the time, certainly not just with search.
You’ll likely find that offering better alternatives to fulfill the goal is very effective.
A caveat
Sometimes a search feature is needed, but only for a narrow data set in specific contexts. In that case, the better approach is to move from global search (the search box is on every page) to contextual search (the search feature appears only where it is applicable).
A caveat to the caveat
Sometimes employing filtering options is a better solution than contextual search. Filtering may take the form of tags, categories, attributes, etc. that your team (or your users themselves) may curate to better fulfill your users’ goals.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 