We have a saying, which is "Don't break search." If you think about Instant, the basics of what you do in terms of searching on Google still work. You go to Google, you begin issuing a question or a query, you see whether or not you're getting the results you're looking for, and you make decisions about that.
That basic experience continues to exist. The difference is that we've made it a lot faster.
We do a lot of user research, and we run a lot of experiments. The user research spans a pretty big spectrum. On the one hand, there's a lot of generative, evaluative research. We go out into the field, talking to people, figuring out what kinds of questions they have about their world. What are things they want to know that we could provide as a search experience?
We [also] have research labs here on campus, and we invite users to come in and use the product. That's much more qualitative research. Are we actually solving the user's problem?
In the case of Instant, it was actually really interesting. When we were building the demos and walking through the process, a lot of people were really concerned about it. If you think about it, you start typing your query and suddenly the page changes. As fast as it was in terms of speeding up the conversation you have with the search results, we worried it was going to be distracting.
But it was actually really surprising. When we brought users in - and we just let them use the product; we didn't really say anything about it - they would use Google search with Instant turned on, and after a moment, we would say, "Okay, well, tell us about your experience," and they would say, "Well, I dunno, it's Google."
What you're seeing, from a UX perspective, is an attempt to introduce something that is rather new. It's a new way of looking at things. Sometimes we want to over-communicate in the UI. You've changed something, you're changing expectations, you may be changing behavior. So you look for ways to try to communicate this.
One of the great things about working on products at Google is that we can try stuff out and launch it as an experiment and get tons of data. As a designer, I feel very lucky because I have access to enough data and enough users that I can actually get statistically significant information on whether or not something should be this tall, or this tall, or this tall.
Some designers, it drives them mad. But I think, if you knew that this mock-up is actually, objectivelya better experience for people than this mock-up, you'd totally take that.
On the toolbar, this is actually a very complicated design problem. One of the dials that you're turning is making it a functional, useful, discoverable tool. But other dial you're turning is that you want to make sure you have enough space on a variety of devices and screens to make sure that the application [the user] is in is given as much space as possible.
Sometimes these trade-offs come into conflict. We have to do a lot of designs, a lot of experiments, a lot of iterations, and so in this particular case, we're in the middle of that process. We're trying some stuff, we're looking at it, we're seeing how it works, taking that learning, walking it back and iterating on that set of designs.
We're pretty open about what we do, so we iterate in public a lot and try different things out. This is what happens on search in particular. We're running tons of experiments all the time to tweak and fix and change.
