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]