Skip to content

PATTERN Cited by 1 source

Intermediate waypoint for context surfacing

Problem

A driver (or delivery courier, or any mobile worker) needs a specific piece of context delivered at a specific moment in their journey — gate code as they approach the gate, detour explanation as they reach the rerouted turn, managed-entrance lane guidance as they reach the venue gate.

The usual notification hooks are too coarse:

  • Job-state transitions (matched, arrived, delivered) fire at boundaries that are usually too early or too late for in-journey context.
  • Time-based triggers ("after 3 minutes of driving") are disconnected from the actual geographic moment the context becomes actionable.
  • Manual rider prompting ("hey the gate code is 1234") is the rider-driver communication black hole the platform should be eliminating, not relying on.

Delivering the context too early wastes the driver's attention and is often forgotten by the moment it matters. Delivering it too late — or via an in-trip chat ping that arrives mid-turn — is a driver-safety risk.

Solution

Insert an invisible intermediate waypoint into the driver's route at the location where the context becomes actionable. The waypoint:

  1. Is part of the routing graph so the routing system knows when the driver is approaching it — producing a precise, predictable geographic event.
  2. Is invisible to the driver as a stop — it doesn't change turn-by-turn meaningfully; the driver passes through it.
  3. Triggers context surfacing in the app when the driver reaches some threshold distance from it — typically a small, scannable banner on the nav screen.

The core move is using the routing graph as a UX timing primitive. The routing change is small; the UX unlock is meaningful.

Canonical instance — Lyft gated-community pickup

Per the 2026-04-23 Lyft write-up (sources/2026-04-23-lyft-smarter-pickup-experience-for-gated-communities):

"For gated communities, our Routing team introduced a new 'detour': the gate itself becomes an intermediate stop, an arbitrary, 'invisible' stop that the driver passes through on the way to the rider. (…) This seemingly small routing tweak creates something valuable: a precise moment in the driver's journey where we can surface gate instructions at exactly the right time."

Lyft's pickup routing inserts the gate as the waypoint. The driver app subscribes to "approaching waypoint" and surfaces a scannable banner with the rider's pre-shared gate instructions — at the moment the driver can act on them, not before, not after.

Why this shape works

  • Precise timing without new telemetry. Existing routing already tracks "driver approaching waypoint" — no new geofence system needed.
  • Safe UX contract. Because it fires at a single well-defined moment, the banner can be designed to be brief, scannable, and safe to miss (chat/call remain as fallback) — the driver-safety contract.
  • Generalises cheaply. Any physical-world constraint that has a point representation — a gate, a detour turn, a venue entrance, an unsafe-curb bypass — can be a waypoint. Same UX primitive, different domain.

Where this pattern applies beyond gates

Lyft explicitly generalises to construction-closure bypasses and unsafe-curb detours — same pattern, different waypoint. Other candidates:

  • Venue-managed entrances — airports, stadiums, malls with specific rideshare lanes.
  • Multi-unit buildings — surface "go to west entrance, apt 4B has intercom" as the driver approaches.
  • Field-service / delivery — "ring bell, leave at side door" at the driveway waypoint.

When not to use

  • When the context is relevant throughout the trip, not at a specific moment (then surface it up front).
  • When the context is optional and rarely needed — the engineering cost of a waypoint insertion plus UX wiring only pays off when the gain is material.
Last updated · 550 distilled / 1,221 read