B2B：主导基于风险的 UX + 可用性工程，减少分子检测中的实验室使用错误

我的职责（双轨交付）

轨道 A 改进操作员工作流程（产品 UI/UX）

识别最要紧的关键任务和错误情形（风险 + 频率）。

重新设计交互点，以预防错误、减少歧义并简化恢复路径。

轨道 B：构建可用性工程证据体系（运营结构）

定义一套一致的方式来记录问题、评定严重度、把发现与风险控制关联起来，并在无需返工的情况下产出符合审计要求的输出。

线框与原型设计（如何设计的）

低保真线框聚焦于：

设置流程的清晰度（下一步是什么、需要什么、缺了什么）。

预防性约束（阻断状态 vs 警告状态）。

恢复体验（如何安全、快速地重新开始）。

交互式原型用于验证：

设置流程的耗时以及回退操作的减少。

在压力下对警报的理解。

操作员无需外部帮助便能从被中断的运行中恢复的成功率。

交付物（有形产出）

产品设计产出

操作员流程图（顺利路径 + 失效模式）

针对校验闸门、确认和恢复的 UI 行为规格

警报内容指南 + 组件规则（由严重度驱动）

用于形成性测试的可点击原型

可用性工程证据产出（符合审计要求）

任务分析（关键任务、潜在错误、严重度依据）

与使用相关的风险可追溯性（把发现 → 缓解措施 → 验证串联起来）

形成性研究计划 + 脚本 + 成功标准

为工程行动 + 合规可追溯性而组织的问题记录

总结性就绪清单（需要哪些证据、缺了什么）

背景与问题陈述

QIAsymphony 处于高风险环境：临床和科研实验室在严格的 SOP 下运行时间敏感的工作流程。微小的交互失误就可能级联成运行失败、结果延迟、耗材浪费或合规风险。

在操作员体验中观察到的核心问题

设置易出错：耗材/试剂装载错误、试剂盒选错、样本/试管架放置错误、遗漏预检。

“预防”设计薄弱：UI 往往在事后报告错误，而不是在事前加以预防。

恢复复杂：当运行失败或暂停时，操作员在不高度依赖手册或资深人员的情况下，难以准确判断下一步该做什么。

文档负担：可用性发现并不总是以一种便于在审计时轻松追溯到风险控制和设计决策的方式加以组织。

用户研究与洞察（我做了什么）

对操作员进行情境调查（设置、运行执行、中断、清理）。

对端到端工作流程进行任务分析（正常 + 边界情形）。

对照公认的可用性原则 + 安全关键 UI 惯例进行启发式评估。

与具代表性的操作员开展形成性可用性测试，采用真实场景并注入失效。

塑造解决方案的关键洞察

操作员不会“探索”UI——他们在时间压力下执行 SOP。UI 必须表现得像一份带护栏的清单。

代价最高的失败来自一小组可重复的失误（试剂盒选择、耗材放置、运行确认）。

“错误代码”还不够——操作员需要通俗语言的原因 + 确切的恢复步骤。

可用性证据最难的不是创建，而是在多次迭代中保持其可追溯性。

影响指标与成果

由于预防优先的校验，与设置相关的偏差减少了。

由于一致的模式 + 引导式设置，操作员上手更快。

由于可执行的恢复指引，运行中断时间缩短了。

由于可用性产出在设计上即可追溯、而非事后重建，审计阻力更低。

这为何重要

QIAsymphony 不是一个“好看 UI”的问题。它是受监管环境中的人的可靠性问题。这项工作交付了两件在现实中真正重要的东西：

一个更安全、更抗错的操作员工作流程与用户界面设计，以及

一套可重复的可用性工程证据体系，能够跨版本扩展，并在审计中经得起检验。