B2B：为 ICU 监护仪设计一项新的临床参数：RFP 界面、安全场景与风险就绪文档

用户研究与洞察

我先把假设和事实分开。来自利益相关者的早期记录方向大致正确，但措辞不一致（例如“误差 %”与“rpm 精度”，以及“age values”与“H values”）。我把措辞收敛为能通过正式评审的版本：过期数值、以 rpm 表示的精度，以及与标准 Delta 行为一致的平台警报继承。

接着，我梳理出哪些内容绝不能重复。SpO₂ 已经涵盖了物理工作流程——选择传感器、佩戴传感器、连接线缆、确认数值——所以为 RFP 再造一整套只会制造噪音，并稀释安全评审。相反，我把 RFP 的范围收敛为一组最小的、与安全相关且尚未被覆盖的独特 UI 行为。

在起草这些场景时，我标记出那些会破坏场景有效性以及后续 UFMEA 质量的确切 UI 不确定之处：

选择新生儿时究竟会发生什么（对话框、禁用状态、自动关闭、反馈）？

RFP 究竟在哪里切换开/关（参数菜单、侧边栏开关、上下文菜单），成人/儿童的默认开启又如何呈现？

界面如何让人毫不含糊地看出当前处于活动状态的是哪个呼吸来源（ECG 还是脉搏波派生），尤其是在两者都可用时？

为解决这一设计依赖，我准备了有针对性的利益相关者问题（面向 UI 架构师/领域专家），严格聚焦于可观察的行为，而非实现细节，好让这些场景在评审中站得住脚。

概念化

基于用户研究，我们把 ICU Angel 构想为一个统一界面，它能够：

用算法图表追踪 ARDS 的进展。

在出现任何关键变化时实时向医护人员发出警报。

与现有医院系统无缝集成，自动填充患者数据。

线框设计

我们绘制了低保真草图，勾勒出：

分阶段可视化：每个 ARDS 阶段（高危、重度等）都用颜色编码，便于快速识别。

警报管理：一套分层系统，将紧急警报置于最前，尽量减少警报疲劳。

用药追踪：一个专门区域，用于查看给药时间和剂量。

原型制作与用户反馈循环

接着，我开发了交互式原型来模拟核心工作流程，从入院、用药排程到实时生命体征监测。

动手测试：ICU 人员和主要研究者在结构化的场次中测试了这些原型。

关键反馈：医生希望有可自定义的警报阈值，护士要求更简单的数据录入表单，IT 人员则主张要有稳健的数据安全框架。

背景与问题陈述

Philips 当时正在引入或改进一些在临床上有意义、但在 ICU 环境下极易误用的能力：

用户在被打断、警报疲劳、认知负荷和时间压力之下操作。

新参数（如 RFP）在技术上或许“属于 SpO₂ 的一部分”，但仍会引入新的 UI 行为和新的失效模式（例如首个数值的延迟、新生儿限制、共享警报限值行为）。

对于 ContTemp 智能线缆工作流程，风险包括选错配件、设置不当，以及在断开/丢弃时的感染控制失误。

缺口不在于“缺少界面”。缺口在于缺少操作上的清晰度：

用户要做什么、看到什么、决定什么、核实什么——而这些又可能在哪里出错？

我坚持的设计决策

继承边界：物理设置留在 SpO₂ 场景之下；RFP 场景只从传感器链路已连接之后才开始。

预期管理：允许 RFP 稍后才出现；场景明确地把延迟出现视为正常，而非错误。

过期数值的措辞：正式使用“过期数值”一词（已知存续时间、仍在显示的数值）。

警报对齐：默认报警行为（包括限值）继承自标准的 Delta 报警；RFP 不引入单独的“报警系统”。

新生儿限制是一条安全边界：该锁定必须在 UI 中显式呈现，而非一条隐藏规则。

成果

这项工作把一个“算法附加功能”变成了一份可评审的交互设计，并带有明确的安全边界。相较于抽象地争论 RFP 和 delta 设备附加，利益相关者现在能够验证：

临床医生看到什么、何时看到，以及系统期望他们做什么

新生儿限制以一种可测试的方式如何强制执行

RFP 如何融入既有的警报和呼吸来源行为，而不制造相互矛盾的 UI 状态

设计了 14 个以上的场景，覆盖将附加设备在床旁监护仪之间来回接入的情形，消除数据丢失、患者风险和管理问题的隐患。