About Irene Au
Last Friday we had the largest attendance in the history of the ZURBsoapbox speaker series. It’s the first time we had to actually amplify the speaker to make sure everyone could hear Irene Au (Google’s Head of UX) share some juicy insights of the design process and decision making behind Google’s products.
For this soapbox we changed the format up to be a moderated Q&A session to give some continuity to our discussion (and maybe ask a few more controversial questions). Below is a quick summary of a few of the questions we asked. Enjoy the full program on the podcast below and don’t forget to sign up for reminders of the next soapboxes in the New Year!
Do engineers drive the product?
"Product development is a function of engineers, product management and UX people working together. UX consists of UI designers, user researchers, 'prototypers'. Most of time these three roles are true partners in product development. Engineers are active participants in coming up with product offering. To say that engineers solely drive product and design would be an overstatement."
How do you get tangible results from a brainstorm session?
Irene said it’s really important for her teams to walk out from a brainstorming session with at least one tangible prototype. It can be a prototype or even a sketch. People just need something tangible to hold on to, to reference and to go back to in order to move the idea forward.
Doug Bowman (now at Twitter) claimed he left Google because designers are strangled by data analysis. True?
“Doug Bowman is a fantastic designer, we've worked together very closely and I was actually in the meeting where he talked about his reasons for leaving Google.”
Irene said that Doug’s fairwell blog post is partly true and partly not. Google did not go through endless rounds of testing to determine the border size on their search page, but its true they did test 41 shades of blue for the links. Search is a massively trafficked, but fragile interface where minute changes have huge impacts on how people use and perceive the results. Anything from typography to bulleting or numbering search results can dramatically impact user behavior worldwide. Irene thinks that context warrants some testing.
The role of data in design at Google gets exaggerated. People forget that design at Google is just as often faith-based as data-driven. Designer’s instincts and gut reactions come into play, especially to identify opportunities for new breakthrough concepts. Any designer needs a basket of tools at their disposal that includes all of these things, whether they are making pixel-level or high-level product decisions.
Have you seen a site recently which you liked which was not created by Google?
”I really liked Quora’s design. Not just the visual design and interactions but the filters and triggers to ensure the quality of the content. They did a phenomenal job of not turning into another Yahoo Answers. Kudos to Rebekah Cox for a job well done!”
Any tips for an interaction team to get traction in their org?
Irene mentioned that it’s really helpful to present options. Specifically she recommended that interaction teams present 3-4 options for visual direction, product offering, feature sets. This helps to focus the conversation around the trade-offs of these different options, not the shortcomings of one lone option.
Give one piece of advice to designers around the world
One universal law at Google is “don’t be slow”. No matter how great the product is, if it's slow, people will leave. This is the biggest factor of any Google product. There is a lot of design considerations that feed into speed.
We’d like to thank Irene Au once again for such an entertaining and insightful look into Google’s culture and decision-making. Thank you to all of you who were able to join us. We look forward to seeing you guys in the next soapboxes in 2011! Feel free to check out the ZURBsoapbox archive and make sure to signup for an email reminder below.
Transcript
Irene: Just pixel-level changes can have an enormous impact on how people consume the page and use the product. Even if an experiment is a failure, that's a learning in some way that can feed into future work that we do. To them, it just seemed like the search results appeared a lot faster than they usually do.
Moderator(Dmitry): So, let's sit down right here. So, Irene, welcome to ZURB. Super excited to have you here.
Irene: Thanks for having me.
Dmitry:Let's just get right into it. What are you working on right now? What are you doing right now?
Irene: Well, my role at Google is I run the User Experience team. We work on all Google-branded services and products. That includes Search, Gmail, Docs, all those things that you named. We're working on a variety of stuff. I mean, you name it. Everything kind of falls under my purview.
Dmitry: So, what's your day like. You wake up, you get excited, you're like, "Oh, I'm going to come in and just crush this today."
Irene: Yeah. Well, today, I picked up my Nexus S phone . . .
Dmitry: Nexus S, okay.
Irene: . . . and I came over here. Yeah, it's the new Android phone.
Dmitry: Okay.
Irene: A typical day is a lot of meetings, meeting with designers, meetings with engineering and PM leaders across the company, figuring out where are we going, what should we do, how does UX enable the company to meet its goals and get products made. I think since we have one large User Experience team — it's more than 200 people. It's a mix of UI designers and user researchers and front-end developers — we're working on a huge range of stuff. So a lot of it is really, like, "How do we invest our time and energy in the most useful ways possible, whether it's in terms of designing actual products or taking a step back and helping teams imagine the future or doing infrastructural work-like style guides or things like that to ensure a coherent experience? There are kind of like a portfolio of things that we take care of.
Dmitry: So, what's the process like? So, somebody has an idea, we're just going to do this, right? What happens next? How does the brainstorm evolve? How do you take an idea out of that brainstorm, code it up and launch it? What's the process? I know it's a very creative process.
Irene: I can't say that there's, like, one process that all of Google uses. There is a variety of ways that ideas kind of emerge and then come to life. One example might be some engineer has some really cool idea for something that could be built. Maybe it's a feature for a product or maybe it's actually a new product. Or, maybe it's a designer or a product manager who has this idea. We kind of have an ecosystem of start-ups, in a way. People from different functions can kind of band together and make stuff. Then we see if it grows. We start prototyping things, and as it gains traction, then maybe it becomes a real product or a real feature that goes out on experiment.
There are other cases where we'll do brainstorming in more structured ways. For instance, we might run a design sprint. Sometimes, that can be in collaboration with engineering and PM, or sometimes it's designers who get together for concentrated periods of time to kind of brainstorm and sketch things out, and then, on a daily basis, kind of reconnecting with engineering and product managers on the team, too.
So, yeah, we might run more structured design sprints where we might have specific design problems that we're trying to solve, or maybe it's a specific business problem or there's a stimulus that gets input. Maybe it's user research, insights from our users that feed into the process. Those kinds of workshops are definitely more structured. That's where we'll deliberately try to source a huge range of ideas and go through a process of coming up with different conceptual directions and then vetting from there.
Dmitry: You talk about engineers and designers and both of these working on one team. People say that engineers actually kind of drive the product at Google. I have numerous friends who say, "Oh, if [you're] not an engineer, it's not really worth going up and working there," or something like that. And then, I read these articles and they're all about, "Well engineers sort of just own the product." They're going to put the brains into it, so they sort of drive the whole process, right? So the designers, they're sort of assisting engineers as far as product development. Can you talk a little bit about the process there, the dynamic between designers and engineers and how they work together to create a product?
Irene: Sure. I mean, usually, the collaboration is one that consists of engineering, product management and user experience. Within user experience, it can be a variety of folks who are UI designers or user researchers, prototypers, web developers, what have you. It's a collaborative endeavor. I think in the most successful cases, they are true partners. Usually, it's kind of a triumvirate, where you have User Experience, Product, Engineering, and they're working together to kind of conceive the future.
Google is a company that has been successful because of its technological innovations, so of course, engineers are going to be active participants in coming up with what our offerings are going to be and what our feature set is. But I think to say that engineering solely drives the development and design of our products is maybe an overstatement. I think it's more collaborative than that.Dmitry: Are there ever quarrels or fights between the two groups?
Irene: Of course. Yeah, absolutely, and I think that's really healthy. You have to have room for creative conflict. That's when you'll often get the best solutions and the most creative solutions. We actually encourage that.
Dmitry: Can you think of an example of a quarrel between [inaudible @06:35]?
Irene: Yeah, but none that I can really talk about right now.
Dmitry: Gotcha. Okay. Let's jump into using data to drive your decisions. Multiple people have mentioned before, and I know I've read in Doug Bowman's blog post before, about how data sort of just drives everything. Every little decision, as far as a border size, 41 shades of the blue button, is just super, super, super data-driven. His view on it was more . . . he couldn't really take all that data, right? He couldn't work under those conditions. I'm wondering, what's your take on that? How are designers influenced by data, and are there other people who are saying that it's too much for them as well?
Irene: Doug is a fantastic designer. He and I worked very closely together, and I was in that meeting where we talked about all these things. I think what you read in the blog post is not necessarily the full picture, and kind of leads you to believe that we're, like, live testing different border widths to see which one should be the right width, and that was absolutely not the case.
It is true that we did do the live testing of the 41 shades of blue to see what our link color should be in our search results. One thing that's really interesting about Search — and it could be true for any product, but we especially know that this is true for Search, and I knew this even in working at Yahoo before I joined Google, when we were working on Search — is that Search is a very fragile interface. Just pixel-level changes can have an enormous impact on how people consume the page and use the product. You can see this more easily with Search, perhaps, because of the nature of the product. You have the search results page and there's a clear task, and maybe it's easier to define success metrics and things like that. But anything, from the typography, the lettering on the page, whether results are bulleted or numbered, or whatever, can have an impact. And here, we have access to the data, so if you have that information, why not use that as something to consider when you're making design decisions? So that's kind of how we looked at it. Certainly, where there are variables that do have an impact on usage and the user experience, we do want to take that into account.
But I do think it's kind of exaggerated, the role of data and the role that data plays in design at Google, certainly, for all the other products that we work on. And I would say, even now, for a large number of the initiatives that we have on Search, it's much more about design, and to some extent, there's kind of faith-based design work. It's not just purely data-driven. Your design instincts have to come into play, and there's a level of creativity. I think data can only tell you so much, but it's not necessarily very useful when you're trying to conceive entirely new product concepts or directions, right? You need to have kind of a basket of tools at your disposal to be able to make decisions, whether they're pixel-level design decisions or high-level product concept decisions.
Dmitry: Say a designer has a mock-up or something he wants to submit, or if it's a team, maybe three or four or five of them are submitted, how much testing actually has to be done and how much of it is actually thrown out? You know, there's one guy who's working on one mock-up, one design, and he submits it. Another guy does another iteration, another iteration, etc. All that stuff gets submitted, and then some team over there is going to test all that stuff out, and then how does that process work?
Irene: It doesn't quite work that way, and it also depends on the product. For something like Search, we're running experiments all the time. We'll host kind of "hackathons," where engineers and designers and product managers will come together, and they'll hack together ideas that they might have for Search — how to make that better, or what Search in three years might look like, or things like that. So we're constantly running experiments and learning from those. Even if an experiment is a failure, that's a learning in some way that can feed into future work that we do.
In other cases, like if we're doing design work for another process like Gmail or Docs or Maps, or something like that, I think the design process might work pretty similarly to how if any of you might be doing design work. You have particular goals and objectives that you're trying to achieve through the design, and you might come up with an array or range of possible solutions. Those will get vetted. Ideally, they would be prototyped and you would have a chance to use them, and I think, particularly with some of our apps, it's really important to prototype with live feeds of data because the experience can be dramatically different when you're actually using a design with your own data and you're trying to, you know, read your own mail, as opposed to just seeing a pretty static mock-up. So I think it has to be a rapid iterative, prototyping and assessing kind of process.
Dmitry: Do you guys document lessons learned from all the designs that haven't made it through?
Irene: In a systematic way, across all of Google, consistently, no. It's really up to the individual teams to do that.
Dmitry: Do you ever launch products as experiments? Like Google Buzz, or something?
Irene: Sometimes we launch products that turn into experiments. You might remember, like, Lively, or maybe Google Wave. Those were certainly cases where we didn't really know how the market was going to receive those products. In a way, Google is kind of an ecosystem of organisms, and the organisms are different products — you see if they'll grow and maybe they'll stick and maybe they won't. But just as is the case in evolution, when you have things that are not successful, aspects of those things may re-emerge in another place in a more successful way, so we take every opportunity to learn as much as we can, whether it's considered a success or a failure.
Dmitry: Moving on, I want to ask you about Google Instant. It's been in the new lately. It came out, and it had this awesome page that said, "We're going to save you two to five seconds on your search," and we're saving hundreds of millions of hours of search and humanity is going to be functioning faster, basically, right? It's great tool. So, a lot of people talk about, or at least I've had a number of people mention to me, "What is this thing? It's too fast. There's stuff flickering. I'm going to turn this thing off." How many people are bailing on this thing?
Irene: We've actually had a really low opt-out rate, so it's been one of the most successful launches, I think, we've had in a while. Definitely, for this year, I think, it's one of the most remarkable ones. It's been really well received. Some of the things we noticed in user testing . . . we user tested this a lot because we wanted to make sure that we got it right and there were some things that were very important to us. We didn't want it to get in people's way. Google is something that people use every day; it's part of your workflow, but if it's trying too hard, it ends up getting in your way. We wanted to make it as helpful and as minimally intrusive as possible, so there was a lot of care in making sure that it disruptive to people. In fact, we were delighted when we saw in user testing that people didn't even notice Google Instant and the search results showing up. It just kind of worked for them, so that was really good. To them, it just seemed like the search results appeared a lot faster than they usually do, so that was really great.
Dmitry: When I first saw it . . . I mean, I get the point that you search faster, and for you, you're displaying ads faster to people as well. Has is significantly moved the needle as far as revenue goes or any of the ads displayed on there?
Irene: I don't think I can comment on that. I certainly don't have any [inaudible @15:51] into that, and if I did, I couldn't tell you.
Dmitry: What was the actual process that that specific product went through? Somebody came up with it — how did it evolve?
Irene: It's so funny because the idea certainly wasn't new to 2010. There are early concepts for this that date back a couple of years ago. You might remember that we did kind of a visual redesign of the Google Search results earlier this year. In the process of doing that, we had built all this based on a prototype, and the foundation for that prototype was this concept of "search as you type." It just kind of became, like, this mean. Once people started seeing the prototype and started using it and seeing it in demos, people were, like, "We have to build that. That is so cool." So that's really how it got a lot of traction. The idea was around for a while, but the prototype really just brought it to life. So that was really powerful.
Dmitry: You've talked a lot about brainstorming in some of the interviews I've heard. What happens to an idea after this brainstorm session? A lot of times, people just brainstorm and brainstorm and brainstorm. It goes for hours, and then people come out, and they're, like, "Yeah, we did this. They got the meeting minutes down, and this is what came out of it." How do you take real results out of something like that and kind of go on with that?
Irene: It's really important to us that we walk out of brainstorms with a tangible prototype of something, even if the prototype is, like, a sketch, a skit, like two people acting something out that kind of prototypes the experience that you would have. But ideally, it would be something that's a very tangible prototype that gives you something concrete to walk away with and then go build, maybe at a higher fidelity. Something that people can interact with and kind of relate to, rather than these abstract ideas.
Dmitry: So a drawing or prototype that people can relate to later on to kind of move the idea forward?
Irene: Yeah.
Dmitry: What's the approval process like? What happens after? Say you've got this little drawing: somebody has to drive it, right? Somebody out of that brainstorming session is going to take that sketch and be, like, "This is what's going to . . . "
Irene: It can be done in a variety of ways. Sometimes, we take a top down approach, where we kind of sell to certain stakeholders who are empowered to say, "Yes, we need to build this. We're going to allocate resources to it and we're going to get it done." Sometimes, it can be more of a bottom up approach, where we just sell it to some people who might feel passionate about it as well, and then, in a skunk-works way, build it up to a certain point and then start selling it across the organization. So it can happen top down or bottom up.
Dmitry: Well, I'd love to hear your questions. You've been listening to the discussion. We've got about 15 minutes for you guys to ask your questions, so here we go.
Audience Question: When you look at the future of web apps, do you see or kind of envision particular themes that you see going on in the next three years?
Irene: Well, they're certainly becoming much more dynamic and interactive. I think animation is increasingly playing a huge role. Those kinds of details are really important to get right. They add delight, they give you a sense of where you are, and I think it's something that some designers just haven't really paid attention to in the past because we're so used to a static, page-to-page model. Even for the products that are web apps today, it's kind of driven through, like, click, click, click, and then keyboard shortcuts or things like that. I think we're at a point now where latency is less of an issue than it was before. Web technologies are more advanced, and so it just allows us to add in more delightful elements like that to the experience to appeal to people's emotional connection to the product.
Audience Question: Hi, Irene. Greg [inaudible @20:20]. I love that you talk about adding delight. That's a really powerful concept, I think. In the data-driven part of your design, how do you think about delight in measurable ways? What are you doing to measure user delight?
Irene: We have internal metrics that we refer to as "user happiness." I can get into details around that. Delight is an interesting one, because I think that's really hard to define in concrete terms. It's like, "I don't know how to define it, but I know it when I see it." We are looking at how we measure the success of our products, how we measure the quality of our products and how we create metrics to make sure that we're focusing on the right things rather than have our products be the sum of features, or things like that. I think that's something that's really in development and part of an ongoing conversation.
Audience Question: What was the role of [inaudible @21:22] in building or creating Chrome OS?
Irene: The OS or the hardware?
Audience Question: Both, actually.
Irene: The hardware was not done by this team. It was outsourced to an industrial design firm. The browser and the OS itself were designed by a couple of designers on the team, really talented folks. I have to say that what's really remarkable about their skill set is that they're software engineers, but they're amazing designers with an amazing eye for visual design and interaction design. One of them was the inventor of Quicksilver. Just really fantastic. I think that really contributed to the success of that design.
Audience Question: I have two questions. First, what are three books on websites you can recommend for designers? I'm a developer, and I want to learn design. The second question is following up on the web apps question. I've noticed that web apps are mostly, like websites, or there's just a [inaudible @22:50] websites. You mentioned animation. So you're saying that they're going to be like more flash or [inaudible @22:57]?
Irene: Yeah, I mean, I think they're just going to start feeling more dynamic and rich.
Audience Question: [inaudible @23:10]
Irene: When I think of a website, I think of a page-to-page model. You click on a link, and then the page refreshes and goes to the next page, or, like, the state changes and then you get a new page, right? For a web app, I think of it as a multi-state kind of page, so, within a single page, when you click on stuff, you're not necessarily getting a full-page reload, but things are happening within the page that are more dynamic. Does that make sense?
Audience Question: Yeah. How about books and websites?
Irene: Okay, books and websites. You know, it's funny, but I don't have a lot of time to read books. I think there are some really excellent UX books out there. Luke is a great one on forms. In fact, I think all of the books that are published by Rosenfeld Media are really fantastic. His books are really focused on appealing to the UX community and/or people who are especially interested in UX. If people are new to UX, I think a common book that is often referenced is Steve Krug's "Don't Make Me Think." I think it gives you a really nice foundation for thinking about user testing and things like that. "The Elements of User Design," there are just a lot. I think it's important to get a range because UX is so multi-disciplinary. Increasingly, what I see is that the designers who have multiple skills, not just specialists in one particular area, but really multi-skilled in front-end technology as well as interaction design, user research and visual design, those are the ones who are the most highly sought after by companies and the ones who are the most successful inside companies. So, in terms of books and websites and things like that, I think it's important to make sure you cover the range and learn and grow in the different areas where, perhaps, you're the weakest.
Audience Member: Have you seen anything recently that's tangentially related to what Google does for the best search or smart phones or browsers or web applications? Have you seen anything recently that you wish you could just steal? Or something you really like that you could take and do more with and it would be better?
Audience Member: Other than the iPhone.
Irene: I don't know if I really understand the question. It's kind of like you're asking, "What are the really great products?"
Audience Member: What have you seen recently that you really liked that wasn't Google's?
Irene: Oh, okay. Well, that's more straightforward. You know, I really admire Quora's design. I think that's been a very successful design, not only visual but also interaction and just in terms of how they have built in mechanisms for ensuring high-quality content. So, for a Q&A site, it didn't turn into, like, a Yahoo Answers, with really spammy content. There's a lot of really rich, high-quality content there, and it's one of my favorite sites to visit on a daily basis now. So kudos to Rebekah Cox and the team there. I think they did a fantastic job.
Audience Member: So when can we expect the acquisition?
Dmitry: I think that gentleman had his hand up first.
Audience Member: This is kind of related, but how much weight do you put behind competitive analysis? Do you look at Amazon or Bing and take little bits and pieces, or do you just run your own tests and do a comparison?
Irene: It's not a huge part of our development and design practices. I think it is important to understand what your competitors are doing and where they're going, but you don't want to be looking over your shoulder all the time, either. You want to be looking ahead and thinking about how to leverage the strengths that you have to create an offering that's unique and interesting in ways that nobody else can compete.
Audience Member: Do you have any tips for an interaction team getting traction in the actual decision process of a company?
Irene: Yeah, that's a good one. I find that it's really helpful to present a range of options. What we're starting to do now is to present three to four options, whether it's for visual design directions or a concept for what a product offering or a feature set should be. Ideally, there would be three or four viable alternatives, because I think just in the act of offering those up, it really helps to force conversations around, "What is the most important thing? Where do we want things to go?" It allows people to juxtapose the trade-offs in a very tangible way, whereas conversations in the abstract without actual mock-ups can get you almost nowhere. You end up, like, fighting religious wars in some way. I think that alone has been one of the biggest techniques that we've been able to use.
Audience Member: Can you talk a little bit more about what you said about faith-based design and the need or role of user research or following standards versus intuition, as you put it.
Irene: A follow-up on it, or talk more about it?
Audience Member: How important is it? How do you balance doing things based on research and standards and kind of what's out there versus, "Oh, I have a cool idea and I think it will work. Let me design something, and then you test it after that."
Irene: I think research is an input. There's kind of a feed-forward, and then there's also feedback. So you use user research as a stimulus to inspire new ideas, and then you can also use user research to help inform, like, how to improve something or how to iterate. Both are really important. At the same time, you want to be always new, always fresh, so even when feel like you've reached some local maxim, I think it's really important to always take a step back and think about, "How can this be better? How can this be always new, always fresh?" Sometimes, that's not necessarily going to be informed or driven by user research. Actually, within the company, we sometimes refer to it as "faster horse." The story is, before cars were invented, if you asked people, how they would like to get around, they'd just say, "I'd like a faster horse." User research isn't necessarily going to tell you, "We should build a car," but it does help point out the latent needs that people have, that are pain points that might be opportunities for you to innovate in that area.
Audience Member: When you say, "faith-based," what do you mean?
Irene: Sometimes design decisions just have to be based on good judgment. Maybe it's difficult to get data, or maybe no amount of data can tell you what a design should be like. There's kind of a mood or an aesthetic that isn't necessarily data-driven. Something could be logically correct, but it could be emotionally incorrect, right? There are user research methods that you can use to try to get at that, but even that is qualitative, subjective data in small quantities. It's all based on user attitude and perceptions, which is still data, but it's different than live testing a shade of blue and seeing if that's successful based on some arbitrary success metric.
Audience Member: I think this is the opposite of the other question. I'm assuming that, in your position, you do a lot of critiques of other designers. You have a lot of people on your team. What, if any, is a common piece of advice you find yourself giving over and over. In other words, if there was one piece of advice that you could give to new interface designers and users, various designers in the world, what would it be?
Irene: Wow. That's a big question.
Audience Member: And yet, there is a recurring theme.
Irene: I don't know if that's really fair in terms of actual design because it's so dependent on the context and the product and the usage. There's no universal law, although, I would say the one universal law at Google, probably, one of the biggest things we care about is around latency and speed. We know that no matter how great or innovative the product is, if it's slow and the page loads really slowly, people are just going to leave and not use it. So that's one of the biggest things that we value as a company, and I think there are a lot of design considerations that feed into it. But design in general is so based on context and usage that it's hard to get a [inaudible @33:06] on.
Audience Member: Can you talk about the design process of Google TV, and also, going forward, will you start actually designing more about things happening in the living room or maybe going to the kitchen or bathroom? [inaudible @33:25].
Irene: I haven't seen explicit product plans for that. Google TV was a fun one. Because we were an integral part of the team very early on, from the early concept phases, we were able to establish culture around rapid design and prototyping and evaluation. We built a usability lab that simulated a living room environment, which was really fun because you could go in there and just watch TV and it was like working. But the design process was really very similar to any other design process that we would approach for our products at Google. Now, there was also the hardware aspect of it. We partnered with Logitech and Sony on those kinds of things. So yes, we played with physical molds and we did do a lot of usability testing on different kinds of text input methods, like whether you had a huge keyboard sitting on your lap or a little remote or using your phone. Those were added aspects of the design problem that you wouldn't normally see in designing other products at Google, for example. But in general, the process was the same.
Dmitry: We're probably out of time. It's 1:00 p.m. right on the dot. I'd like to thank Irene for coming out and having such an awesome Soapbox. And thank you guys. See you guys probably next year. Stayed tuned to the email, and we'll have more great speakers.
