Skip to main content
Prototype map component notes

Using maps in government services

This is preliminary guidance.

It is for service teams designing, building or procuring services that use maps.

Use this guidance to help you:

  • decide if you should use a map
  • design maps so they are usable and as accessible as possible
  • provide alternatives so all users can complete their task

Understand your users

Before deciding to use a map, you must research your users.

You need to understand:

  • their digital skills and geospatial literacy
  • how they currently complete their task
  • whether they already use maps, and how
  • the problems they experience when using maps

Do not assume users understand maps. Geospatial literacy is a specialist skill and is often low.

Maps and accessibility

Maps are often inaccessible to many users.

You must:

  • assume some users cannot use a map at all
  • provide an alternative way to complete the task
  • make the map as simple and accessible as possible
The alternative must allow users to complete the same task and be available alongside the map.

When to use a map

Only use a map if there is a clear user need.

  • there is no simpler way for users to complete the task
  • it improves understanding of location or space
  • it is an enhancement, not the only way to complete the task

When not to use a map

  • as the default starting point for a task
  • when a postcode, address or list would work
  • if it adds complexity without clear benefit
  • if users can complete the task more easily another way

Designing services that include maps

Provide alternatives

You must always provide a non-map way to complete the task.

  • search by postcode or address
  • select from a list
  • filter results step by step
  • enter or view coordinates in text form

Make maps simple

  • show only the features users need
  • remove unnecessary controls
  • avoid overloading the map

Structure the page appropriately

  • show text-based information before the map
  • place search and filters before the map
  • do not make the map the first element unless essential

Support different ways of interacting

Users must be able to interact without relying on a mouse, touch or vision.

  • provide full keyboard support
  • use logical tab order
  • ensure visible focus states
  • label all controls clearly

Use clear, accessible content

  • use text labels instead of icons
  • do not put text in images
  • describe map features in text

Use colour accessibly

  • do not rely on colour alone
  • use high contrast colours
  • use patterns or hatching where needed

Use appropriate technology

  • prefer vector maps over static images
  • minimise reliance on JavaScript
  • provide a fallback where possible

Common user needs for maps

Identifying a place

Users may confirm an address, recognise a place visually or identify land without a formal address.

Selecting a place

Users may select a location to view information or take an action.

Defining an area

Users may draw or define boundaries.

Comparing places

Users may compare multiple locations.

Understanding features and boundaries

Users may need to identify features or understand boundaries and responsibilities.

Choosing a map provider

  • accessibility
  • usability
  • customisation options
  • keyboard support
  • performance

Testing maps

You must test:

  • the map interface
  • the non-map alternative

Include users with low digital skills and those using assistive technology.

Improving map accessibility

  • convert geographic data into text
  • use step-by-step filtering instead of map interaction
  • provide structured data formats such as GeoJSON

Help improve this guidance

This is an early version of this guidance. We need examples, research and feedback.

Email: hmlr-design-system-support@landregistry.gov.uk