Making maps
that don’t suck
People scan maps, they don’t read them.
What’s your map’s story?
Make sure every feature on the map relates to your map story. Have you done the squint test? (When you squint at the map what is the information that stands out, primarily)? Are those prominent features the most important features to complete the story? An 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 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’?
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. It seems obvious, but it’s commonly forgotten. 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 their 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.
I’m always interested to discuss this with anyone who has an interest in map design.
*Image header: Map tiles by Stamen Design, under CC BY 3.0. Data by OpenStreetMap, under CC BY SA.