第一次被核查老师问到"你们产品的可用性工程是怎么做的"的时候，我整个人是懵的。
那是在2024年，NMPA刚刚发布了《医疗器械可用性工程注册审查指导原则》。老师翻着我们的设计输入清单，说："你们的设计输入里写了电气安全指标、写了性能指标、写了环境适应性指标，但没看到可用性要求。你们产品的用户是谁？使用场景是什么？用户界面怎么验证的？"
我张了张嘴，答不上来。
后来查了资料才知道，IEC 62366这个标准早在2015年就发布了，YY/T 1474-2016也已经等同采用了好几年。但国内很多企业——包括我当时所在的公司——对这个标准的重视程度远远不够。设计输入阶段只关注"产品能做什么"，几乎不考虑"用户怎么用"。
今天就用一套"做菜"的比喻，帮你彻底理清IEC 62366可用性工程的核心逻辑，以及如何把它无缝融入设计开发输入。
图：可用性工程核心三角——用户 × 使用场景 × 用户界面
一、可用性工程是什么？用"做菜"来理解
很多人一听到"可用性工程"就觉得高大上、很复杂。其实就是：让人用得好。
用做菜的比喻来说：
用户（User）= 吃菜的人。是老人还是年轻人？口味偏清淡还是偏辣？有没有忌口或过敏？——这就是用户画像分析。
使用场景（Use Scenario）= 吃饭的场合。是家庭日常聚餐、是户外野餐、还是宴席招待？不同场合对菜品的要求完全不同。
用户界面（User Interface）= 餐具和摆盘。筷子怎么放最顺手？盘子怎么摆最美观？温度怎么保持最合适？——这些细节决定了用户的用餐体验。
使用错误（Use Error）= 吃菜时出岔子。老人看不清菜单点错了菜、户外风大吹翻了盘子、宴席上菜顺序搞混了——这些都是"使用错误"，根源往往是"没有充分考虑用户、场景和界面的匹配"。
在医疗器械行业，这个逻辑更加关键。一个输液泵如果界面设计不合理，护士在紧急情况下可能输错剂量；一台除颤仪如果操作步骤太复杂，急救现场可能错过黄金救援时间。可用性工程的目的，就是在设计阶段就识别和消除这些"使用错误"的风险。
二、IEC 62366的核心框架：一个三角、两个评价
IEC 62366-1:2015+A1:2020的框架可以简化为"一个三角、两个评价"。
"一个三角"就是用户、使用场景、用户界面三者构成的可用性工程核心三角。三者交汇处就是"使用错误"的发生点。标准的核心逻辑是：通过系统性地分析用户特征、使用场景和用户界面，识别潜在的使用错误，并采取风险控制措施。
"两个评价"是形成性评价（Formative Evaluation）和总结性评价（Summative Evaluation）。
形成性评价 = 做菜过程中的"尝味道"。在设计的早期和中期阶段，邀请目标用户参与测试，发现问题、调整设计。可以做多次，目的是"改进"。
总结性评价 = 上桌前的"最终品鉴"。在设计定型的后期阶段，用有代表性的用户样本做最终验证，确认使用风险已经充分控制。通常只做一次，目的是"确认"。
NMPA 2024年发布的《医疗器械可用性工程注册审查指导原则》明确要求：高使用风险的产品，必须提交完整的可用性工程研究报告，包括形成性评价和总结性评价；中使用风险的产品，可用性工程活动可以裁剪；低使用风险的产品，建议融入可用性考量但可以简化。
图：可用性工程融入设计开发输入的六步落地法
三、如何将可用性工程融入设计开发输入？六步落地法
可用性工程不是"额外的工作"，而是设计开发输入的有机组成部分。下面是我在项目中总结的六步落地法。
Step 1：定义用户（确定谁来吃这道菜）。
分析用户画像：使用产品的人是谁？医生、护士、患者还是家属？他们的年龄范围、教育背景、专业经验、身体条件、培训情况是什么？不同用户群体的能力和需求差异巨大——专业医生能看懂复杂的参数设置，但患者家属可能完全看不懂。
输出物：《使用规范》文档，明确用户群体的定义和特征。
Step 2：明确场景（确定在什么场合吃）。
识别所有使用场景：常规使用场景（日常操作）、紧急使用场景（急救、故障处理）、异常使用场景（误操作后的应对）。还要考虑环境因素：光线、噪音、温度、湿度、电磁干扰、使用者的精神负荷和体力状态。
输出物：《使用场景清单》，覆盖常规、紧急、异常三种场景。
Step 3：分析任务（确定菜要怎么吃）。
梳理所有与产品使用相关的操作任务，特别关注与危险相关的任务。比如：开机设置、参数调整、报警处理、清洁消毒、维护保养。哪些任务一旦出错可能导致伤害？这些就是"关键任务"，需要重点分析。
输出物：《关键任务清单》，标注与危险相关的关键任务。
Step 4：识别风险（分析吃什么可能出问题）。
基于前三步的分析，识别潜在的使用错误模式。IEC 62366提供了一套系统的使用错误分析方法：从用户特征、使用场景、用户界面三个维度出发，识别可能导致使用错误的原因，评估使用错误的严重度，并与ISO 14971的风险管理过程对接。
输出物：《使用风险评估》报告，含使用错误模式与对应的风险控制措施。
Step 5：转化为设计输入（把需求写进菜谱）。
这是最关键的一步——把可用性工程的分析结果转化为具体的设计输入项。例如：用户界面要求（"主屏幕必须在3秒内显示关键参数"）、报警要求（"高优先级报警必须伴随声光双重提示且音量不低于XX dB"）、说明书要求（"操作步骤不超过5步，每步配有图示"）。这些要求要和功能性要求、安全性要求一起，写入设计输入清单。
输出物：《设计输入-可用性》清单，作为整体设计输入的一部分。
Step 6：验证闭环（做好菜让顾客试吃）。
通过形成性评价（设计过程中多次用户测试）和总结性评价（设计定型后最终验证），确认可用性要求已经满足、使用风险已经充分控制。验证不通过的要回到设计阶段迭代优化。
输出物：《可用性验证报告》，含形成性评价和总结性评价结果。
四、三个避坑要点
坑一：把可用性工程当成"用户体验设计"。
可用性工程（Usability Engineering）和用户体验设计（UXDesign）有相似之处，但目标不同。UX设计追求的是"好用、好看、让人喜欢"，可用性工程追求的是"安全、不出错、即便在最差的使用条件下也能控制风险"。核查老师关注的不是你的界面好不好看，而是你的界面在紧急情况下会不会导致使用错误。
坑二：用户测试只找内部员工。
形成性评价和总结性评价的测试对象必须是"有代表性的目标用户"——即实际使用产品的那类人。找公司内部的工程师做测试，结果会严重偏差（因为工程师太懂产品了，测试不出真实用户会犯的错误）。NMPA指导原则要求高使用风险产品的总结性评价，每个用户组至少15名参与者。
坑三：可用性工程文件和其他文件"各说各话"。
我见过很多企业，可用性工程报告里写的用户界面要求和设计输出文件里的界面设计不一致，和说明书的操作步骤也对不上。这在核查时是大忌——文件之间必须一致。建议在项目一开始就建立"可用性要求追溯矩阵"，确保从输入到输出到验证到说明书，所有文件对同一要求的描述完全一致。
图：NMPA使用风险等级分类与可用性工程要求（2024指导原则）
搞懂可用性工程，不只是为了应付NMPA的新要求。
它背后是一套思维方式：产品设计不能只关注"功能是否实现"，还要关注"用户能否安全、正确地使用"。一个好的医疗器械，功能再强大，如果用户用错了导致伤害，就是失败的设计。
IEC 62366给了你一个框架，告诉你从哪几个维度去分析、用什么方法去验证。但真正的核心只有一个：站在用户的角度想问题。
做菜的人要站在吃菜的人的角度想问题，做医疗器械的人要站在用医疗器械的人的角度想问题。这个道理，古今中外都一样。
觉得有用？转发给你那些设计输入里还没有"可用性要求"的同事，帮他少收一份发补意见。
医械加油站将持续为医械人分享医疗器械行业快讯、法规标准解读、文件模板、培训课件及设计开发相关产品资讯，助力行业同仁合规提速、少走弯路，欢迎持续关注！
📋 医械加油站持续更新新版GMP核查专栏系列全景规划，覆盖GMP核查从框架认知到模块拆解、从文件编写到问题整改、从内审应答到供应商管理的完整链路，欢迎持续关注！