Subtitles section Play video Print subtitles JONAH JONES: Hey everyone. Thanks for coming. Today we're going to talk about the process of redesigning Google Maps. My name's Jonah. I've been working as a designer at Google for seven years now. ANNETTE LEONG: Hello everyone. My name is Annette. I'm also a designer on Google Maps. I've been at Google for 2 and 1/2 years. In the new Maps I designed the overall framework and image browsing experience. JONAH JONES: And I led the overall redesign. So Google Maps was launched back in 2005. And this time last year, we announced the new Google Maps. And this was the biggest redesign we'd ever done. Over the last year we've made a ton of changes. We had a long preview period. And now this is the new default experience for Maps. So there are some pretty major changes that have taken place. The map is now dynamic and full screen and it adapts to every single one of your clicks. And the imagery is also fully immersive in 3D. But as you can imagine, redesigning a product used by a billion people is quite a daunting task. And we wanted to share a little bit of insight into what our process was, so that you can design your apps to be ready for a billion users as well. And we thought about what this entailed. And we realized that it basically boils down to three key lessons. The first is to think big. So that you don't get trapped incrementalism. The second is to question everything, because sometimes your assumptions can be holding you back. And the third lesson is to listen to your users, because even if you think big and question everything, you're not going to be right about everything. So let's jump into the first lesson, which is to think big. We started with an audacious goal, which is that we wanted to redefine expectations of online maps. And if you look at what we had with the previous maps, we'd added so many features over the years that the old user interface was starting to get really, really cluttered. And every new feature we added was making it harder to find that new feature and the old features too. We'd added thousands of businesses. We'd added thousands of miles of Street View. And we'd also added further ways of transport, so it's not just about driving. It can be about walking or public transit. On a technology side as well, Ajax was the big innovation back in 2005 that let people smoothly scroll and zoom the map. But nowadays, there are more recent technologies like HTML5 and WebGL that let people do vector graphics directly within a web browser. And consumer expectations had changed too. The arrival of mobile had brought new paradigms for touch-based user interfaces. But even more fundamentally than that, we felt the existing mapping products were basically just taking this old scanned map and sprinkling a few pins on top and adding a search box at the top. And we thought surely we can do better with dynamic digital maps. So we went back to the drawing board. And we thought how would Maps be if we reinvented it today, using all of the great data that we have as a foundation and everything that we've learned over those last seven years. And we came up with this vision that we called "The Future of Maps." And we created this short video that we shipped around the company. And this was really, really good to get people on the same page about where our vision was, and where we were headed, and where our big thinking was going. And actually it's quite interesting. Looking at this video, there's a lot of the concepts that we had there made it through into the final product. So here you see we have a beautiful new set of rich dynamic bright map tiles. And this is Lausanne in Switzerland. And what happens now is we click on a transit station. And suddenly the map shifts. And dynamically becomes all about the transit network. Later in the video we do a search. And now we can see that the search results are the primary focused thing. And they're labeled too. And then toward the end of the video, we zoom in further. And amongst all of the regular points of interest, we see the places that I've been to, and I've rated. And the places that my friends have been to and rated as well. So this is a map built for you. Over to Annette. ANNETTE LEONG: While the concept video focused on the map tiles, it was a challenge to come up with a framework that could really support and highlight the maps itself. And yet be fully functional and easy to use. We wanted to think big. We wanted to be able to explore quickly and capture all possibilities. And wireframes and sketches were great for that. We made hundreds of wireframes and sketches to generate ideas and to [INAUDIBLE] and also lay out variations. This method let us go broad. Then, from a subset of these wireframes and sketches, we went steep. We started filling in with the right typography, colors, and visual elements to create higher fidelity marks. The look and feel of the product started to really come together. As we generated more and more of these marks, it can be hard to keep track of what's the latest version. It's like an engineer constantly asked you where can I find the latest file? So we needed a better way to organize them. As you may know, when engineers want to show progress of their latest code, they create a build to test how well the code in the biggest system. So we did the same for design. We created a design build, where we put in all the latest designs from individual designers into a single place. To keep things simple and easy to digest, we focused on a few key scenarios. Like finding a restaurant, getting directions, and browsing imagery. This let the designers, PMs, engineers, and everyone in the company to see where we were headed. JONAH JONES: So it's really important to think big. But if you want to think big, you have to be willing to question everything. So you could argue if it ain't broke, don't fix it. This seems fairly reasonable. But it turns out this isn't really the case with technology. As you saw before, adding more and more features meant that we couldn't stay still anymore. But also the world is changing. So by staying still, you're basically moving backward. So I want to give you a couple of examples of where we were questioning things as we were redesigning different parts of the system. And the first is around the map tiles themselves. So this is how the map tiles used to look, when you were looking at a world view. And you can see here that we've got some countries and some states and obviously the land masses and stuff. But we realized that actually this isn't answering all the questions that our users might have. Like why are people going to a map at this zoom level? Well first of all, you can't really differentiate between the cities and the states in the US there. You can't really see where the mountains are. You can't see where the forests are, and where the deserts are. This map isn't really doing everything that it needs to. So when we did the redesign, we answered all these questions. Now you can clearly see the difference between countries and states. We've got elevation data, so that you can see where the mountain ranges are. And we have vegetation data too, so you can see the lush green areas and the more barren orange areas. And plus also, we used a new brighter, more vibrant color palette, so this feels much more on brand than how it did before. The same is true at deeper zoom levels, too. This is the map of how San Francisco used to look. And you can see here our heritage, that basically we just used to be a road map. But that's really all you can see here. But even the roads, they're kind of overwhelming. They're really, really fat. And this orange highlight color and the yellow is being used way too much and not sparingly enough. And you also can't see all of the other information that people care about at this zoom level. You can't see the neighborhoods. You can't see public transit. You can't see where the parks are. So we really want to redesign this, too. So this new design answers all of the questions that people need to know about from a city level too. You can still see the road hierarchy very clearly, but it's cleaner. You can now see the neighborhoods too. You can see the businesses, the points of interest. You can see the transit information. You can see all of this stuff. Now another example is around this concept of a map of a place. So let's imagine that tomorrow after I/O we're all going to go for a picnic. And we're going to meet in the Pullens Gardens. And I share this map with you. Now on first glance, this map looks fairly reasonable. But if you look closer, this really isn't the best map that I could have given you. So for a start, there's a ton of labels on here that you really don't need to know about. And some of the labels you wish were there are missing. So if you look at the Pullens Gardens in the middle, you can see Penton Place bordering it. But you can't see the names of those other two streets. So surely we can do better than this. So we took inspiration from the kind of map that you might draw on the back of a napkin, if you were telling your friend how to get to this place. In that kind of map, people will only show the most important information. You can see here that all we're doing is we're highlighting the major roads that are landmarks and the roads that are nearby and bordering this place. These are the roads that you need to know about to get to this place, and the other ones are much less important. We even developed a pretty snazzy algorithm to approximate this kind of data, where we look at anonymized logs of all of the directions that anyone has ever got to this place. And we look at the most popular ones. And if you're interested on how this works, we get a Tech Talk last year at I/O that's available online, that goes into more depth. But so here we go. We've got these roads. We've got the ones that are important. But now we have to decide how we're going to render these on the map. So the first idea we tried was we thought, OK, let's take these important roads. And we're going to visually lift these up. And make them very prominent. And all of the other roads we're going to let sink back into the background. And this kind of conceptually works. You can see that it's a little bit like that napkin map we had. But there's one really big problem with this, which is that we've lost the sense of road hierarchy. You can now know longer tell the difference between the big major arterial roads and the more minor, local roads. So we had to come up with a solution that didn't interfere with the fundamental road network. So back to the drawing board. We try another version. And we thought what if all of the roads are grey. And we can convey the network using widths instead. And what we'll do is we'll light up these important roads. And this actually looks pretty cool, even on the [INAUDIBLE], you can kind of see the concept there. But what happened when we built this thing is as you're clicking around, the roads changing was just far too visually jarring. It created much too much prominence for what the feature deserved. So, threw that idea away as well. And we came up with this other idea. We thought, well, the way the algorithm works is it's basically taking directions. So why don't we just draw these tiny little arrows, because it's all about getting directions from the north, the south, and the east, and the west. This seems like a cool idea, right? But then we put this in front of people. And this didn't work too well either. We were too close to the algorithm. And it turned out that the users were confused between real sets of directions and these weird little blue arrows we were drawing everywhere. But the good thing about all of these explorations was that we learned something. So that let us finally come up with the end design that we did. This answers all of the problems. Now the most important roads are brighter and they're highlighted. They're labeled as well. You can see that those roads next to Pullens Gardens that weren't labeled before, are-- Crampton Street, Iliffe Street, Amelia Street. And the change is actually quite subtle as well. Because the other roads are still there, but they've just sunk into the background a little bit and the most important roads have lifted slightly, this is not such a dramatic change as you go and click around the map. It subtly draws people's eye, without being a massive headline feature. To give you another example around search results. So here, this is a search for bars in Sydney. And there's something quite interesting going on with this map too. Which is that we have a lot of places that are labeled on the map, but none of these are the places that you've asked for. These are all the generic things that were left on the map from before. Sushi Train, Oxford Vintage Cellars, Darlinghurst. And the very thing that you're interested in-- the bars-- they're not labeled. They're the only thing we don't label. This is crazy. So we've just got these red pins. And there's a letter, and you have to cross reference it. And part of this was because we didn't use to be able to dynamically render labels, but now we could. So we thought OK, we can definitely do better than this. So here's what we first tried. We thought, well the search results, they're conceptually the same as a landmark really. They're just a thing that we're going to highlight on the map. So why don't we just draw them the same as a landmark. And we'll just draw a little red circle around them to highlight them. But this had problems, which is that it looked kind of messy as you started zooming out. But even more fundamentally, you couldn't tell the difference between the most relevant search results and the search results. So it could get a bit overwhelming. So how are we going to solve that. We thought OK, what we can do is we can put the star ratings directly on the map. This seems like a good idea. But actually, here you can see this isn't working so well, either. The star ratings and the red dots are kind of competing with each other, and the whole thing looks a bit overwhelming. And it also turns out that star ratings are not the best way to differentiate between places. Because all the top places tend to be about four stars anyway. So what's a more human way of doing this? We thought aha. What we could do is we could take the top places. And we could differentiate them with some human readable text. So you can see here that Esan Thai is known for its pineapple fried rice. But Aroy Thai is known for the Pad Thai. Now this seemed like a strong concept. But even this version was lacking as well. Because typographically, you couldn't really tell the difference between the top and the secondary research results. And also we've lost some of the key information. You can no longer now see what type of business each of these are. We don't have the knife and fork anymore. So with the learnings from all of these different explorations, we finally came up with something that really worked. We used a bright red color to indicate the search results. And now they're conceptually very similar than the landmarks, which are much more set in the background. You can tell the difference between the top and the secondary results through size. And we've still got this very useful text string, which says herb marinated chicken, or whatever. So we put this first in front of users. And we were super excited to see how their reaction was going to be. We expected them to be blown away. Wow. You've labeled search results on the map. This is awesome. No one's ever done this before. And what actually happened was nobody noticed. And we realized that that's actually OK. Because of course the search results are labeled. Weren't you doing that before? People instantly forgot that we didn't used to do that. And it's a reminder that sometimes the best design-- people won't even notice it. It will just work and get out the way. So Annette's going to give you a couple more details around place details. ANNETTE LEONG: Similar to the napkin map design and the search results and signposts that Jonah gave, we are still questioned a lot on the place details. In the old maps, when you searched for bars, there's a list of results in the left-hand panel and also on the map. When you click on the result, whether from the left-hand panel or on the map, there was this informational window that appeared on the map. We asked ourselves, why does this informational window have to be that big and cover so much of the map? And secondly, why is the information showing twice? The same information is showing in the left-hand panel and also in the informational window. The more we question the UI, the more we can get a better sense of how we can improve upon it. We tried a version, what if we took away all the UI and had the search box only appear when you click on a place. It didn't really work well, because you expect the search box to be at a persistent location. So you click on the place and it shows up at a different location. It's a style strange. So we ditched the idea and tried another version. What if we want to show more of the map? So we show the text on the transparent background. This also didn't really work well, because as you can see, the text can be hard to read against different backgrounds. And also, the actions that you may need, like getting directions and saving a place, are hidden with another click away. What if we try a version that the text radiated from the place you clicked. Visually it looked cool and somewhat interesting. But it also opened up another can of worms. Like the space limitations and also legibility. And the more we questioned all these explorations, we learned from them. So finally, we landed on this version where the text-- the information about the place is always showing in the upper left corner in a predictable way. And this information box can be minimized when you want to see more of the map. Sometimes the problems can be obvious, but the right solution might not be. It takes questioning everything, exploring everything, to get to a much simpler design. JONAH JONES: OK. So the final lesson is that it's really important to listen to your users. And there's a bunch of different ways you can do this. You could run usability studies. You can study your user metrics. You can directly solicit user feedback. Or you can run an internal dogfood. Dogfood is the idea that you eat your own dogfood. So you test the app internally, before you release it into the wild, to the general public. But it's important that you do all of these and don't just focus on one. I'm going to give you a couple of examples of why this is important. So the first is around speed. So when we first launched the new Maps, we heard some users were giving us feedback that we needed to make it faster. And we thought, this is kind of interesting. Because when we looked at our logs, average speed was-- the new Maps was faster than the old Maps. But it turns out that wasn't the whole picture. It turns out the for people with fast computers and fast network connections, the new Maps was indeed significantly faster. For people with average computers and average connections, the new Maps was a bit faster or about the same. But for people with slow computers or slow internet connections, the new Maps was slower. That's why people were saying this. This is a problem. They were kind of seeing something like this. They were seeing this extended loading screen. And they were waiting for that to load. Oh, man. This is so slow, come on, come on, come on. OK, it's loaded. And so we sent our crack team of engineers on this. And they worked night and day. And they managed to get the loading speed down to half of what it used to be. And this was pretty amazing, but it's still not fast enough. So this needed a bit of a more creative solution. And we realized that people tend to do one of two things when they first load up Google Maps. Number one is that they just kind of stare at the map tiles for one or two or three seconds. Just to get a sense of orientation. And number two was if they're not doing that, they tend to go to the search box and just start typing. So we thought, what if we could be smarter. What if-- is this the new loading sequence or the old one. It's the new one. OK. What if we could load the map tiles first, in a static way. So they're not the normal 3D ones. These are just a quick set of map tiles that we can load immediately. This gives all those people who just want to look at the map something to do much, much quicker. And what if we could enable the search box, so that people can type into that. Now, in a much, much quicker amount of time, we're showing the map and we're letting people type into the search box. And by the time they're done doing that stuff, the rest of the map is loaded. So this is a sign that real speed is very, very important. But the perceived speed can be very important as well. The number of people who are dissatisfied with the speed went down dramatically after we did this change. There's a second example too. And this is what happens when you click on a place, and then we load this new map that's built for this place with the new roads. And there's actually quite a few things going on here that you'll notice. So the first thing is that when we click, we have to wait for 200 milliseconds to differentiate between if this is a click, which is to select something, or a double click to zoom in. And there's nothing, really, you can do about this. But if you just wait, it will feel slow. So what we do is we immediately do a little ripple event that responds to the first click. And after that 200 milliseconds time out, that's when we begin to lift the pen up in the air. So this now feels immediately much more responsive. The second thing that happens is that the pin jumps up into the air and then lands. And as it lands, the map responds and updates. And this is done because as soon as we know that there's been a click, we have to go back to the server, figure out what all these roads are that we need to highlight, come back again to the client, and then re-render these new map tiles. And had we waited to do that, before showing the pin, that would feel laggy. But lad we shown the pin immediately, and then the map tiles had updated sometime later, that would also feel laggy. So this solution lets us begin the animation. Everyone's watching that, they're distracted, and then it lands. And then the map tiles update. And this not only hides the loading, but it also adds personality and character to the map. So we managed to kill two birds with one stone here. Annette's going to give you some more examples around Street View. ANNETTE LEONG: Imagery was one of the major features in the redesign. We wanted to make discovering images much more easier. In the old maps, there was this to little yellow guy that we called Pegman, where you have to click the Pegman and jerk him to the map, in order to see Street View. And some people did not discover that. So in the redesign, we wanted to put the images up front. So we replaced the Pegman with a sequence of images at the bottom. We tested this design in our internal dogfood. We were rather surprised that one of the comments we got was that, where did you put Street View. So in this design, we thought that we had a clean and organized way to organize everything. Information is at the top, and the images are at the bottom. But that wasn't what users saw. When the users saw the information at the top, they were questioning where was Street View. And they saw the images at the bottom, and they questioned what those were. In order to match the user's mental model better, we changed our design. We grouped the information and images together in one place. And users can still see images about the neighborhood by opening the imagery cursor at the bottom. Finally, people are able to get into Street View more intuitively. Problem solved. But there was another problem. In our usability study, we noticed that once people got into Street View they actually did not move around much. They actually were missing out on all the fun. What a shame. How could we fix it? So we looked again, we looked into our old UI. There was this circular highlight that followed the cursor, supposed to indicate that you could click and move. But some people did not get that. We tried a bunch of designs, and finally we made two small but important changes. One, we changed the cursor from an arrow to a hand with a pointing finger. Now people understand that they can click to proceed. Secondly, we added an arrow inside the circle highlight. Now people understand that when they click they will also moved toward that direction. This all leads to some really great news. Our Street View usage was up three times, according to our metrics. In the meantime, something strange was happening. People were still asking to bring back Pegman. We were wondering why. Our Street View usage was up three times. Why are people still asking to bring Pegman? So we looked into it further. Turned out there's a group of users like Anita, who thinks of a place first. So she would search and see Street View, she is happy. This explains why the new design was successful to help Anita to discover images much easier. Which also explains why our usage was up three times. There's another group of users like Susannah, who thinks of Street View first. So she did not search. And she's not seeing any images. Nor the Pegman like in the old maps. She is stuck. So we decided to bring Pegman back. And now Pegman is happier, because he's living closer to the imagery carousel. And our users like Anita and Susannah are happier too. Sometimes when you design a product, it may not be matching how your users use your product. You may have to listen carefully and observe carefully, in order to improve your design further. Finally, it's really important to close the feedback loop. During our preview period, we received tons of feedback from our users. As soon as we fixed an issue that users requested or suggested, we wrote an email to thank them and let them know that their issues have been fixed. And people love this. 98% of our users who received our email would like to continue to receive communication like this. It really showed that to your users that you listened, that you care, and that they have been heard. JONAH JONES: OK. So back to the original question. How can you design your apps for a billion people? You think big, you question everything, and you listen to your users. Thank you very much. [APPLAUSE] ANNETTE LEONG: Thank you. JONAH JONES: And we've got 17 minutes left for questions. So if you've got any questions, there's a couple of mics there. And we'll be very happy to answer them. AUDIENCE: Hello. Thank you for the talk. And also thank you for redesigning Google Maps. I think it's fantastic. I had exactly the Pegman issue when Google Maps was resigned. As a UX guy, I was like, it felt like a real misstep for the design. And when I eventually found him down in the bottom corner there, I was a little bit confused as to why you guys moved like from a purely UI design perspective. Why he's down there with the settings and also the tour. But there are also some options at the top right and you can also do stuff in the top left corner. And there's also Street View in the bottom left corner as well. It just seemed to me to not follow a hierarchy, or like a functional hierarchy. So can you talk a bit about that? JONAH JONES: Sure. I mean the original thinking behind taking away Pegman actually was if you're going to redesign a product like Google Maps, there's like thousands of features. And we had to be really, really bold. And we wanted to see how much we could take away and get away with. And like 90% of the stuff we took away, we got away with, which is good. So you managed to simplify, but we always knew there was going to be somethings that we had to bring back. And the Pegman was one of them. And it was because of these two mental models that people had. A bit of insight is that conceptually we'd always thought of Pegman as the deepest zoom of Google Maps. And there used to be this behavior that you'd zoom in, zoom in, zoom in, zoom in, and then suddenly you'd hit Street View. And that was why Pegman used to be on top of the zoom slider over there. But we would constantly see people zooming in and then accidentally getting into Street View, and like-- and then coming back out again. So it turns out that it didn't really make sense, conceptually, to our users to have it that way. And that's why when we brought the Pegman back, we brought him back in the imagery area down on the bottom right. Because that's where you summon all of the other imagery. If you pull that up, that's where the Street Views live, that's where the panorama photos live and everything else. So it felt like that was Pegman's natural home, even though it was a different place than where he'd originally been living. So that's why we put him there. AUDIENCE: Hi. When do you make the decision to do such a large redesign? I mean for applications with so many users and things like that, at what point do you stop saying, oh we should do that. And say all right, we're starting now. JONAH JONES: We'd kind of reached- I alluded to this at the beginning, but we kind of reached the stage where most people kind of felt like they were happy with Google Maps. And that was fine. But we realized that first of all, there was a big opportunity cost. Because it wasn't doing all these things we wanted it to do. But second of all, it was kind of running out of space, adding all these new features. And we were adding features. And all the discussions were always around discoverability, because everyone wants their feature to be big and bold. But it means all the other ones can't be discovered. And so we were basically running out of space to fit new features. So we wanted to rethink it and simplify it and also build a frameworks to let us add more and more new stuff in a contextual way. So it was kind of like 50% necessity, just looking into the future of where we were going. And 50% that we wanted to try something new. And as we mentioned before, just kind of redefine expectations of what Maps would be, rather than just keep plodding away and adding features to the same thing. AUDIENCE: Hi. So I notice now when you search for cities, you get a nice city border. But when you zoom in enough to figure out whether something's in one city or the other, it disappears. And so there's this frustration of zooming in enough to see what you're looking for, and then you lose your border. I wonder if you could explain the rationale for why those disappear. JONAH JONES: We actually have quite a lot of heated arguments about this internally as well. Because it turns out that when people are searching for a city or anything, like a neighborhood or a zip code or any of this stuff, you might want different things. Like some people are really interested in the exact border of the city. In which case maybe we should really highlight that, get rid of everything else. Just show all these stats about the city and everything. But then some other people, maybe they just want to send to the viewport there. Then in that case, you don't want to draw too much visual attention to it. And you want to show the context too. So we try to achieve a balance between highlighting the thing that you've searched for, but not in such a way that it's at the detriment of anything else. So it's just about trying to balance what everybody wants. And you'll probably see this has changed in the past, you'll probably see it change again, as we're trying to tweak this to best answer all of our users needs. AUDIENCE: Hi. I'm wondering if you have plans to include the embed code somewhere in the new UI? Because I can't find it. And I always have to switch back to Classic Maps to get it. JONAH JONES: I believe the embed code is down in the-- ANNETTE LEONG: Yeah, so it is actually in the Gear menu. It's not the most intuitive way at all. We're still looking into finding a better place for that. If you click into the Gear menu, you should be able to see share and embed map. AUDIENCE: Thank you. AUDIENCE: Hi. I have a question about 3D buildings and mapping and the 3D new imagery system. You've just abrogated it last year. And just-- there were users who were able to build and upload by those [INAUDIBLE] using SketchUp, using Building Maker. And it seems maybe two or three months ago, they were not able to just upload everything, because it was canceled. And there were more than 10,000 modelers. They had made millions of buildings since you started. And why did you decide to cancel this project, and what's the main reason? JONAH JONES: So I'm probably not the best person to talk about this. But I can give you like a more of a design perspective. My understanding on this basically is that we try to kind of automatically generate a lot of the 3D buildings we have as we've been flying over cities and stuff and building them up. And we do have some amount of buildings that have been specifically hand-modeled. But I'm not 100% sure on the exact policies of what gets included and what not. So if you follow out with me afterwards, we can follow up with [INAUDIBLE]. And he'll be able to answer those questions. So come and chat to us afterwards and I'll give you more detail. Thanks. AUDIENCE: Hi. I was just curious. To what degree was the redesign informed by the needs of low-end mobile users versus desktop users? JONAH JONES: So that's a really interesting question. So the vision of the future of Google Maps that we talked about was very, very platform agnostic. It was about this thing that's personalized to you. It's showing the data that you care about. It can dynamically change for every single place. And we wanted to achieve this on all platforms. And what you saw was that I guess the first hint of that was with the new iOS app that we built with the new design language. And then a lot of the new functionality and concepts came into the desktop version. And now they're starting to find their way back into the mobile version as well. So all of the platforms are kind of-- they're almost like in a race. Some are readier earlier than others. But we're all heading toward this unified future. And low-end devices are going to be very much an important part of that as well. It's not something that we've been focusing heavily on to begin with, but definitely we're going to be focusing very much on speed and devices with low connectivity and low CPU and that kind of thing. It's really important to get those things working, especially with the Android 1 phones coming out and everything. Actually, I haven't tried one of those yet, but I'm really curious to see how it works. AUDIENCE: More generally, about the process. When you do decide to do a redesign, the three lessons are sort of like three steps. Is there a particular order that you guys followed? Did you listen to users first, or did you try to think big on your own? Or is it all at the same time? JONAH JONES: It's kind of all at the same time, actually. Because the benefit we had of working on this product for seven years, is that we've run repeated usability studies. We're getting feedback all the time. So we know what our users' pain points are. And we know what areas of the products are being underutilized. So we knew, for example, that we had all this great imagery, and people weren't finding it. So some of them are explicit issues. And other things are just opportunity areas. So we kind of just have this idea of oh man, this could be so much better. So that was just informing things. And then obviously, if you want to change something and do something audacious, you've got to question everything. You've got to think big. It's all kind of part and parcel. It's not really a step one, two, three thing. ANNETTE LEONG: Similarly, like when you build a product, you want to focus on a few key use cases. And then constantly, you're looking back at what you designed to see if you are matching those use cases. And each time you are not, then you go back to the sketching board, or talk to the researchers how we can improve the products further. AUDIENCE: Hi. I was hoping you could share a little more about how you conduct the user research. Both before, during, and after this process for around the world. It seems like a pretty difficult problem. I'm wondering what the main steps were. JONAH JONES: I wish we had a researcher with us to talk about this. But we basically run a variety of different research studies. We can do super small scale stuff, even within the company, where you just go into a cafe, and you get someone to click on stuff. We can bring people in and have them test things out. We can go to people's homes and see how they use things in the real life. There's diary studies, where you can get people to document the things that they need every day, and what they're using. And that can be across different products. Obviously, there's the feedback that you get from users when you get to send feedback from within the product. You can look at the metrics. You can see what's getting clicked and what isn't. So we kind of used like a dozen or so different ways of getting this, because they're all flawed in their own different ways, so you're trying to get around it. AUDIENCE: And is it something that if you look at that data and say it's not really making sense for a particular region of the world. You'll go out there and really attentively study that. JONAH JONES: You can certainly notice that there are regional differences in how people use things, the kind of things that they search for, the kind of things that they need. And of course the data is very different as well. The data in the Bay Area is great. You go somewhere else, maybe the data is a lot lower quality. So things vary a lot. It's really interesting. ANNETTE LEONG: And sometimes when you design a feature, you may need multiple rounds of research and usability testing for that. And then we had a long period of time with internal dogfood, where we collected a lot of feedback from internal users. So we actually during that round we made the feedback button super prominent. And people wherever they use and run into any problem, they can just click there and that would allow them to easily file a request or bug. JONAH JONES: It's also worth pointing out that we're a very diverse team. Like you can hear that neither of us are American here. We have teams all over the world. And so I think that actually helps in bringing a very global perspective in building a product like this. That we're not all just focused on one place. We've got people from different point of views. That helps too. AUDIENCE: That was my additional question. Sorry for interrupting. But I wanted to know how localized the maps are. And how different they are in Asian countries, or let's say in the Middle East. JONAH JONES: So we try and achieve a balance between localization where it makes sense, because we want people to feel familiar. But we also want Google Maps to be a consistent experience, so that you recognize it as you travel around. So you'll see some elements of the design, like we have localized public transit icons, for example. But the things like-- what else was a good example-- things like restaurant icons or something like that are kind of the same everywhere. So we try and achieve a balance of localization where it makes sense to be different. But otherwise we try and have a consistent style so that everyone can predict how to use the product. ANNETTE LEONG: And in terms of the UI, we also created the framework that supports multiple languages. Like some language like you have to read from right to left. So we had to make sure that the framework could allow a format like that. AUDIENCE: I was wondering if you could talk more about the differences between the mobile app versus the web UI, which you were showcasing more in this talk. In particular, I run a UX design agency in our office. We were talking about how much we really enjoy the updates in the web app. And in the mobile UI, we kept getting lost in how you even start a navigation session. And it looked like something's transferred well, and other things didn't. And maybe somethings you're working on. So I was just wondering if you could shed more light on that. JONAH JONES: I would characterize that as saying that we have this vision of the future. And then the mobile and the desktop versions were being developed concurrently. And so they're almost like slightly different interpretations of that same future. So the teams are sitting right next to each other. So the desktop team were borrowing ideas from the mobile team and vice versa. So it's mostly the same. There are some things that are deliberately different. There are a few things that are kind of unintentionally different, that we want to fix. But I think gradually you're going to see these things converging increasingly. And especially with the new material design staff. We really want to have an experience where it's very, very consistent as you go from desktop to tablet to mobile to watch to Glass, whatever. AUDIENCE: So for new features like highlighting roads next to points of interest, are there any plans to make those accessible via the API or any of the new features that you guys talked about today? JONAH JONES: That's a really good question. They do show up on the API embed. Follow up with us afterwards. We've got the API guy here so we can find out more about that. I believe that's everything. So thanks everyone for your time. ANNETTE LEONG: Thank you. [APPLAUSE]
A2 map jonah annette street view jones design Google I/O 2014 - Redesigning Google Maps 151 17 Hhart Budha posted on 2014/06/16 More Share Save Report Video vocabulary