Saying more with less: how designing maps helps you understand use cases
Map design is a master class in understanding how users seek information
"Maps will sell our product to customers, even if they don't use it often." My product manager said, sparking a month-long deep dive into learning how to design maps.
Maps are an odd design case since you won't be designing much of the page. Instead, Engineers will likely call an API like OpenStreetMap or Google Maps to populate the page.
Instead, we design certain UI elements that will be on the map.
While this might seem easy at first, what I found working with maps is that it requires you to understand nuances about your user to ensure you design something worth caring about.
Map layers matter: in fact, it's often the most important decision
One of the most important things to consider is something that you won't design at all: the map layer.
After all, maps are a type of information visualization, meaning there are several ways to show this. For example, consider these two layers, which are available in OpenStreetMap (one of the main mapping libraries).
The first is the standard map, which is similar to what you might see on Google Maps.
The second, on the other hand, is a specialty layer called the transport map, which de-emphasizes a lot of detail.
If you choose the latter layer, for example, it makes the design elements much easier to see, as everything is de-emphasized for clarity. However, doing so would make it much harder to highlight certain buildings, restaurants, and more since those have been de-emphasized.
You might wonder why you should do things differently than Google Maps, which dominates this space. The answer is that your use case may differ from theirs.
Why you might not want to emulate Google Maps
There's no denying it: looking into this space, Google Maps tends to dominate this space (with OpenStreetMap being the nearest competitor).
However, it's essential to identify your use case because it might differ from Google Maps.
Google Maps and its design decisions are all based on a primary use case: transportation. In other words, I want to select a spot on the map and figure out how to (most likely) drive there, with some alternatives for bus, bike, and walking.
The map layers Google provides are almost entirely about transportation.
Their primary user might say, "I want to go to this restaurant," or "I'm lost, and I need to find X." Most of these people are likely accessing Google Maps on mobile devices in the car.
This is why the map layers, design elements, and more about navigation and transportation. Given how many people drive daily, it's no surprise they chose this widespread use case.
However, my use case was different: it was about troubleshooting. To help my users troubleshoot, I needed to show if a server was down or where alerts came from. I didn't need to show them how to get there; the next steps would likely be calling that specific office.
As a result, this affected the map layers I chose and many of the UI elements. I'm not a weird isolated case, either. Some other widespread use cases might include:
Showing high/low activity in a particular region (Choropleth maps)
Showing regions affected by something (I.e. outages)
Showing performance across certain states (Sales Numbers)
etc.
Identifying the primary use case will play a large part in the layers and how you design the rest of the system.
The other thing you need to remember is how users seek information.
Information-seeking behavior and how to design around it.
Imagine you were looking for a specific restaurant (Panera Bread), and when you searched for it, you were given a list of 20+ results. How many users would scroll down the entire list, and how many would take a moment to refine the search?
Most users tend to fall into the latter category: they are not necessarily going to browse through the entire map or drag things around; instead, they'll repeat the search, refining signs, until they only get a few results.
This user behavior matches the information-seeking behavior concept that Ben Shneiderman proposed. It consists of three parts:
Overview
Zoom & Filter
Details on Demand
This model is nearly a 1:1 match with how users use a map, which often means that you need to provide enough clues to help users find information.
Overview
At this stage, users are unlikely to use the left-hand drawer to find what they want. Instead, they are likely to do one of two things:
Zoom in to a particular area if they know the rough location where it is (i.e., "somewhere near the center")
Refine their search to include a location like "Panera Bread DC."
If the user has enough context clues (such as a series of overlapping points in the center), then they may move on to the next stage of Zoom In and Filter.
Zoom in & Filter
Assuming that we cleared the first bar of the Overview, we move to Zoom In on a particular location and see if this new map level helps. At this stage, it can be challenging to see these locations amidst many other points of interest (which is why the map layers often matter), but we can still see if this Zooming In helps.
For example, does this Panera bread match the description of what your friend gave you ("In the Macarthur shopping center")?
Details on demand
At this level, assuming that you found the right location, you can get several essential details (such as when it opens and how to get there).
To once again emphasize the "Transportation" use case, Google Maps' primary action is a blue button called Directions.
Remember that the user may decide to start over at any point in the process. Perhaps they don't like what they see and choose Chipotle instead. Or none of these results are what their friend described, leading them to look elsewhere.
However, creating a map users will use requires focusing on how they seek information. This often requires considering one additional point: Zooming In and Out considerations.
Understanding Maps requires thinking about Zoom In and Out.
We didn't see it in the Google Maps case (which led to some friction), but we may want to showcase different map views, UI elements, and more at certain Zoom levels to support our users' information-seeking behavior.
For example, in my troubleshooting use case, what happens if an entire region goes down? In the zoomed-in view, it might make sense to showcase multiple pins at different levels.
However, what happens when we Zoom out? Does it make sense to have hundreds of points clustered in an area? Perhaps not. Instead, we might showcase a different view.
Remember, the main point of the map is to guide the user through the information-seeking process. If we need to change how something appears, that can often be okay.
Websites like Zillow take this approach, showing 'random' price points and locations at different Zoom levels to pique your interest in Zooming in.
Making sense of maps, in this fashion, allows you to design something that users will often use.
Maps are often a particular design scenario that gets ignored
Designing around Geography and maps can be tricky. On one hand, you might not be able to make much of a difference, given you're only designing parts of the page.
However, Designing maps often requires a strong understanding of your user, the typical use case, and how users seek information. While you may only design part of the page, the care you put into each UI element that properly represents your use case can help users find the necessary information.
So, if you design a map, take special care to understand your users and what they're searching for. After all, it can be one of the most persuasive types of designs, even if you don't expect it.
I've revamped my Maven course to teach Data Informed UX Design. If you want to learn this valuable skill, consider joining the waitlist.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.