第1章：可用性工程：IEC 62366在智能药盒交互设计中的实践

大家好，我是你们的老朋友。今天咱们聊聊智能药盒的可用性工程。说白了，就是怎么让用户不犯错，或者犯了错也能安全地纠正过来。

我做了十几年医疗器械，见过太多因为交互设计翻车的案例。有个项目我印象特别深——药盒的按键太小，老人戴着手套按不准，结果剂量全乱了。嗯，从那以后，我对IEC 62366的敬畏心就上来了。

1.1 为什么IEC 62366这么重要？

你想想看，智能药盒不是普通消费电子。它管的是人命。用户可能是视力不好的老人，也可能是手抖的患者。如果设计时没考虑这些，出事了就是严重事故。

IEC 62366的核心就一句话：把用户可能犯的错误，在设计阶段就扼杀掉。我个人习惯把这个标准拆成三步走：

• 第一步：识别用户——谁在用？老人？护士？还是患者自己？
• 第二步：分析任务——用户每一步操作是什么？哪里容易出错？
• 第三步：验证改进——找真实用户测试，看他们会不会按错。

1.2 用户错误预防的实战技巧

我在项目中遇到过最典型的错误，就是用户把药盒的「确认」键和「取消」键搞混。你想想看，一个老人眼神不好，两个键挨着，按错太正常了。

怎么防？我建议用这几个方法：

1. 物理隔离——关键按键之间留足间距，至少10mm以上。
2. 触觉反馈——「确认」键做成凸起的，「取消」键做成凹陷的。闭着眼睛都能摸出来。
3. 颜色编码——红色代表危险操作（比如取消服药），绿色代表安全操作（比如确认）。
4. 二次确认——任何修改剂量的操作，必须弹窗让用户再确认一次。

1.3 可用性验证怎么做？

验证不是走过场。我见过太多团队，找几个同事按两下就说「没问题」。这不行。

真正的验证要满足IEC 62366的要求，至少包括：

验证项目	具体要求	我踩过的坑
用户代表	至少5名目标用户（老人、患者等）	曾经只找了年轻人测试，结果老人根本看不清屏幕
任务覆盖	覆盖所有关键操作（取药、设置、报警处理）	漏测了「更换电池」这个操作，结果用户把电池装反了
错误记录	记录每个用户犯的错误类型和次数	一开始没记录，后来改设计时根本不知道问题在哪
改进闭环	发现问题后必须修改设计，再测一轮	曾经改完设计没复测，结果新问题更严重

1.4 一个真实的避坑案例

我曾经负责过一个智能药盒项目。设计时觉得「语音提示」很酷，就加了个功能：每次到点吃药，药盒会喊「请取药」。结果呢？

用户反馈说：半夜被药盒喊醒，吓出心脏病。而且语音内容太模糊，用户不知道要取哪个药仓的药。

后来怎么改的？

• 把语音改成「滴滴」声，不吓人
• 对应药仓的LED灯闪烁，告诉用户「就是这个」
• 加了个「静音模式」，晚上不打扰睡眠

你看，一个看似简单的功能，如果不做可用性测试，就会出大问题。

1.5 总结一下

IEC 62366不是束缚你的枷锁，而是保护你和用户的铠甲。我个人的经验是：

• 设计阶段多花1小时做用户分析，能省下后期100小时的返工
• 可用性测试要找真实用户，别找同事凑数
• 用户犯的每一个错误，都是设计改进的机会

下一章，咱们聊聊智能药盒的软件生命周期管理。到时候我会分享一个因为版本管理混乱，导致药盒「失忆」的惨痛案例。敬请期待。