OS Maps. Adding a live path conditions layer to a product 5 million people trust with their safety.

A value test of 45 OS Maps users, plus analysis of reviews and 36 items of feedback on the project ticket, gave a clear picture. 82% had cut a walk short over an obstacle. 84% didn't know how to report one, and only 9% ever had.

The insight that shaped the design: when asked about incentives, core users didn't want rewards. They wanted to see the problem flagged on a live map. So the design didn't lean on points or badges to drive reporting: the motivation was already there. It needed a loop worth contributing to, not a game.

Two obstacle types mattered in different ways. Muddy and boggy paths were the most frequent (3.67 of 5). Flooded paths were the most disruptive (3.87 of 5). Mud is constant. Floods ruin the day. That split fed the priority matrix and the category choices.

I ran a teardown across five products: Waze, Ramblers' Pathwatch, AllTrails, OutdoorActive and Garmin.

Waze was the reference for the loop. Real-time display, community validation, expiry on unconfirmed reports and reporting limits had all been proven at scale. I took the mechanics, not the gamification. Pathwatch was the warning: an engaged base let down by a slow, bureaucratic flow that never told users what happened to a report. AllTrails had gone the other way, putting land owners in charge through its Public Lands Program, which solved a different problem and depended on engagement we couldn't control. OutdoorActive's community contribution was vague and Germany-focused. Garmin's was cycling-only and buried.

The takeaway: the validation loop is the product. Get it wrong and the map fills with noise. Get it right and the data stays credible without a moderation team behind it.

Discovery used a value / viability / feasibility / usability risk frame. The IP risk was real and got checked properly: relevant Waze and Google patents covered vehicular routing and had lapsed or expired, and we built our own icons in-house specifically so we couldn't be accused of passing off Waze's. The compliance risk was real too, and is covered in the trust section below.

This didn't start as a reporting feature. Four directions were explored before landing on the community loop:

I argued for the community loop instead. Framed as a feasibility and time-to-value call, not a preference: the flood-data route was the heavy, slow, full-build option, carrying maintenance, freshness and multi-jurisdiction licensing overhead, for partial coverage. The community loop was the version we could ship, learn from, and expand. The PM and I also saw the strategic upside: crowdsourced reports would be data unique to OS Maps, which raised the app's value precisely because no competitor had it. That was the call I pushed for.

Once we committed to community data, the design problem became: what rules make crowdsourced reports trustworthy enough to act on? Every number was a decision, worked through with the PM and engineering.

20m clustering. Phone GPS is accurate to roughly 20m. Two reports closer than that are almost certainly the same issue, and the pins would be impossible to tap apart anyway. So reports within 20m of the same category merge in the UI and stay separate in the database. This came directly from an engineering input on GPS accuracy: a feasibility constraint that set a design rule.

800m drop-pin radius. You can report from your location or drop a pin, because testing showed people wanted to reach safety first ("I'd get to a safe spot before reporting cows in a field"). But only within 800m, the width of an iPhone SE slightly zoomed out. If you have to pan the map to place the pin, you're too far away for the report to be accurate.

30km validation radius. You can validate a report after your walk, from home or your accommodation, but not from the other end of the country. 30km lets genuine validation happen without opening the door to someone confirming Scottish reports from Cornwall.

2-week expiry. Reports auto-expire unless confirmed, and the timer resets on each confirmation. Path data changes slowly, so two weeks balances freshness against churn. The expiry was aligned across all categories at engineering's request, to keep the build simple for MVP: a feasibility trade-off accepted knowingly, with per-category expiry deferred.

Removal that resists spam. One report needs one "not here" to be removed. Two or more reports need two, so a single bad actor can't wipe a confirmed condition off the map.

And the strongest trust call: no usernames. We chose not to show who reported a condition. A name, plus a location, plus a route someone walks regularly, makes them identifiable, and that's a real safety risk for solo walkers, women especially. We had no in-house privacy controls to mitigate it at launch. This was a design-PM call made before the DPO review, then confirmed by it: we'd rather lose the social proof of a name than expose a user. Reporting also needs exact location at the moment of tapping, which made location tracking essential functionality and triggered EULA and DPIA updates. Compliance shaped what the feature could be.

I started with hand-drawn sketches mapping the core loop, then low-fi report a hazard v1 and v2, moving from a tools-menu entry point to a map-first report action. Then I ran moderated remote testing with nine OS Champions, using a seeing / meaning / doing structure and changing the prototype as findings landed. The main results:

The honest limit: this was remote, at desk, on a high-fidelity prototype. Reporting mid-walk, on patchy signal, with cold hands, is a different test. We knew that going in.

The MVP / MMP / MLP phasing was a roadmap, not just a release plan. Each phase was gated on what the last one proved.

The logic throughout: ship the cheapest thing that validates the riskiest assumption first, and defer anything that adds moderation, legal or build overhead until the prior phase earns it.