01 · 現場不是平均使用者
暴雨下班時,導航仍把行人帶向最低窪的地下道。前方水只到腳踝,卻因混濁看不見路緣,旁邊排水口形成吸力。此時「水深幾公分」不是唯一問題,路面是否完整、流速是否增加同樣關鍵。
這一場景提醒我們,設計對象不是抽象的平均值,而是會在壓力、時間限制與不同身體條件下完成具體任務的人。
02 · 機制從哪裡開始
步行穩定受水流推力、鞋底摩擦、視覺參照與落腳面連續性共同影響。水深與流速通常同時變化,地下設施損壞還會製造突變風險。因此系統應將已知、推測和未知區域分別表達。
因此不能用單一指標代表整個系統;量測必須與流程節點對應,並讓讀者知道數據能夠解釋什麼、不能解釋什麼。
03 · 證據要怎樣收集
資訊可來自固定水位計、道路攝影、維修通報與居民回報,但每個來源要附時間和可信度。照片無法直接推出水深,感測器也不能證明整段道路安全;只有多來源交叉才能提高決策品質。
所有精確數字都應記錄來源、時間和適用邊界;本頁指標屬於設計示例,用來說明結構,不冒充研究結論。
04 · 把原則變成流程
先封鎖已知高風險點,再發布可通行替代路線;回報介面要求位置、時間、方向與可辨識參照物。當資料過期或互相矛盾時,地圖降級為未知,不用陳舊的綠色標記鼓勵通行。
實施時應先小規模驗證,保留人工覆蓋與退出路徑,再根據真實反饋迭代;自動化只能執行已說明的邊界。
05 · 最容易出現的誤判
群眾回報量多不代表覆蓋完整,熱門道路往往資料密集,弱勢社區反而空白。把沒有回報解讀成沒有積水,會形成危險的沈默偏差。系統需要主動標示未觀測區域並安排巡查。
對異常與失敗保留記錄比隱藏警報更重要。若系統只展示成功案例,管理者就無法看見結構性缺口。
06 · 如何作出可解釋決定
對一般行人最有用的輸出是「不要進入、等待更新、改走哪裡」,而不是複雜水文圖。管理端則需要感測異常、資料新鮮度與封鎖執行情況,兩種介面不應混為一談。
最終報告應同時呈現收益、代價、未覆蓋人群與剩餘不確定性,避免把複雜公共問題壓縮成單一漂亮分數。
07 · 部署前的實務檢核
「積水看起來不深,腳下可能已經沒有路」不應停留在概念展示。正式投入使用前,需把使用者、設備、資料與例外情境放進同一輪小規模測試,事先寫清成功條件、停止條件與人工接管方式。測試紀錄要保留失敗與缺漏,不能只挑選最順利的流程作為成果。
- 每則回報附位置、方向、時間與可辨識參照物,逾時後自動降低可信度
- 對感測器、照片與居民回報做交叉確認,清楚標示未觀測區域
- 測試井蓋移位、夜間低能見度、訊號中斷和道路突然封閉
- 把替代路線是否對輪椅、長者和兒童可行納入發佈前檢查
完成檢核後,應由實際受影響的人參與復盤:哪些步驟變得更容易,哪些人仍被排除,資料是否足以支持判斷,以及新增流程是否帶來隱私、時間或維護負擔。若證據不足,就把結論標示為待驗證,而不是用精確分數製造確定感。
編輯檢核:本文提出的是可測試的設計框架,不是已完成的產品結論。正式部署前應由實際使用者、維護者與受影響群體共同複核資料邊界、例外情境、人工接管和停止條件,並保留失敗紀錄供後續修正。