01 · 現場不是平均使用者
高層建築警報響起後,多數人能走安全梯,但輪椅使用者與部分病患只能前往避難區等待。傳統告示只寫「火警勿用電梯」,卻沒有說明誰來確認、如何通訊,以及受控疏散電梯何時可以運作。
這一場景提醒我們,設計對象不是抽象的平均值,而是會在壓力、時間限制與不同身體條件下完成具體任務的人。
02 · 機制從哪裡開始
受控疏散依賴防煙分區、備援電力、井道狀態、候梯區通訊與人工指揮。系統要把感測狀態轉成可理解的模式,而不是讓一般乘客自行判讀。任何關鍵信號矛盾時,預設應停止自動放行並升級人工確認。
因此不能用單一指標代表整個系統;量測必須與流程節點對應,並讓讀者知道數據能夠解釋什麼、不能解釋什麼。
03 · 證據要怎樣收集
需要樓層煙霧與溫度、電力來源、門區狀態、轎廂位置、避難區人數和協助需求。個人健康資料只收集完成疏散所必需的部分,並限制可見人員,演練資料與真實事件也要清楚分開。
所有精確數字都應記錄來源、時間和適用邊界;本頁指標屬於設計示例,用來說明結構,不冒充研究結論。
04 · 把原則變成流程
警報後先切換專用模式,確認安全樓層與避難區,再由控制中心安排批次。顯示器明確告知等待、登梯或改走替代路線;每次運送完成回報人數與目的樓層,讓下一批不依賴口頭猜測。
實施時應先小規模驗證,保留人工覆蓋與退出路徑,再根據真實反饋迭代;自動化只能執行已說明的邊界。
05 · 最容易出現的誤判
只追求最快總疏散時間可能犧牲最需要協助的人;固定優先名單又可能在樓層受煙影響時失效。設計必須允許規則因現場狀態調整,同時留下誰在何時改變優先序的紀錄。
對異常與失敗保留記錄比隱藏警報更重要。若系統只展示成功案例,管理者就無法看見結構性缺口。
06 · 如何作出可解釋決定
演練要測試通訊中斷、感測矛盾、電力切換與人員超出預估等情境。關鍵成果不是動畫順利跑完,而是等待者是否持續收到資訊、替代方案是否明確、指揮者能否解釋每次決定。
最終報告應同時呈現收益、代價、未覆蓋人群與剩餘不確定性,避免把複雜公共問題壓縮成單一漂亮分數。
07 · 部署前的實務檢核
「火警時的電梯,不該只有「能用/不能用」兩種答案」不應停留在概念展示。正式投入使用前,需把使用者、設備、資料與例外情境放進同一輪小規模測試,事先寫清成功條件、停止條件與人工接管方式。測試紀錄要保留失敗與缺漏,不能只挑選最順利的流程作為成果。
- 與行動不便使用者共同演練等待、通訊、登梯和抵達確認
- 加入煙霧訊號矛盾、備援電力切換與控制中心失聯情境
- 逐次核對樓層狀態、候梯區人數與轎廂任務,不以固定名單取代現場判斷
- 演練後公開等待時間分布及未完成項目,而不只公佈總疏散時間
完成檢核後,應由實際受影響的人參與復盤:哪些步驟變得更容易,哪些人仍被排除,資料是否足以支持判斷,以及新增流程是否帶來隱私、時間或維護負擔。若證據不足,就把結論標示為待驗證,而不是用精確分數製造確定感。
編輯檢核:本文提出的是可測試的設計框架,不是已完成的產品結論。正式部署前應由實際使用者、維護者與受影響群體共同複核資料邊界、例外情境、人工接管和停止條件,並保留失敗紀錄供後續修正。