去年冬天在济南一个老旧小区做现场调研，我看到的一幕让我至今难忘。
零下八度，一位七十来岁的阿姨被新门禁挡在单元门口。她对着屏幕反复抬头、低头、凑近、后退，折腾了将近十分钟，人脸识别始终失败。她从兜里摸出一张旧IC卡往上贴，没反应——那台门禁早已取消了刷卡模块。最后是邻居从里面开门，她才回得了家。
作为技术人，那一刻我脸上发烫。因为这种“只认脸”的门禁，恰恰是行业过去几年追逐的技术方向。而今天我想聊的，正是这种设计背后的产品陷阱：强制智能。
什么是强制智能？
强制智能，指的是在交互设计中，取消用户的选择权，强制使用唯一的技术路径。具体到门禁产品，就是砍掉IC卡槽、密码键盘，只保留人脸识别或手机扫码，美其名曰“无感通行”。
这种设计在产品经理圈子里并不少见。我们往往陷入一个误区：把“技术先进”等同于“体验好”，把“功能精简”包装成“极简设计”。但当你的用户画像只覆盖了20-40岁的数码原住民，那些沉默的长尾用户——尤其是老年人——就被系统性地抛弃了。
人脸识别在老旧小区的失败模型
从技术角度拆一下人脸识别在老旧小区场景下的失败原因：
- 输入层：皱纹导致面部特征点偏移，驼背引起身高和角度变化，注册时的面部数据与实时采集的数据偏差显著。
- 环境层：室外强光、逆光、冬季呼出的白雾，对RGB和红外摄像头均有干扰。
- 交互层：老年人对“抬头”“眨眼”等动作指令的理解和执行效率，远低于年轻人。
实测数据也很直接：冬季室外，65岁以上用户的首次识别通过率，比25-35岁用户低约三倍。这不是个例，是单模态生物识别在特定人群中的系统性局限。
当一个产品只提供单一生物识别方式，而又覆盖了高失败率人群时，这就不是体验问题，是可用性问题。
两种适老化路径：教育用户 vs 优化系统
行业现在有两种解法。
第一种是用户教育：开培训班教老人用手机，做图文教程，上门指导。思路很简单——用户不会用，就教会他。
但社区给我的反馈很现实：“教一遍，过两天又忘了。不是不想学，是记不住。”从认知心理学角度看，这涉及工作记忆随年龄衰退的问题，属于不可逆的生理因素。把系统问题转嫁为用户的学习责任，本质上是一种设计惰性。
第二种是系统优化：在架构层面保留多模态交互，提供低认知负荷的保底方案。
我们在新门禁的架构设计里明确了一个原则：开门方式必须保留五种——IC卡刷卡、固定密码、人脸识别、手机远程、临时密码。其中IC卡读卡器作为物理模块，不因人脸算法升级而取消。
技术冗余：一个成本很低、价值很高的保底方案
团队内部曾有过争论：保留刷卡模块，单机会增加一些物料成本。但最后我们算的是另一笔账——这笔成本买来的是什么？
- 老人出门的体面：不用在邻居面前一遍遍被提示“识别失败”
- 独居老人的独立：不用每次出门都惦记着喊人帮忙
- 子女的安心：知道爸妈不会被一扇“智能门”锁在寒风里
从产品价值角度看，这是成本最低的用户体验保险。
而且IC卡作为离线认证方式，不依赖网络、不依赖服务端，在断网、服务器故障等极端场景下是最可靠的保底方案。这一点对于单元门禁这种高可用性要求的设备来说，尤为重要。
数据说话：那三分之一被“静音”的用户
去年在济南一个老龄化街道的旧改中，我们5天交付了144台设备。居委会验收时提的唯一硬指标是：必须保留刷卡，小区60岁以上老人占41%。
上线三个月后的后台数据：
- 人脸识别使用占比：约50%
- IC卡刷卡使用占比：超过33%
- 其余为密码、远程开门和临时密码
三分之一以上的用户选择了那个被很多同行砍掉的刷卡方式。这些人，就是在需求评审阶段最容易变成沉默用户的人。如果你不做专门的高龄用户画像，他们永远不会出现在你的NPS调研里，但他们会在每一个零下八度的傍晚，被你的产品挡在门外。
落地技术伦理，靠的是具体原则
技术伦理不是口号。在我们团队，它被落地成三条具体的设计原则：
- 多模态优先于单模态。 任何涉及物理通行的交互，不能只有一种方式。给人脸，也要给卡片和密码。
- 离线优先于在线。 卡片和密码不依赖网络，是极端情况下的最终保底。
- 低认知负荷优先于高体验感。 对高龄用户，“记得掏卡”比“理解人脸识别交互流程”容易太多。真正好的交互，是让用户感觉不到交互的存在。
数字化进步的列车跑得很快。但衡量好技术的标准，从来不是它跑得有多快，而是它愿不愿意在每一站，等一等那些走得慢的人。
写在最后
做产品越久，越觉得一个道理朴素但容易被忽略：一扇好门，不赶人。
当你设计的产品可能覆盖老人、小孩、残障人士等多样化人群时，请一定记得在系统里留一个“不智能”但靠谱的保底方案。这不是技术退步，这是产品经理的基本良心。
如果你也在做智慧社区、IoT或适老化相关的产品，欢迎在评论区聊聊，你们是怎么处理这种“技术先进”和“用户包容”之间的矛盾的。
本文由作者基于一线产品实践撰写，观点仅代表个人。
#产品设计 #交互设计 #适老化 #智慧社区 #技术伦理 #IoT #技术冗余
