Welcome everyone. We're here today with Dan Russell who is an uber-tech lead and director of search quality and user happiness at Google. >> Right. >> It's great. Great to have you here, Dan. >> Thank you, Scott. >> And we have a question that seems deceptively simple, but I think actually, there's a lot to it. So the way that we use the web today is we have the box on Google. And people type stuff into that search box. >> Right. >> And we get a bunch of results out of that. And search drives a lot of people's interactions with the web. And for designers of websites or other internet content. What's something that they should know so that it plays nice with a web search ecosystem. >> I thin the answer is that, designers have to know what any good content creator has to know, which is to basically make good content. It's easier for example, to do very clever things and have dynamically loaded content that's not actually on part of the page but it's created or pulled from different resources and that makes it tough to index. Because if the crawler comes around and sees this page but the page is not the page, cuz it's dynamic for every person, then what gets indexed? Well, whatever's on the page, so don't be too clever. It's very easy to create stuff that looks great, smells wonderful, but what do you index? Unclear. So that's one thing, don't be too clever with the design. If the information is on the page then it should be on the container of the HTML box. Second thing. You know there is a lot of stuff you can do for example using tags and all this stuff. And the truth is most of that gets ignored. I mean for example there are some people who try to optimize their page by putting white text on a white background. That's actually a penalty. People I don't think know that but we, in crawling through these pages, look at a lot of different features but the thing that dominates, the thing that makes your page come to the top is high-quality content that people like, people use and people click through. That's the primary directive for this kind of stuff. And for designers who are making this site. We talked about the errors of trying to gain the system or of not have a page there because it's dynamically loaded. Is there a usability error from a google's perspective that you think is common that people could do better. If you got to wave your magic wand. >> Right, right, yeah. >> Or in this case talk to a lot of students online. What's something that we can do better? the primary problem I think, from experience perspective is people create very heavyweight pages. By that, I mean it takes a long time to load. And so one of the common errors I see is people creating this giant animation and it slowly loaded, and it takes many seconds. And even if it takes five seconds, which doesn't seem long, but if you're a user, we know that 50 or 100 milliseconds. Makes an experiential and a use difference. If your flash innovation takes ten, 20 seconds to load, forget it. You've lost these people. So, yeah, we'll index it. Yeah, we'll put it in our search results. But people will click through that thing. They'll get the search results. They'll click. Five seconds they'll have it done. Back, and you've lost them. So your page has to be fairly light weight, load quickly and be visually salient. It's very easy especially for young designers to put five point font, light grey, on a black background. Very cool, impossible for half of your population to read. So don't do that, make it visually simple, it's the kind of thing where if you can't read it from, especially with my glass, from that way away, you've lost. So think about designing not for you and your twenty three year old friends, think about designing for your parents, think about it for somebody who is actually going to try to use it and not just look at the cool factor. its use not cool. >> Mm-hm. >> [INAUDIBLE] >> And is there, you know one thing you can do with Google is that you can use Google Analytics to keep track of what people do with your site. I think a lot of people who have tried doing fancy analytics imagine that good information will come to them magically. And of course, that's never true with data. For a designer who's starting out with Google Analytics, what is one thing that you would encourage them to take a look at? >> In the analytics space, especially when you're beginning, >> It's very easy to get wrapped around all the complexity, and I think the high-order bit there is to look at very simple statistics. How may people click through there? Where do they come from? What are the sources? How long can they spend in the page? How long they leave. But almost more important than that is having some sense of proportion. That is, I remember when I first looked at some of my pages I thought, people stayed here for five seconds, ten seconds, and I was depressed. And then I looked at a lot of other pages and I realized that's not bad. And so some of the statistics will look terrible. But until you get some basis for understanding how other pages look, you really don't know. So it's one thing to look at your own site. Go look at someone else's site. So, Scott, let me look at your statistics! All right. I got 10 seconds. You only got 5, right? >> And that's something that you would do by having a friend who also has the same tools installed. >> Yeah. It could be a colleague in your design shop or in your school or something, but yeah. I would love to look at your analytics. [CROSSTALK] Show me your analytics. Please. >> This is like the museum exhibit design problem that nobody spends nearly as long in front of the museum exhibits as we wish they did. >> That's right. In particular, it's one of these things that's impossible to discover from usability studies. Somebody comes into your shop, you put them in front of the computer and watch them and they will lovingly sit there for minutes at a time and you get a completely wrong impression. The reality is, people are busy. They probably don't wanna spend that much time on your site. They wanna get in, get out, move on. >> They got 17 other tabs open already. >> Exactly. >> And so you mentioned usability studies. Is that something that designers should still do? Is it still worthwhile to drag somebody into your office? >> Yeah. >> Or in this age of big data, >> Do we not need that anymore? >> I'm a true believer in mixed methods. So I love logs analysis, I love the statistics of analytics and so on, but very little beats actually, for example doing your field study, going to someone's house and watching them use your stuff. >> Yep. >> Because it's one thing to bring someone in, and the downside of usability study is if they're in your shop in your space trying to make you happy. You go to their house. Just happened to me. Go to someone's house. They come to your page, they hit the back button like that and say I hate this. Not realizing that you've actually made the page. When you hear that, that's an important signal. Yeah, usability studies are really important. Partly because big data, there's so many ways to cut it, so many ways to look at it. How do you know what to look at? So the intuition you gain from usability studies or from field studies drives your analysis, drives your looking at the data. So yeah, you need all these methods. >> And it's a lot easier to ask questions when somebody's there in person. >> Exactly. >> And what you're saying is that whenever possible >> Go to the place that somebody actual- >> Right >> Does that stuff. Whether it's at home or at work as opposed to having them come to you. Because that changes the energy of the, the discussion. >> It changes the whole goal of the person. The goal in one sense is to make you happy where as an in situ study, the fancy word for being there- >> Yep. >> Right >> An in-situ study, they have their objectives. They're not necessarily trying to make you happy. They wanna live their life. >> They're just getting work done. >> The second thing that happens there, is that people are contextually cued. They see things in their own environment, their office oh, yeah, that's what I'm doing. And they get reminded of things. They get reminded of tasks. They get reminded of ways to do things. They have all these context cues that help drive their behavior. It's the distributive cognition argument. But, here, it's in a cueing sense. And that happens all the time. So yeah, you gotta get out there. >> Well, we've got you here. Google is a widely respected employer, and I'm curious, for somebody who's starting their own design company or working a designer in an existing organization, what's something Google does as part of its design practices that you think would be a good habit for everybody? It's a great question because I think a lot of people look at the Google working environment and the lessons they extract from that are you need bouncy chairs. >> [LAUGH] >> Or you need primary colors. Or you need 20% time or whatever it is. And that's actually now the big lesson. I think the big lesson is iteration. It's just sticking to the goal. And it's a kind of basic design one on one, but it's one of these things where you put out a design and you look at the data with a cold eye. At what's actually happening, not what you want to have happen. Not your prejudiced view of that, but what's really happening. and then saying okay let's do another one, let's do another one, let's do another one and going along with that is actually doing the experimentation. It's one thing to put up multiple iterations, but if you never look at the data, you're wasting a lot of energy, you're wasting people's time, you're wasting your energy. So iterate about the design but evaluate that didn't I. Evaluate and learn to see because what you're really doing is iterated and going towards a solution that's better. That's a really key lesson from design lesson. >> So what you're telling me is that we look at google and think there's a lot of smart people that work there. >> Right. >> What you're saying is that the smarts is not, that that doesn't lead them to get it right the first time. That the good design evolves- [CROSSTALK] >> If only you knew. >> [LAUGH] >> How often we got it wrong, right? No, that's exactly right. >> And in fact even the things we see that do get wrong had 200 or variations. >> Right. >> Before we see it. >> Yeah, and sometimes these changes are. Subtle, I guess is the best way to put it. They're the kind of changes where if you change the color of a link just slightly, imperceptibly, you put them side by side, I can't tell them apart. People behave differently. And you'll never figure that out without actually testing, actually looking at the data. That's the big lesson for me. How is search changing over time? Is there a difference between how we searched five or ten years ago, and how we search now? Mobile is becoming increasingly prominent. Is that gonna drive changes in search in the future? Wow, big question. The answer is, everything is changing all the time, okay? But to break that down slightly, you mentioned mobile. It's a really important thing to know that roughly half of all the searches that are committed to Google now are in mobile, which is a big deal. Interestingly, Europe crossed that boundary a little while ago, before us. Of course, you knew that. So what's interesting is to see the shift as people move from their desktop onto their mobile device. And what's interesting is that, the way you interact with these different devices, cuz they're qualitatively different. I never use my desktop in a bar, right? [LAUGH] I never ask those kinds of questions in my work environment, and vice-versa. And so you see these very different use patterns, what's interesting is that the queries don't differ that much they're not erratically different, but the kinds of questions you see are different for example, an interpretation of pizza in downtown San Diego on my phone has a particular meaning. Well there's pizza sitting in my office and mountain view, totally different. so there's a lot of things happening like that I think to answer your changed question, search is getting smarter. It's getting more contextual smart about what's going on. So for example, we have a lot of. Not quite on demand, but sort of anticipating your demand, things that are going on. So you do a query now for something like bronchitis, and you see a panel on the far right side. So if I was to sketch it out here, what you'll see if you've got your query, you get your results here. And the right hand side there will be a little panel with a picture of a guy who's coughing his head off because he's got bronchitis. And it's anticipating the kind of question you would have here. Both in terms of additional information like how contagious it is or how the treatment should go or how long it should last and whether or not you should call your doc. Okay, those are probably the next couple queries you're gonna do. Imagine more of that. So, not only anticipating the next questions that will come on, but also questions that you haven't even formulated yet. >> In fact, that's probably a good principal for design in general. Designers should think about what question will the user have next? And there should be an easy way for them to get from here to there. >> Yeah, that's actually a great principal. You're always trying to think one step ahead. >> Yeah. So, for example, in contextual menus, what's the next question? What's the next action that the user will take? How can you best make that as fast and easy process? You want to keep people in that flow state, so that when you're drawing, you're sketching, when you're doing whatever, what's the next action? [CROSSTALK] That's a great route. >> That's how I end up reading Wikipedia for three hours straight without realizing it. [LAUGH] The last question that I have for you today, I think that there is going to be a number of students out there that would love to get a job at Google or somewhere like it, and what are some things to know that can help students succeed getting their resume seen, or if they get to an interview stage at a place like Google, to help them get the job? It's a little bit like the advice people used to give S.A.T. takers. It's a little bit like sure you can study algorithms, but the best thing you can do is actually do stuff, right? It's a little bit like studying for a math exam. You can read all that stuff, or you can do math. >> Mm-hm. >> The doing is better. So, a successful job candidate is someone who can actually say, well, I built this. I designed this. And show it. As opposed to someone who would say, I built a prototype in class, and I only ever used it with my friends. And so some really spectacular success interviews we've had have been who have built a little piece of code a real website that then had some adoption, had some real use. And all of a sudden, those people are able to answer questions like the analytics question you just said. Whereas if you've never had the experience, you haven't built that website, you're answering in sort of a theoretical way. >> Yep. And if I'm a Google interviewer, and I've got all this real world experience, and you're answering from a very theoretical perspective, the dissonance is huge. >> Yeah. >> So you wanna remove that dissonance by trying to be as grounded, and have real world experience as possible. >> And that's great, because one thing that students could do, for example, for the capstone project for this specialization is that they could take that project beyond just the class and build something that gets real use. Because you can answer the and then we did, and then we learned, and then we did, and then we learned question. >> Yep, That's right. And I think another thing is that HCI candidates often come in, or I meet them at conferences and so on. They say do I really need to know how to program? Yeah, you do. [LAUGH] You don't need to be the world's best C++ coder or whatever, but if you can't think algorithmically, cuz you're gonna be dealing with data, these log files and so on, and if you can't understand how to transform that data, how to deal with it, how to manage it, how to wrangle it, you're not a contender. So you really do need to know at least some of that stuff. >> Awesome. Well, thanks so much for taking the time Dan, this has been really fun. >> It's great. Thank you, Scott. [LAUGH]
