People scan maps, they don’t read them.
When I started working in maps, I was surprised and disappointed how little information was shared about what makes a good map. I wanted to learn and improve this space, so set about my research and here are some learnings.
Keep it simple.
Maps can be perceived in the same way as graphs — people shy away being overwhelmed by their complexity of information. People don’t want to spend time reading and understanding a detailed map.
Just give the user the information they need, when they need it.
Firstly, maps are layers of data. You can choose what data you show when and get a whole lot of that information through a user’s device. Learn about the user’s journey, their context and what they want to achieve by using the map. From this we should define the map’s story. Everything on the map should be directly relevant to the map’s story.
But what’s a map story?
Think back to when you last hand drew a map on a napkin for a friend, ‘How to get to the 4 euro bike shop in Berlin’ — you sketch only the important streets and notable surroundings. Consider this as that map’s story. This info is the most important information.
Transferring this to a digital platform you want to highlight this information using ‘design hierarchies’. Meaning, you would highlight the main route to the bike shop, highlight the final destination and perhaps a corner where the user needs to turn. The better you understand the user’s context, the more you can guide the user throughout the journey and keep the map simple. Other map information such as surrounding streets, provide additional context but is secondary level of design hierarchy.
Make sure every feature highlighted on the map relates to your map story. Have you done the squint test? (When you squint at the map, the information that stands out should all be relevant to explaining your map story). I learnt about the squint test from this interesting talk from the Google map developers at Google IO.
Your user’s journey
What are the users goals when using the map. Consider the user’s context; where they are, what they’ve been doing before and what they will do next, after using the map. What data do we already know or can we access, to predict what will be useful to them next?
Is the data represented accurately in the map?
Understand what the meaning of each data source is and make sure that is communicated accurately on the map. Test the language you use with users to ensure you are conveying the right message. Example: Does ‘Gaming’ statistics mean, ‘Pokie machines’ or ‘Video games’? It seems obvious, but it’s surprising how often these can be misinterpreted.
Is the legend adding clarity or clutter to the design?
Challenge the need for a legend, always. If the map data is simple, start the design on the basis you will not use a legend. Include a legend if you can’t design it in a way to support discoverability. (This isn’t a design failure to include a legend, but it’s a good mindset to get started trying to keep the map design and symbology as minimal and simple as possible). If we understand a user’s story, we know the common scenarios or goals a user wants to achieve using the map. If you can present relevant information to the user, when it’s most useful, or make it sensibly discoverable, it simplifies the experience for the user.
Share your current map snapshot.
A user should always be able to share the map with their selections embedded in the sharable link. A useful library, https://github.com/mlevans/leaflet-hash
Maps can take time to load. Offer useful things to the user.
A site shouldn’t show any animations on the map until all map tiles have loaded. Typically, a user doesn’t feel safe to interact with a site if it’s still loading and you want the user to feel confident in knowing their action will have an expected response. Google maps did this well, by allowing a user to start their search (a layer on top of the map tiles) before the map loaded so it took the user’s attention away from the slowly loading tiles.
Users should be able to scroll the website without zooming the map in and out.
When a user scrolls down a website with an embedded map, it shouldn’t affect the zoom level of the embedded map. It is an unexpected behaviour for a user and it is difficult for them to re-centre the map or know what was being highlighted prior to the accidental zoom.
Double click to zoom.
Double clicking should zoom the map into that point. We have learnt this from Google maps and this is familiar and expected practice for a user.
Is colour cluttering the map?
Count the number of different colours on your map. Colour can also be visual clutter. Here is an excellent article on how the design was critiqued between Apple & Google’s map designers. An interesting read to consider the different approaches to their design thinking process.
People scan maps for answers to their immediate needs. They don’t read them. Keep it simple.
Let’s keep mapping beautiful.
If you found this interesting or have some new ideas too contribute — I’m always interested to discuss this with anyone who has an interest in map design.