Product & Systems Designer
Waterline
Designing anticipatory systems for driver in flood-related events
Introduction
Experimenting how disaster-response systems can help drivers seconds before a car meets floodwater.
Waterline is an ongoing experiment testing whether anticipatory action and its logic can be reframed into automotive use cases. It borrows from my experience working in humanitarian sector and in anticipatory action. This project pretends to explore the intersection of both disaster response applied to under-stress and rare driving events.
The problem
Drivers keep entering floodwater despite warnings, sensors, and rerouting prompts
This is not primarily an engineering gap — vehicles already detect standing water and rain intensity reasonably well. It is a psychological-design gap: existing systems treat the driver as a rational actor who simply needs more data, when the driver approaching a flooded road is operating under panic, tunnel vision, social proof, and time pressure — states that predictably override rational risk calculus.
A prior exploration (the companion brief “Driver Psychology Under Flood Risk”) mapped these failure modes — normalcy bias, social proof, optimism bias, cognitive narrowing, and time pressure — and proposed a phased in-vehicle response (“Flood-Aware Drive Mode”) built around anticipation, bias-disruption, and one-tap safe actions.
Reframing
Most in-vehicle flood warnings are single-moment events
The car detects water, the car warns. Institutional early-warning systems for floods work differently — they never wait for the water to arrive. They monitor continuously, escalate through defined readiness levels as risk builds, and separate “what should happen” (thresholds, safety logic) from “what the user is allowed to touch” (configuration, preference).
Applied to a vehicle, this suggests two structural shifts:
From single warning to staged escalation — the system should already be “thinking” about flood risk 30–90 minutes before the driver reaches water, not just at the moment of encounter.
From one-size warning to layered permissions — some thresholds are too safety-critical to be editable by an individual driver in the moment; others are exactly where personalization should live.
Defining the logic¡
Where the analogy comes from
Large-scale flood-anticipation systems built for disaster response (used by emergency-management and risk-monitoring organizations to decide when and how to act before a flood hits a region) share a recognizable structure, independent of their specific institutional context:
A staged trigger ladder — a “no risk” baseline state, a “readiness” state activated well ahead of impact, a state requiring explicit human validation before action, and an “active response” state once risk is confirmed.
Separation of trigger logic from action parameters — the threshold that says “risk is rising” is defined and owned separately from the parameters of what happens next, and the two are only reconciled at the moment of activation.
Human-in-the-loop validation at the critical step — even where monitoring is automated, no system studied activates the highest-consequence action without a person confirming it.
Tiered access and permissions — different roles can view data, adjust thresholds, or approve activation, with the most consequential settings locked to the fewest people, following a “least privilege” principle.
A shared core engine, locally calibrated — the same decision logic is reused across different regions or contexts, but the specific numbers (rainfall thresholds, response windows) are calibrated locally rather than hard-coded globally.
Designed degradation — when connectivity or data quality drops, the system has an explicit fallback behavior rather than simply failing silently.
A closed learning loop — after an event, forecast accuracy and decision outcomes are reviewed to recalibrate thresholds for next time.
None of these patterns map onto a moving vehicle unchanged — a car does not have a multi-agency validation committee, and a driver cannot wait a week for “funds” to move. But the underlying shape — anticipate early, separate logic from parameters, protect the critical step, layer permissions, degrade gracefully, learn afterward — translates well to the cockpit.
Design contraints
Constraints & Open Considerations
6.1 Technical
Degraded-connectivity fallback: when live data drops, the system should default to a conservative, cached-risk posture (assume elevated risk when uncertain) rather than silently reverting to no-warning behavior.
Sensor fusion across forecast data, road-level water sensors where available, and vehicle telemetry (suspension movement, wheel slip) to reduce false positives.
Integration within existing automotive HMI stacks without requiring proprietary hardware most vehicles lack.
6.2 Human Factors
Alert fatigue: the S1→S2 escalation must be rare and high-signal, or drivers will learn to dismiss it — directly undermining the trust the S4 learning loop is meant to build.
Progressive friction (Section 4, S3) must be tuned carefully: too little and it doesn't interrupt impulsive decisions; too much and it reads as the system overriding the driver, which the psychology research and the driver-autonomy principle both warn against.
Cultural and vehicle-type variation: a stall-risk framing calibrated for a sedan says nothing useful to a motorcyclist or a driver of a working truck; the Tier 1 model needs multiple vehicle-class calibrations, not one generic curve.
6.3 Trust & Governance
Calibrating confidence: the system must communicate uncertainty (“forecast confidence: moderate”) rather than presenting every S1 trigger as equally certain — false confidence is as damaging as false alarms.
Auditability: because Tier 1 thresholds are locked, there should be a transparent, inspectable record of when and why they were last changed — an equivalent of an audit trail — so “locked” doesn't come to mean “opaque.”
Open question: should Tier 2 (fleet/household) ever be allowed to loosen a Tier 1 floor for a trusted, experienced driver — and if so, under what accountability? Left unresolved in this brief.
System concept
Staged Trigger States for Driving
Where the original brief proposed three moments (Trigger / Approach / Decision Point), this version proposes a five-state ladder, so the system’s posture — and what it is and isn’t allowed to do — is explicit at every point in the journey.
S0 — Ambient Monitoring (No Risk)
Default state for the overwhelming majority of driving. The system quietly ingests weather forecasts, river/drainage data where available, and crowd or infrastructure signals. No UI intrusion. This stage exists purely so the transition into S1 can be evidence-based rather than sudden.
S1 — Readiness (Anticipatory Trigger, ~30–90 min ahead)
Forecast or sensor data crosses a first threshold for the driver's planned or likely route. The HMI shifts tone — calm, ambient, non-alarming — and surfaces route options, safe-window estimates, and a chance to notify a contact, while there is still time to decide without pressure. This is the state most responsible for removing the time-pressure failure mode identified in the original psychology research.
S2 — Pending Validation (Approach / Cognitive Support)
The vehicle is closing in on a flagged segment and risk indicators have intensified. Rather than auto-acting, the system requires an explicit, low-friction acknowledgment from the driver — a deliberate confirmation, not a passive notice — before it will proceed to stage S3's stronger interventions. This preserves driver authority while creating a natural pause point that interrupts autonomic, tunnel-visioned driving.
S3 — Active Intervention (At the Decision Point)
The vehicle is at or immediately approaching standing/moving water. This is where the original brief's bias-disruption tools apply directly: social-proof counter-messaging, vehicle-specific stall-risk framing, and one-tap safe actions. New in this version: if a locked, safety-critical threshold is exceeded (see Section 5), the system does not passively warn — it introduces progressively increasing friction on the “proceed” action (e.g., a deliberate multi-second hold plus secondary confirmation) rather than fully overriding the driver, preserving control while making the unsafe path measurably harder to take by accident or impulse.
S4 — Post-Event Review (Learning)
After the encounter — whether the driver avoided or proceeded — the system logs context (forecast accuracy, time pressure, route familiarity, which prompts were shown, what was chosen) for two purposes: reinforcing the driver's own decision with feedback, and recalibrating thresholds over time so the system earns trust rather than crying wolf.