The design challenge: relevant, not distracting
Our key design challenge was to make sure people would notice relevant results without being distracted. We knew it would take extensive testing to find the right design, so we ran through a sequence of prototypes, usability studies (testing with people from the community), dogfooding (testing with Google employees) and search experiments (testing with a small percentage of Google users). Some of our early prototypes weren’t perfect. For example, we tried a prototype where we waited for someone to stop typing before showing results, which did not work. We realized the experience needed to be fast to work well. We also considered other interfaces which essentially clustered results for a variety of queries based on probability. Here are a couple examples:
Grouped results prototype
Blended results prototype
In the end, our grouped and blended interfaces seemed too difficult to scan while typing, so we pursued a model based on a single search. We hit upon two features that worked well together: first, a query prediction in the search box in gray text and second, results for the top prediction that update continuously while the user types. In user studies, people quickly found a new way to interact with Google: type until the gray text matches your intention and then move your eyes to the results. We were actually surprised at how well this worked—most people in our studies didn’t even notice that anything had changed. Google was just faster.
The infrastructure challenge: 5-7X more results pages for typical searches
We’ve been optimizing performance and speed for more than 10 years, and we’ve found that every second counts. When we came to the infrastructure team and said, “we’re going to be serving five to seven times as many results pages for each query performed in Google Instant,” first they threw a fit, then they figured out how to get us there! Even before Instant, Google was serving more than a billion searches per day, and our systems were optimized to ensure those searches happen as quickly as possible (usually less than a quarter second). How could we serve so many more searches without breaking or slowing down our systems?
One solution would have been to simply invest in a tremendous increase in server capacity, but we wanted to find smarter ways to solve the problem. We did increase our back-end capacity, but we also pursued a variety of strategies to efficiently address the incredible demand from Google Instant. Some of these are quite technical, but here are some examples:
- We deployed new caches that can handle high request rates while keeping results fresh as we continuously crawl and re-index the web.
- We introduced user-state data into our back-ends to keep track of the results pages already shown to a given user—this way we don’t re-fetch the same results repeatedly.
- We optimized page-rendering JavaScript code to help ensure web browsers could keep up with the rest of the system.
The engineering team at work
As Google Instant neared completion, we packed the core teams into two large rooms on our main campus. We began having daily stand stand-up meetings (more than 50 people). With all that hard work behind us, we’re thrilled to see Google Instant out in the wild! But, in some ways, this is just the beginning of a new kind of “conversational” search interaction. We will continue to experiment, as we always have—and with the help of your feedback, we hope to make Instant even better over time! While it’s a big change, I personally believe that we’ll look back and wonder how search was ever any other way.
Members of the Google Instant team watching the launch announcement
