Maps in public services

About maps in public services 

Maps can be used in services to show: 

• the location of something (navigational or location map) 
• data that has a geographical element, such as population or pollution levels (data visualisation or thematic map) 

Online maps can be interactive or static.  

You can create maps from scratch or use:

• specialist software
• online tools
• commercial map plug-ins

Types of maps for data visualisation 

Types of data visualisation maps include:  

• dot density  
• proportional symbols  
• choropleth  
• heatmap  
• equal area cartograms 

Find out more about the types of data visualisation maps on the Ordnance Survey website.  

Be cautious about using maps  

If they’re designed well, maps can bring data to life. They can show geographical trends and patterns.  

However, you should not assume that you need a map if your service has information with a geographical element.  

Be cautious about using maps in a service or publication because: 

• they can be inaccessible, for example for users with visual or motor impairments  
• it can be difficult for users to interpret them 
• they can take more time and resources to design and maintain than other types of content 

There are often more accessible ways for users to complete tasks or get the information they need. For example, postcode checkers or written content. 

You should only consider a map if you’ve got: 

• evidence that users need a map – a discovery phase will help you find this out 
• evidence that adding it to the service would benefit some users and not hinder others 
• another way for users to complete the task or use the service – the map should not be the only way to do this
• geographic data that's trustworthy and properly licenced

Discovery  

Use a discovery phase to understand who your users are and what they need from your service. This is so that you build the right thing to meet those needs.   

In discovery you should define the problem. This will help you to find all potential solutions. A map may be one solution, but it may not be the simplest or most accessible for users. 

For example, users can find out their voting constituencies using Boundaries Scotland’s postcode search. This is quicker and simpler than checking multiple maps. It’s also easier to update this content if boundaries change.  

Discovery questions about maps

To understand if a map is the right thing to build, you should also find out: 

• how other services have met similar user needs – particularly if they’ve used content other than maps 
• your users' ability to interpret spatial data 
• what devices they use and mobile data issues – these might impact using a map 
• what data you have and what’s missing 
• how often the content will need to be updated  
• what resources you do or do not have – such as people with map design expertise, software licences and data licences
• what functionality users would need in a map to complete a task

At the end of discovery, you should understand the problem and have an idea of how to meet user needs.  

Find out more about how to do discovery in the Scottish Government Service Manual and how the discovery phase works in the GOV.UK service manual. 

Provide another way for users to complete tasks 

It's difficult to ensure maps are fully accessible. It can be a barrier for some users if a map is the only way for them to complete a task or use your service.  

Give users another way to complete the task or use the service (alternative content), such as: 

• plain English written content  
• ‘checker’ tools – for example eligibility checkers or postcode lookups 
• graphs and charts (although these can also be inaccessible) 
• the full address of a building
• coordinates of a location (if users are familiar with navigation)
• accessible tables 

Public sector bodies have a legal duty to give “essential information...in an accessible digital manner for maps intended for navigational use” (Accessibility Regulations, regulation 4(2)(d)). 

For example, give a postal address and nearby public transport stops as an alternative to a map to a public building (EU Web Accessibility Directive: frequently asked questions). 

Test the simplest solution first 

It’s best to prototype and test the simplest and most accessible solution first (a ‘minimum viable product’).  

This prevents your team from wasting time and resources.  

For example, if you find that plain English written content meets user needs, it may not be necessary to also include a map in your service.   

You can prototype and test solutions with users during an alpha phase. You should think about testing with users with accessibility needs as part of your alpha.  

Find out more about how to do an alpha phase in the Scottish Government Service Manual and more about how alpha works in the GOV.UK Service Manual.