On the Search team at Dropbox, we were focused on how to enable our users to spend less time searching, and more time doing. We saw an opportunity to implement a highly-requested feature, so I sought to identify the real problem our users were facing, to see if and how it made sense to implement this feature.
We received a ton of complaints around not having search operators like our competitors. Here's a sample of some user feedback we received:
"Not great at searching within files in a refined way. Lots of after-work needed once search is done. Evernote is better at search function."
"I'm trying to search for a multiword term like 'world trade center' and Dropbox doesn't seem to allow for searches in quotes as specific phrases. As a result, I get back every result that has WORLD or TRADE or CENTER which is useless and these directions are so basic they offer no help."
“Please allow Boolean, esp OR Please consider wildcard. Please consider 'Image' search (JPG, PNG,..), 'Document' search (DOC, PDF,..) Please allow various sortings of results."
This started as a project to reach competitor parity, but power users only make up around 0.5% of the user population at Dropbox, so I saw a couple immediate concerns:
I revised the project goal to become a product differentiator for Dropbox, as I saw potential to increase our potential impact and help more than just our power users. The goal was then to help users get more relevant results, faster.
How might we help users form better search queries?
When a space is really ambiguous and has an unclear starting point, I try to imagine the experience through the lens of the user. In this case, I started by brainstorming some potential scenarios where users might find value in search operators. I then used the most common/recurring use cases from that initial brainstorm to imagine what users might use as clues to find their files, which would later inform when we’d trigger educational prompts.
It's one thing to create functionality on the backend, but how will we make users aware it exists? I laid out the user flow and identified critical moments of education through user research. In this, the two types of education are referred to as "Discovery" and "Confirmation".
Discovery: Users need a way to find operators. The context of where they're found should help them understand how they work.
Confirmation: Users need to know that the operator was valid and applied. This should encourage users to continue to try and experiment with operators.
From here, I mapped out more distinct user paths and prioritized them based on how often they've come up in past research.
There’s a lot of smaller explorations that were done around the visual design, interaction design, and similar intricacies. I frequently took designs back to my larger crit group and local designers on my team to fine-tune the details. Since this design problem lended better to quantitative feedback, I chose to get user feedback through experimentation, which is why the final design was designed as multiple phases.
Some of the things I explored were:
We’ll test a banner with language that provides examples of operators to use, and a visual style that draws a relationship between operators and filters. The banner will change each time you open the drop-down, cycling through these options:
I’ll be the first to confess that a “learn more banner” is not my ideal design, but the goal in this first phase was not to gain adoption. The goal was to prove that for however many users decide to try it, that they actually are seeing an improvement in their “time to success”.
That being said, this phase was not completely devoid of user education. You’ll also see the operators, like “type:”, applied in your search bar when you select a filter. This was an effort to help users understand the relationship between the filters they’re accustomed to applying, and the new method of applying them through search operators.
If we see success in the basic functionality of this design and can prove the value of the feature through Phase 1, we'll move forward to showing suggestions for each type of operator to see if we can increase usage of operators. We'll try this by showing examples in both the empty state of the search bar as well as contextually based on your search query.
Eventually, we'd like to dynamically update the typeahead results to show that we've identified a valid operator based on your search query. This was our North Star 💫—a future where operators are suggested based on how we’ve analyzed the potential search results of any query you’ve entered, or recent searches you’ve made.
Upon launching Phase 1 of this feature, we saw an average of 200-300k queries per day 🎉
As we work through the remaining phases, we also wanted to explore whether we saw an improvement in users’ time to success. We qualify "success" here as taking a qualified action, like editing or sharing the file. Before investing more heavily into education, we used the first phase of this design to gauge whether we see any improvement to the search experience for a small sample of users. If that test showed statistically significant results, we'd move forward to the next design to increase adoption of search operators (aka make operators discoverable to those we believe will benefit from them).
