Rule 1: Think like your audience
When you’re working with digital mapping and GIS every day it’s easy to assume that everyone understands what a map “is” and what your map represents. The OpusMap team once worked with a company who provided a map printing service and were trying to encourage customers to order over the web using a text-based form. However, time and again customers were unable to complete the form because even though it provided simple drop down menus for choosing scale and paper size, the vast majority of buyers were unable to visualise how a 1:10,000 scale map printed at A1 would differ from a 1:5,000 scale map printed at A1 and so on.
Usability testing – i.e. understanding maps the way users understand them – is an important component in building a website and it’s applicable to how you design your web map and how you identify the way users will engage with your web map. When it comes to usability testing of web maps you are not your user no matter how much you may know about GIS, cartography or using maps and data in your day-to-day work.
Rule 2: Keep it simple, stupid
A GIS is a very powerful piece of software. It has many useful functions and tools to help users interact with, interpret and analyse maps and data. It’s easy to assume that replicating these functions and tools online with your web map will keep the user happy.
Most web maps are telling a specific story. This might be “where the best cycle routes are for cyclists of different abilities” or “where Local Plan policies will be developed in the next 10 years”. Features and tools should only be used if they support your web map’s story otherwise, you risk distracting or even alienating users. Something as basic as how you layer your map and style those layers can make a big difference in how easy it is to interpret your web map and know where to engage with the data shown on the map.
If the purpose of your web map is to help users make a decision. then it’s important that your web map’s usability supports that decision-making process. More choices and features do not necessarily result in higher satisfaction and a frustrated user is unlikely to make a decision at all, let alone the right decision.
Rule 3: The need for speed
Web maps are generated from a server to your browser. Each time a user makes a change – for example to the viewing scale of the map, or to the number of layers shown on the map, or to where the map is centred – the server has to undertake a process before the user sees the change in their web browser.
If you want your map to support making these user changes quickly you need to make sure that both the server and the user’s web browser are able to make full use of caching. Caching essentially means that the server and the user’s web browser are able to store and make use of the same processes (i.e. changes) applied to your web map rather than have to start from scratch.
However, there are choices you can also make in the way your web map is designed and built to improve speed:
- Keep the base map simple
- Keep the number of layers to a minimum
- Aggregate layers into one layer – e.g. show roads as one layer rather than having a separate layer for A roads, B roads etc.
- Keep styles simple
Rule 4: Users don’t care what software you use
A few year’s ago Google asked people on the street “What’s a browser?” Of the 50 people interviewed only 4 knew what a browser was. Ultimately users only care that your web map works with their technology, with their hardware and with their software and they don’t really care why or how it works!
It’s easy to get hung up on technology and software when deciding how to design and publish your web map. It’s easy to assume that the GIS you use to interact with maps on your desktop at work is just as good for interacting with maps over the web. It doesn’t matter how good your web map is or how brilliant the software is that generates the web map in the first place if a user has to make any kind of change to their hardware or software to be able to use your web map.
Rule 5: Be consistent
There are many different ways to publish a map online, from a static image through to a fully interactive map. It’s important that the first web map you publish or the first version of your web map is consistent with subsequent web maps or versions of a web map. Users don’t like having to interact with different types of web maps across a website, particularly if what is shown on the map is subject to change.
The user interface (UI) of your web map and the position of features in the UI – e.g. the legend, search box, interactive tools – should be consistent from Day 1. Whether people use your web map daily, weekly or once in a blue moon, they will expect their experience of any web map you publish to be consistent even if the content or map story changes.
It’s tempting sometimes to just put something out “that makes do” either as a stop-gap or because there is a perception that the project stage or map stage is less important than a previous or later version. This is a mistake.
There is a saying in business: you’re only as good as your last job or project. The same mantra should be adopted for web mapping.