A practical guide to pin-drop map surveys

When a map beats a form

Some questions are spatial and no amount of clever wording makes them work in a form.

"Where do you feel unsafe walking at night?" produces "near the station, sort of, on the side by the car park" in a text box. On a map it produces a point, and four hundred of those points produce a pattern that no one can argue with — including the fact that the concern is concentrated at one specific unlit stretch rather than spread across a whole neighbourhood.

Reach for a map when the answer is a place: safety concerns, missing crossings, flooding, dumping, where a bus stop should go, which junction to fix first, which buildings people would keep. Do not reach for one when the answer is a preference. "Which of these three designs?" is a survey question, and putting it on a map only makes it harder to answer.

Plenty of consultations want both, which is why a campaign page can carry a survey and a map together and report them side by side.

What a pin actually is

Four pieces of data, and each one earns its place:

• A point. Latitude and longitude, stored properly as geospatial data so it can be exported to GIS rather than as two numbers in a spreadsheet.
• A category. The single most valuable field on the whole map, because it makes the data filterable and the map legible at a glance.
• A comment. Where the reasoning lives, and where your report's quotes come from.
• Optionally a photo. A picture of the broken kerb ends more debates than a paragraph about it.

Designing categories

Three to five categories. Never more.

Categories are the legend, the filter and the colour scheme all at once, and past five the map turns into confetti. Three is often perfect: something positive, something negative, something generative. "Love it, Concern, Idea" works for an astonishing range of consultations.

Rules that hold up in practice:

• Name them in the community's words, not the organisation's. "Feels unsafe" beats "Perceived personal security deficit".
• Make them mutually exclusive. If a respondent has to think about which of two categories applies, you have two versions of the same category.
• Avoid "Other". Everything lands in Other, and Other is unanalysable. If you genuinely do not know the categories, run a short idea board first and let the categories emerge.
• Do not sneak a survey into the categories. Six categories that encode demographics belong in questions, not on the map.

Setting the frame

Centre the map on the thing you are consulting about, at a zoom where the area fills the screen on a phone. If someone has to pinch and pan before they understand what they are looking at, you have lost a share of respondents before the first pin.

Set a boundary if the consultation has one. It keeps pins inside the study area and saves you explaining, later, why 30 points landed in the next county. But make the boundary generous at the edges: people who live just outside a study area are often the ones most affected by it.

Public pins or private?

Showing everyone else's pins is a real decision with real trade-offs.

Public pins create social proof. A map that already has two hundred points on it looks like something happening, and people add to things that are happening. They also let you add upvotes, which surfaces consensus quickly and cheaply.

Private pins protect against pile-ons and anchoring. If your consultation is contested — a facility siting, an encampment, anything where neighbours are already arguing — a public map can turn into a scoreboard, and the second hundred pins tell you more about the first hundred than about the neighbourhood.

A reasonable default: public pins with public comments for constructive consultations, public pins with private comments where the topic is heated, fully private where the input is sensitive. Whatever you pick, say so on the page. People write differently when they know who can read it.

The accessibility part, which is not optional

A drag-a-pin map canvas is, on its own, unusable for a keyboard-only user and close to meaningless for a screen reader. If the map is the only way to contribute, your consultation has quietly excluded a slice of your community — and if you are a public body, that is not just a design failure, it is a duty you have not met.

The fix is simple and it should ship with every map: a plain, labelled text field where someone types an address or a postal code, which is geocoded to a point and submitted exactly like a dragged pin. Same categories, same comment box, same weight in the results.

Details that matter when you implement it:

• Make it visible, not hidden behind an "accessibility options" link. Plenty of sighted mouse users prefer typing an address they already know by heart, and people on slow connections would rather not load a map canvas at all.
• Confirm the geocoded result in text before submitting, so the respondent can catch a wrong match.
• Accept a postal code or an intersection, not just a full street address. Not everyone wants to give their own address, and some concerns are not at an address.
• Keep every other WCAG 2.2 AA obligation in place around it: visible focus, 4.5:1 contrast on the category colours, real labels, targets big enough for a thumb.

Our maps ship with the address fallback switched on and it cannot be switched off. It is the single feature we are most stubborn about, because a consultation that only some people can answer is a consultation that produces the wrong answer.

Moderating a public map

A public map is a public comment box with coordinates attached, so the same rules apply, plus two extras.

First, watch for pins that identify individuals. "The house on the corner with the red door" is a moderation problem regardless of how politely it is phrased. Hide those quickly and say in your standard that you will.

Second, watch for coordinated placement. A hundred pins in one spot in ten minutes is either a genuine community response or one person with a browser and a grudge. Rate limiting by address and device catches the crude version; the queue and a human catch the rest.

Reading the results honestly

The most common analytical mistake with map data is treating pin density as need density.

Pins cluster where people live, where people walk, and where the link was shared. A cluster in the town centre may mean the town centre has the biggest problem, or it may mean the town centre has the most footfall and the most people who saw your flyer. Both are true often enough that you have to check.

Three habits that keep the analysis defensible:

• Normalise where you can. Pins per thousand residents, or per unit of footfall, tells a different and usually better story than raw counts.
• Read the categories separately. A cluster of "Love it" and a cluster of "Concern" in the same block is a live debate, not a consensus, and reporting the total would hide the most interesting finding on the map.
• Cross-reference with the survey. If your survey asked about travel mode, you can see whether the pins came from people who walk the corridor daily or from people who drive past it.

Then export it properly. GeoJSON drops straight into QGIS, ArcGIS or whatever the planning team already uses, which means your community's pins can sit as a layer next to the official data instead of as a screenshot in an appendix. That is usually the moment a consultation stops being consultative and starts being evidence.

Five mistakes to avoid

1. Eight categories. Nobody can read the legend and nobody can read the map.
2. A boundary drawn so tightly that affected neighbours cannot contribute.
3. No address fallback, so the consultation excludes the people who most need transport and access improvements.
4. Launching with an empty map and no seeding, so the first fifty visitors see a blank canvas and leave.
5. Reporting pin counts without reporting where you promoted the link.