交互设计：以技术为盾，守牢体验每一处防线

文章配图，仅供参考

　　当时我第一反应是骂人——这帮开发，每次都说“测过了”，结果证书过期时间算错了，他们居然用本地时间算的，没考虑时区！但骂归骂，手不能停，我赶紧切到证书管理页面，结果发现更离谱的事：证书文件权限被改了，原本644的权限，现在成了400，连nginx都读不了！我一边改权限一边想，这特么谁干的？后来查日志才发现，是前一天安全组扫漏洞，自动修复工具把所有证书文件权限都锁死了——那工具还是他们自己写的，号称“智能修复”，结果修复了个寂寞。

　　其实最让我后怕的，不是证书过期，是整个交互设计的问题。你想啊，证书过期前一周，系统明明有提醒，但提醒的方式是——邮件！谁天天看邮件啊？尤其是运维，邮箱里全是告警、工单、垃圾信息，真正重要的提醒早被淹没了。更绝的是，证书管理页面连个“过期倒计时”都没有，只有个“有效期至”的日期，还得自己算还剩几天——我原以为这种基础功能不会有坑，结果它还真就坑了你。

　　那晚我改完权限，重新加载证书，业务线总算恢复了，但开发那边开始甩锅，说“我们没收到提醒”“权限问题不是我们的责任”。我直接怼回去：“提醒方式是你们定的，权限管理也是你们写的，现在出事了怪谁？”他们不说话了，但我知道，这事儿没完——第二天早上，我翻出之前的交互设计文档，发现证书管理的页面，居然是三年前一个实习生做的，当时为了“快速上线”，连基本的交互规范都没遵循，比如错误提示用红色但没加感叹号，比如操作按钮放在页面最底下，得滚半天才能看到——这些细节，平时看着不起眼，关键时刻能要命。

　　其实运维干久了，对这种“小问题”都麻木了。比如磁盘满了，告警阈值设得太高，等收到通知时，磁盘已经撑爆；比如备份脚本，日志写得很详细，但没人看，结果备份文件损坏，恢复时才发现；再比如迁移数据，界面上显示“迁移成功”，但实际只传了一半，剩下的全卡在中间件里——这些坑，哪个不是交互设计的问题？可开发总说“这是技术问题，不是交互问题”，我呸！技术问题归根结底是人的问题，而交互设计，就是帮人少犯错的盾牌。

　　那天下午，我跟开发吵了一架，他们坚持说“用户（也就是我们运维）应该自己注意”，我直接拍桌子：“用户注意？用户要是有这精力，还要你们开发干嘛？你们把界面做得像迷宫，把提醒藏得像彩蛋，出了事就怪用户没发现？”他们不说话了，但我知道，他们心里还是不服——直到我翻出另一组数据：同样的问题，在另一个业务线，因为交互设计做得好，证书过期前三天就弹窗提醒，权限变更会触发二次确认，结果那业务线三年没出过类似事故。优胜劣汰，就是这么残酷。

　　其实那晚我还干了件蠢事——改完证书后，我没做回滚测试。我当时想，反正已经恢复了，测试浪费时间。结果第二天，开发说“有个接口调用失败”，我一查，发现是证书权限改完后，某个旧版本的客户端不兼容，只能又把权限调回去——这事儿要是发生在生产环境，又得是一场事故。我后来想，这就是交互设计的另一个问题：它不仅影响用户操作，还影响用户对系统的信任——你老出问题，用户就会觉得“这系统不靠谱”，哪怕问题不是你造成的，但锅总得有人背。

　　窗外天快亮了，我泡了碗面，没吃完就凉了。手机又响了，是另一个业务的告警——这次是磁盘IO高，但监控页面上，IO曲线和CPU曲线挤在一起，根本看不清哪个是哪个。我叹了口气，心想：这交互设计，到底什么时候能真正“以技术为盾”啊？

　　下一步我打算补个交互设计规范，把所有运维相关的页面、工具、提醒都梳理一遍，该加弹窗的加弹窗，该改颜色的改颜色，该做倒计时的做倒计时——我知道开发会嫌麻烦，但总比出了事再补锅强。其实这事儿本来能避免，如果三年前那个实习生做证书管理页面时，能多想想“用户会不会漏看提醒”“操作会不会出错”，如果安全组的修复工具能多测几种场景，如果……算了，没有如果，只有现在。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!