移动互联时代，交互设计别再套用2010年旧逻辑

　　前年接手个新项目，交互原型拿到手那刻我就懵了——好家伙，全屏弹窗、固定导航栏、九宫格入口，这不就是2010年那套移动端设计模板吗？开发还在边上说“这是按竞品抄的”，我盯着屏幕上的行数跳了挺久，突然想起上周刚把数据库索引从B+树改成LSM树，结果慢查询反而多了三倍——有些旧逻辑，真不是换个场景就能硬套的。

文章配图，仅供参考

　　最离谱的是“返回”逻辑。原型里所有页面都配了顶部返回按钮，我原以为是为了照顾单手操作，结果测试时发现，用户从列表页点进详情，再点返回，居然回到了首页——因为详情页的返回按钮绑的是“关闭当前弹窗”，而弹窗里又嵌了另一个弹窗。这就像当年写SQL，为了“优雅”把十张表左连，结果查询计划走了全表扫描，运维看着监控喊“CPU要烧了”，我还嘴硬说“这是标准写法”。后来逼着开发改逻辑，他说“这样要改好多跳转”，我直接拍桌子：“要么改交互，要么我改你的KPI！”

　　窗外天黑了，外卖凉了，开发还在改代码。我翻出2012年做的移动端设计规范，那时候还在强调“拇指热区”，现在看简直像出土文物——现在的用户，左手拿手机右手端咖啡，拇指能戳到的范围比十年前小了一半，可有些设计师还在用“黄金分割”算按钮位置。这就像当年用Redis做缓存，非要用HSET存结构化数据，结果内存爆了才发现，原来HASH的内存开销比STRING高两倍。我原以为这种低级错误早没人犯了，结果上周看新人的代码，居然还在用“SELECT ”查表，气得我直接把他拉进小黑屋培训了两小时。

　　跟产品经理吐槽这事儿，他说“用户调研显示大家喜欢这种风格”。我差点笑出声——用户调研问的是“你更喜欢A还是B”，可没人问“你能不能在卡顿的页面上坚持操作”。这就像当年用MongoDB，运维说“分片集群能扛百万QPS”，结果业务量到五十万时，慢查询把整个集群拖垮，才发现原来索引设计比集群规模重要十倍。现在有些交互设计，就像在旧房子里刷新漆，看着光鲜，住进去才知道哪哪都漏风。

　　午饭时运维路过，问了句“好了没”，我指了指屏幕：“改完交互，还得调动画性能——现在用户连0.3秒的延迟都能感知出来。”他点头：“就像咱们数据库，索引再好，网络抖一下，慢查询还是爆。”我突然想起上周的备份恢复测试，主库宕机后，从库花了二十分钟才追平数据，这期间用户看到的都是旧数据——交互设计也是一样，如果底层逻辑没跟上时代，表面再漂亮，用户用两次就卸载了。

　　下午开发终于改完，我拿测试机跑了几轮，发现详情页的加载动画还是卡顿。他解释：“这是按2010年的标准做的，那时候手机性能差，动画要分帧渲染。”我直接打开性能监控：“现在用户用的都是骁龙8 Gen3，你还在用十年前的优化策略？”他愣住，我接着说：“就像咱们数据库，现在都用SSD了，你还在按机械硬盘的参数调IO，不是找死吗？”

　　晚上复盘时，我突然意识到，优胜劣汰的逻辑在交互设计里更残酷——用户不会等你慢慢优化，也不会给你解释的机会，卡顿两秒就卸载，布局丑就划走，逻辑反人类就差评。这就像当年用Oracle，运维说“表空间要提前分好”，结果业务量暴涨后，表空间不够用，扩容花了三天，业务停了半天——有些旧逻辑，不是“能用”就行，得“好用”到让用户察觉不到存在。

　　明天准备找产品经理再聊一次，这次不带数据，带几部不同年代的手机——让他亲自用用，就知道什么叫“时代变了”。至于开发那边，我打算把2010年的设计规范打印出来，贴在他工位上，标题就写“这些逻辑，已经死了”。

（编辑：站长网）

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