北京
多年處理二類醫療器械的可用性文檔，我逐漸看清一個規律：當這份文檔淪為合規擺設時，產品上市后往往悄悄蔓延三類問題——操作失誤率上升、糾正措施頻次走高、注冊周期莫名拉長。相反，把可用性文檔當成“設計決策的記錄儀”，它能反哺產品，甚至比幾輪用戶訪談更早暴露致命交互缺陷。這份文檔的本質不是證明“我們做了可用性工程”，而是證明“風險控制真的在用戶手里奏效”。
標準框架本身并不難理解——IEC 62366-1 搭骨架，FDA 人因指南定節奏，二者都指向同一個終點：使用安全。難的是讓文件里的每一條記錄都形成可追溯的鏈條。一份真正經得起審核的可用性文檔，至少要做到三件事：說清誰會使用這個設備、在什么環境里用、用的時候真實場景是怎樣的；然后把使用過程中可能引發傷害的交互逐一拆解，并跟 ISO 14971 的風險管理思路對接；最后用形成性測試和總結性測試的證據，證明你加進去的那些風險控制措施不是紙上談兵。我見過太多 40 頁厚的文檔，缺少的就是這三根鏈條之間的咬合點——一旦斷開，審核員的追問就像刀子一樣精準扎進那些模糊地帶。
在多次審核和內部復盤里，我反復撞見八種典型的失敗模式。第一個坑是時機錯配，人因工作啟動得太晚。硬件定型了、圖形交互凍結了，可用性工程師才被請進來“把把關”，這時提出的任何建議都像在竣工大廈里要求改地基，開發團隊本能抵抗，最終能落地的寥寥無幾。第二個坑是使用場景的畫像太薄。用戶欄只寫“護士”或“患者”兩個粗顆粒標簽，缺少角色細分、操作環境特征、培訓背景和典型工作負荷的描述。沒有這些勾勒，任務分析很難真正觸及那些忙亂病房里才會暴露的誤操作點。
任務分析本身也容易滑向抽象。高層級步驟比如“準備設備”“執行給藥”看起來清晰，但如果不往下拆解出關鍵子任務和容易出錯的交互環節，就等于只在危險區外圍畫了一圈輪廓線。更麻煩的是形成性測試名不副實。小規模、散點式的測試只產出一堆觀察筆記，卻沒有推動設計的迭代調整——測試的發現沒能變成設計輸入，形成性就只剩形骸。
到了總結性測試階段，失真問題更隱蔽。實驗室條件過于純凈、任務腳本太機械、招募的測試者跟真實用戶特征偏離，這些都讓測試結果像在排練過的舞臺上測產品的極限——跟現實世界的混亂與壓力毫無關系。另一個被嚴重低估的斷裂點，是人因發現與風險管理之間的連接松脫。可用性測試里看到的問題，如果沒有追溯到對應的危險、風險控制措施以及殘余風險的可接受標準，監管審核時就會顯露出致命的信息孤島。再加上測試腳本、知情同意書、主持人筆記這些文檔未能存留或者通過標準含糊，整個檔案的完整度就更加脆弱。
最隱蔽也最難修補的窟窿，是上市后的反饋回路斷裂。用戶投訴和糾正措施源源不斷涌回來，卻沒有一條通路能把這些信息導入人因流程，更談不上據此更新可用性文檔。這意味著產品一代一代迭代，同樣的使用錯誤卻可能原封不動地繼承下來。
我在一家兩百人規模的公司里，跟一個小型質量法規團隊一起摸索出一套低負擔的務實做法。頭一條就是把可用性工程推到需求階段啟動。讓預期用戶、使用環境、操作頻率和關鍵任務這些元素直接寫進最初的需求規格說明里，能有效防止后期需求范圍的突然膨脹。對每項關鍵任務，用一條簡明標注直接體現其關鍵性，開發人員掃一眼就能讀出風險等級和成功完成的標準，連同什么算一次使用錯誤都界定清楚。
招募受試者時，不拿方便樣本湊數。如果實在接觸不到臨床人員，用經過驗證的腳本進行線上模擬才是最后的備用方案，而不是默認選項。形成性測試中，哪怕是紙板原型也能在早期暴露操作邏輯的根本性錯位，關鍵是要讓原型具備足夠的真實交互感。所有測試發現的處理結果也要留一條清晰的追蹤線，直接關聯到對應的設計變更和風險緩解措施的更新。這套做法不追求文件厚度，而是追求每一條記錄都能在審核時被迅速定位和解釋——這才是可用性文檔脫離合規道具、回歸設計安全記錄本色的唯一路徑。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
