Rebuilding Google Maps
In 2006, I was 1 of 2 designers on Google Maps.
At the time, Maps wasn’t the top mapping application, but it was growing like wildfire. We were adding tons of features and it was becoming a cluttered mess.
We knew the UI could only handle so much feature growth. But we wanted to expand the product in many different directions. So we were faced with tearing apart and redesigning everything we had.
Here’s the full story:
Maps before ‘Maps
Until the late 90s and early 2000s, people used paper maps to navigate. They carried maps and road atlases in their cars to figure out where they were going and where they were. For longer road trips, people often went into AAA offices to get help planning routes.
So the debut of online mapping in the late 90s was huge. By the early 2000s, online mapping began to take off with MapQuest dominating the market. Suddenly anyone could go online, enter a starting and destination address, and print out turn by turn directions for anywhere in the United States. MapQuest became synonymous with online mapping.
But in 2005, Google Maps launched with a far better user experience. The product was the brainchild of Lars and Jens Rasmussen and leveraged a new web technology (AJAX). With Google Maps, people could:
Interact with the map directly — Users could click and drag the map to pan and zoom. Previously people had to use separate +/- and directional arrow buttons to change the map.
See the map faster — Google Maps preloaded the surrounding map tiles (in X,Y,Z axes). Before this, people had to wait for the map to load after clicking left/right/zoom buttons.
Search more intuitively — People could search for local businesses, airports, etc. without having to know the specific address. Other online maps required address, city, and state to find an address.
Working With A Limited UI
Despite these big leaps in the user experience, the interface for Google Maps was fundamentally stunted. The UI was based on the underlying technical structure of the product. For any search query, Google Maps referenced one of three databases:
Maps data
Local business data
Directions data
So not surprisingly, Google Maps had three tabs: Maps, Local Search, and Directions. There was one tab for each database and each of these tabs had different input fields.
The UI did its job well enough. By 2006-7, Google Maps had hit product-market-fit, its user base was growing rapidly, and it was on its way to catching up with MapQuest’s usage numbers.
I joined the team at this time. We were rapidly adding new content and features like:
Satellite and Terrain views
Street View, 3D buildings, Traffic
Editable map data, Reviews, Photos
Transit Data
Personalized Maps
The original UI didn’t allow for a lot of feature expansion. We tried a bunch of different ways to rearrange the Maps UI to accommodate all of these new elements. Below are a few of the explorations:
But really, we were out of pixels. We were wedging all of these new features into any space we could find in the UI.
It became clear the user experience was suffering and the product was growing increasingly complicated. Our VP at that time, Marissa Mayer, likened the Google Maps interface to a Christmas tree that we kept adding more and more ornaments to until it started to fall over.
The Only Way Forwards Is Backwards
Eventually we had to step back and rethink Google Maps based on what we knew was working, what brought people to the product, and what we believed the future might look like.
These were the 4 key steps we took to simplify the design of Google Maps into the underlying structure that still exists today:
Deconstruct — extract and inventory all the features and content of the product
Reframe — group and relate these to each other in different ways
Reconstruct — explore different ways to combine and relate features to each other
Scale for the future — consider future states and capability to support exponential growth.
Let’s dive into each of these in more depth:
1. Deconstruct
We essentially deconstructed the product into all of its parts and pieces.
We wanted to look at all of the different elements of Google Maps with fresh eyes.
So we methodically went through the product and inventoried all of the product’s current and upcoming content, features, and functionality.
We wrote these down on post-it notes, played with different ways to cluster them, and ended up loosely grouping them into the following categories:
Core features — The most common tasks people came to do (search, get directions, find businesses)
Aspirational use cases — Tasks we wanted people to start doing (adding their own content, correcting inaccurate information, using Maps to explore new places, etc.)
Global actions — Actions that impacted the entire page (print, share, save, etc.)
Use case specific actions — Actions that were relevant only within a specific use case (e.g. while getting directions, being able to drag a route or add a destination)
Related features — Things that weren’t a part of Google Maps at the time, but existed and were closely related. (e.g., transit information, business searches on Google.com)
2. Reframe
We wanted to reimagine how these elements could all relate to each other in a more intuitive way. We leveraged a combination of user research, business goals, and our own intuition to explore this.
Our focus was on understanding what brought people to the product, how people navigated through the product, what was working well, which flows were confusing, what information was valuable when, anything that was missing, and any functionality that was redundant.
We conducted baseline usability tests for Maps’ core features to understand how well each feature currently worked and to establish a benchmark for evaluating changes to these features.
We did field-based research to understand how people used Google Maps and competitive sites to understand issues and opportunities.
We also spent a lot of time going through the product ourselves, and noting friction points.
Through our explorations, we identified several key points:
Searching was the most pivotal task in Maps. Searching addresses, businesses, parks, mountains, cities, etc could all be thought of as searching for “places”
Getting directions was important. But people rarely thought of this as a route between two specific addresses. Directions searches usually had a known start or end point, like home or work. It was also more intuitive to be able to search for directions by a place name e.g., ‘Carmel Library’ rather than having to look up the address first.
User generated content was big. It was strategically important for people to be able to contribute content to Google Maps and to be able to explore the world around them.
3. Reconstruct
Based on what we learned, we then explored many different ways to reshape the product.
It was important for the product to still feel like Google Maps. But we wanted to break away from the database-driven site architecture and explore how we could more intuitively reconstruct the site.
As we began to explore, we held these usability principles in mind:
Entry points to core use cases should be prominent
Flows within core use cases should be intuitive
Common actions, interactions, and views should be consistent
Contextual actions should be accessible when relevant
These are a couple of the different framings we considered:
These explorations of different models and site maps helped us to identify the four main use cases:
Search
Get Directions
Create
Discover
They also helped us explore how we could prioritize between these use cases, handle actions that impacted the entire site vs use case specific actions, relate the search inputs, map view, and list view to each other, and support the nuances within each use case.
4. Scale For The Future
We proposed several key design changes:
There would be only one search box (this would search everything — businesses, parks, addresses, personal content, reviews, directions, etc.)
Directions would live as a secondary feature (but would be always be easily accessible)
Other features would appear in context (e.g., adding another stop within directions)
These changes made for a much cleaner UI. The single search bar at the top replaced the proliferation of tabs.
This was 2008. We knew the product would continue to evolve, the feature set would continue to expand, and the information set would grow exponentially.
But we were confident the UI framework would scale because:
It prioritized finding places and getting you there
The single search box could handle infinite data sets
New features wouldn’t be competing for the same pixels (because they appeared in context when relevant)
Despite the evolutions over the past 16 years, the single search box has persisted as the key organizing principle to Google Maps. This solution seems obvious today, but at the time we faced considerable push back on merging everything into the single search box.
Users were used to multiple input fields on other mapping services, and people in Google were concerned that users wouldn’t know how to search for directions or businesses. But through a combination of using the product ourselves, conducting small experiments, and running usability tests, we strongly believed this was much better solution. While experiments showed us that search metrics did drop initially, with educational prompts and time to adjust, the metrics recovered.
So we committed to the changes, and started rolling out the single search box UI that helped shape Google Maps into the simple, intuitive, much-loved product that 1B people use around the globe.
Where Can We Go With This?
It is natural for early product UIs to reflect the technical architecture behind the product.
But the first version of the product that ships doesn’t have to be locked in forever. It’s important to ship, learn, and iterate. Using your own product regularly, understanding how people use your product, and having a good sense of its future expansion are critical to evolving it well.
There will always be space to deconstruct what you have, reframe your existing flows and use cases into key tasks for your user, and reconstruct based on what you’ve learned and where you want to go.
As with Google Maps, stopping and taking a step back may actually be the best way to scale for the future.
I posted a shorter version of this story on X a while back and got a ton of questions, many of which I aimed to answer in this full version.
Feel free to email me with any additional questions you have. I’d love to hear from you and I’ll try to get back to every reply!