昨天談到救災現場真正棘手的問題之一，是大量的人力、物資與需求同時出現，卻缺乏有效的資訊協作機制。當災情快速變化時，一個地區可能同時收到多組志工、物資與民間資源，但另一個更急迫的地區卻還在等待支援。對前線來說，資訊的落差會直接影響資源是否能在正確的時間抵達正確的地方。
所以，如果今天要設計一個救災協作平台，我會先把問題拉回產品設計最基本的一步：到底是誰遇到了什麼問題？
這也是我在做高風險場域產品時很重視的一件事。當系統涉及醫療、運動、救災等真實世界的決策，產品定義需要從現場的工作流程、角色、限制與資訊缺口往回推，而不能只從「我們可以提供什麼功能」開始。
如果真的要開始做這個平台，我會先從具有實際救災經驗的人開始訪談，例如參與過地震、颱風、土石流等災害支援的志工、NGO 工作者、地方社群組織，以及負責物資與人力調度的人員。
訪談時，我會避免直接問「你希望有什麼功能？」這類問題。使用者通常很難在沒有具體情境的情況下，準確描述自己需要什麼產品。更有效的方法，是請他們回想最近一次實際參與救災的經驗，從事件發生、收到消息、前往現場、接受任務，到任務結束，一步一步還原當時發生了什麼。
例如可以追問：「你當時怎麼知道哪裡需要人？」、「誰告訴你這個需求？」、「資訊是從哪裡來的？」、「你怎麼確認這個需求還存在？」、「如果同一個地方已經有人去了，你知道嗎？」以及「任務完成之後，誰知道它已經完成？」
除了訪談，我也會加入次級資料分析。災後檢討報告、政府公開資訊、新聞報導、NGO 的紀錄，以及社群平台上的公開貼文，都可以用來補足單次訪談可能產生的偏差。尤其是災害這種高變動場景，事後資料往往可以幫助我們看到當時資訊如何流動，以及哪些環節反覆出現協作問題。
以我實際參與的一次在地訪談為例，受訪的協會工作者提到，災後真正最混亂的，其實是前三天：政府單位進駐得慢，對口人員又採輪值制，幾乎每天早上都要重新確認「今天要找誰」；物資站的溝通幾乎完全依賴 Line 群組，特殊車輛的通行申請則得靠打電話一一協調；車輛動線一度卡死，通行證發放的標準也不夠清楚，因而引發不少現場爭執。這些細節不一定能直接變成產品功能，但它們讓我更清楚知道，真正卡住現場的，往往是「找人」與「對齊資訊」這類看似瑣碎、卻每天都在重複發生的行政負擔。
研究完成後，下一個挑戰是把大量的故事整理成可以支持產品決策的洞察。
假設在訪談中反覆出現幾種情境：志工加入救災後，不知道哪裡最需要人；物資提供者知道自己有物資，卻不知道哪個地點真的缺；災情回報很多，但不同來源的資訊彼此重複甚至互相矛盾；任務發布之後，也很難知道現在究竟是「等待支援」、「有人接了」、「處理中」還是「已完成」。
這些現象可以進一步被整理成幾個核心洞察。
第一，志工需要的是「下一個最有價值的行動」。當大量志工同時進入災區，比起一張塞滿所有任務的清單，他們更需要的是能根據地點、技能、交通條件與當前需求，快速判斷自己現在去哪裡最有幫助的建議。
第二，需求的有效期限非常短。一筆「需要 20 箱飲用水」的需求，在兩個小時後可能已經完全改變。因此平台需要持續處理需求的新鮮度與狀態，才能避免系統只是單純累積更多回報。
第三，資訊可信度本身就是產品問題。不同人可能從不同管道回報同一件事情，平台需要讓使用者知道資訊來源、更新時間與目前確認狀態。
第四，任務完成後的狀態回傳同樣重要。如果平台只負責「發布需求」，卻沒有後續的狀態追蹤，很快就會再次形成資訊黑洞。
這幾個洞察會直接影響後面的產品架構。
接下來，我會把使用者分成至少兩個主要角色：需求端與供給端。
需求端可能是災區居民、地方組織、社區管理者或前線工作者。他們的旅程通常從「發現問題」開始，例如道路中斷、長者需要撤離、某個避難點缺乏飲水或醫療用品。接著，他們需要回報需求、補充細節、等待確認，最後確認資源是否真的抵達。
這條旅程最大的斷點，通常發生在「回報之後」。需求被提交之後，回報者不知道有沒有人看見，也不知道是否已經有人處理。如果同一個需求被不同人重複回報，系統又沒有整合，就會進一步增加資訊噪音。
供給端的旅程則完全不同。志工或物資提供者可能先看到災情，接著想知道「我現在可以做什麼」，然後尋找適合自己的任務，再確認地點、需求內容與安全條件，最後認領任務並回報進度。
這裡的核心斷點是「選擇」。當平台上同時存在幾十甚至幾百筆需求時，使用者如何判斷哪一個任務最值得自己處理？如果只是按照時間排序，最早發布的任務未必最急；如果全部依照緊急程度排序，也可能忽略距離、技能與現場容量。
因此，平台真正需要解決的，是讓需求與資源之間產生更有效的匹配。
當問題被理解之後，我會開始做範疇取捨。
救災平台很容易越做越大。從災情回報、志工管理、物資調度、捐款、交通、避難所管理，到政府指揮系統，每一個方向都可以延伸成一個大型產品。
但如果第一版產品同時想解決所有問題，最後很可能沒有一個核心流程能真正被做好。
因此，我會把產品定位在資訊媒合與協作層。它可以協助不同來源的需求被整理、讓可用的人力與物資找到適合的需求，也讓任務進度能被持續更新。
相對地，我不會直接把政府排除在產品之外，而是在角色設計裡，另外拉出一個「指揮官」角色，讓政府或正式指揮體系可以用這個角色進入平台，掌握全局的需求分布、資源調度與任務狀態，但不直接取代既有的行政系統與金流捐款流程。這樣的邊界可以讓產品更清楚，也能降低系統介入高風險決策核心所產生的責任問題。
沿著這個方向，我會把角色再拆得更細一些，設計成一個「角色切換」功能：使用者進入平台後，可以依照自己當下的身份切換視角，包含災民、指揮所、救難隊、消防隊、醫療團隊、無人機隊伍、在地組織、線上志工，以及現場志工。每一個角色看到的資訊與可以採取的行動都不一樣——災民關心的是自己的需求有沒有被看見與處理；指揮所需要的是全局的資源分布與任務進度；救難隊、消防隊與醫療團隊需要清楚的任務指派與現場狀況；無人機隊伍可能負責提供空拍與勘災資訊，協助其他角色判斷現場狀態；在地組織熟悉當地環境，能補足外部資源看不到的細節；線上志工可以在遠端協助資訊彙整、查證與媒合；現場志工則需要知道自己現在最應該去哪裡。角色切換功能讓同一個平台可以服務所有這些不同的人，同時確保每個人只看到與自己相關、對自己有用的資訊，而不是被淹沒在整個系統的所有資料裡。
這一步其實和前面醫療 AI 的討論非常相似：高風險產品的能力邊界，本身就是設計的一部分。
最後，我會把前面的研究收斂成三個產品支柱。
第一是災情回報與彙整。使用者可以提交需求，包含地點、需求類型、數量、緊急程度、照片或其他佐證資訊。系統則負責將相近或重複的需求進行整理，並顯示資訊來源、最後更新時間與確認狀態。
這裡還有一個很實際的問題：重複開單。當同一個地點已經有人回報過需求、甚至已經有人正在處理，介面上就應該讓使用者在提交前先看到，避免大家各自開單、卻不知道彼此在講同一件事。除了畫面上的提醒，AI 也可以在使用者輸入地點與需求內容時，比對現有的資料，判斷這是不是與既有的某一筆需求高度相似，並主動提示「這裡可能已經有一筆類似的需求，要不要直接合併，或補充在原本的紀錄底下？」這樣的機制可以讓重複回報不再變成新的噪音，反而成為補充現場最新狀態的來源。
第二是資源需求媒合。平台需要讓志工、物資提供者與需求建立關係。媒合條件可以包含距離、技能、可提供的物資、任務緊急程度與現場需求量，讓使用者更快找到適合自己的任務。
第三是任務認領與狀態追蹤。一個需求從「待確認」到「待支援」、「已認領」、「處理中」再到「完成」，每一個狀態都應該被清楚記錄。這會讓整個救災協作從一次性的資訊發布，變成一個可以持續更新的工作流。
如果把這三個支柱畫成資訊架構，首頁可能會圍繞「現在發生什麼」、「哪裡最需要支援」與「我現在可以做什麼」三個問題展開。需求端進入後可以快速回報與追蹤案件；供給端則可以看到與自己相關的任務，認領後持續更新狀態；平台中間則負責處理需求、資源與任務之間的關係。
到這裡，一個模糊的問題才真正開始變成產品。
我們從「救災現場資訊很混亂」開始，經過訪談、次級資料分析、角色與旅程拆解，再進一步定義產品邊界與核心功能。這個過程的價值，在於把一個很大的社會問題，收斂成幾個可以被設計、驗證與迭代的產品問題。
接下來真正有趣的地方就來了。
如果今天只有很短的時間，我會怎麼把這套產品定義快速轉成可以操作的初版？從資訊架構、使用者流程，到介面原型，我又能怎麼利用 AI 把原本需要數天甚至數週的設計工作壓縮到幾個小時？
Day 20，我會直接進入實作：如何利用 AI，在極短時間內完成一個救災協作平台的第一版。
iThome鐵人賽
看影片追技術