GCP Request
The app GIS specialists build ground control point requests in — which markers a surveyor has to set, re-measure or check, auto-validated against the technical rules before anyone drives to the site.
Product designer — the only designer on the project
PM, frontend, Head of Design, and the GIS specialists as stakeholders
Interviews with 5 GIS specialists, the request flow across GIS, managers and the field, every screen of the request builder, and the adoption metrics after release.
GIS specialists now send one standard request, and surveyors know what to do with every point on it.
The app suggests where an extra control point is needed for the network to hold up. Requests carry enough detail that a surveyor no longer has to guess what a point needs — a re-measure, or just a flag.
The placement rules moved into the interface. The app walks a specialist through what a valid network needs instead of leaving it to a document and a review.
45%
faster to create a GCP request
15%
fewer rework requests caused by errors
30%
fewer clarifying messages between GIS and the field
Nothing said what a point needed, or where a new one should go — so every request was argued out in a chat.
A point might need a re-measure, a repaint or just a flag, and a request had no way to say which. The placement rules lived in a document and in people's heads, so the GIS team ran a chat of its own where each request was checked by hand before it went out. Building one took half an hour, and a mistake in it only surfaced in the field.
A request builder for GIS specialists. It says which ground control points a surveyor has to set, re-measure or check in the field.
GIS specialists — highly skilled, technically proficient people who know exactly what a valid point network looks like and had no tool that agreed with them.
- Research and flow: user interviews with 5 GIS specialists
- UX/UI design
- Adoption metrics after release
One request crosses four roles before anyone drives to the site.
A GIS specialist creates it, a manager reviews and approves it, and a pilot or a surveyor does the work in the field. All of that used to run across email, Asana and Slack, with every request built and checked by hand.
The rules for a valid network live in the interface.
A request is only worth sending if the network behind it holds up: the points have to triangulate, and the quality control points have to cover the whole surveyed area.
- Problem
- Problem. What made a network valid — how the points triangulated, how far the quality control radiuses had to reach — lived in a document and in people's heads, so each request was argued through a chat before it went out.
- Solution
- Solution. Both rules are checked on the map while a specialist places the points, so a network that doesn't hold up says so while the request is still being built.
GCP point network
The app connects the points as they are placed and draws the network, so a gap in the coverage shows on the map while the request is still being built.
Quality control radiuses
A QC point is what the accuracy of a scan is verified against, and each one covers a defined radius — every point throws that radius over the site, and whatever the discs do not reach stays visible until another point closes it.
A surveyor has to know what to do with a point, not just that something is wrong with it.
Every point on the map is one of these, and the glyph says which — what it is, and what still has to happen to it.
| EC | Existing control. Already standing on site, not yet measured — somebody has to find it and check it. |
|---|---|
| EC, check first | The existing controls to start with. A request asks for at least five of them to be marked this way. |
| Requested GCP | A new ground control point, to be set in the field. |
| Requested QC | A new quality control point, to be set in the field. |
| Corrupted GCP | An existing point reported broken. Red has to be replaced — damaged or undetectable; yellow only needs cleaning up or repainting — obstructed, faded, covered. |
| Corrupted QC | The same two levels of damage, on a quality control point. |
| Need coordinates, GCP | The point is standing, but its coordinate is missing — it has to be measured. |
| Need coordinates, QC | The same, on a quality control point. |
| GCP | Ground control point. A measured marker the scan is aligned to. |
|---|---|
| QC | Quality control point. A measured marker the accuracy of a scan is verified against. |
| Fake GCP | A control the alignment uses that has no physical marker standing on site. |
| Measured EC | An existing control that has been measured, so it counts as a control like any other. |
- Problem
- Problem. A point could say that something was wrong with it and no more. Whether it had to be replaced, repainted or only checked was worked out in a chat after the request had already gone out.
- Solution
- Solution. Every point carries a status, and where a status is not enough, a comment — so the instruction travels with the request to the person standing at the point.
Set point status
Stable points get damaged, faded or covered. The status says which — and with it, whether the point is replaced, repainted or only checked.
Add a comment
When a status is not enough, a comment goes out with the request — so the context reaches the point instead of staying in a chat.
Every kind of work a point needs draws as its own marker.
One glyph per type of work, so the map says what has to happen to a point before anyone opens it. The screens above are built from the same small set of pieces around them: groups that sort the markers, a row that opens into everything known about one point, and a bar that acts on any number of them at once.
The action menu
- Problem
- Problem. Every point had to be handled on its own — a request where all the existing controls needed re-measuring meant repeating the same action down the list.
- Solution
- Solution. Any number of points can be selected together, and one menu acts on all of them, offering only what is valid for every point in the selection.
On site the surveyor corrects the points and measures them, and what comes back is a file the app can read, with the site scan.
The surveyor installs the new GCP markers and fixes the existing ones, then submits a file with the updated coordinates. Once it lands, the new positions are previewed against the old ones before anything is imported for good.
The app has more of the job to take on.
We keep an eye on the GIS team's own task backlog, and what's below is what appeared in it after the release.
More context in one place
After the rollout we found GIS specialists still switching to other applications for parts of the job — reviewing technical drawings, analysing how elevation changed over time. Those move into the app next.
Review while the request is still open
A request costs money the moment it reaches the field, so the other roles want to review it as it is being built rather than after it has been sent.