昨天有一个问题很典型。
用户扫了微信二维码，微信那边看起来已经成功了，但网页没有跳。
如果我是用户，我不会知道什么父页面、回调页、消息监听。我只会觉得，我明明扫完了，为什么网页还停在这里？
这个感觉很糟。
因为登录是进入产品的第一道门。第一道门如果不稳，后面的功能再好，用户也很难放心。
扫码登录应该像开门一样
扫码登录在用户心里是一个非常明确的动作。
我拿手机扫一下。
我确认。
网页进入我的登录身份。
这条路径应该像开门一样自然。
如果门开到一半卡住，用户不会去研究门锁结构。他只会怀疑这扇门是不是坏了。
所以我昨天没有急着加一个跳转。
因为如果没有搞清楚哪一步断了，直接跳转可能只是把问题藏起来。用户看起来进去了，但登录态未必真的保存好了，后面还会出现更多问题。
链路要一段一段看
扫码登录背后至少有几段。
二维码要正常出现。
微信确认要成功。
回调页面要把结果告诉网页。
网页要识别这个结果。
登录状态要保存。
后面页面才应该跳转。
任何一段断掉，用户看到的都是「不动」。
所以排查这类问题，要一段一段看，而不是只盯着后面的跳转。
这对用户的好处，是修复会更稳。
不是今天强行跳过去，明天又在另一个地方掉登录。而是把整条链路接清楚，让用户扫完以后真的进入自己的登录身份。
兜底很重要
真实世界里，浏览器环境很复杂。
有时候回调消息可能没到，有时候页面监听可能错过，有时候状态已经生成但前端没及时拿到。
所以我更倾向于做双保险。
一边接收扫码回调，一边主动检查登录状态。
这样用户扫完以后，即使某一条通知链路没有那么顺，页面也还有机会确认他是不是已经登录成功。
对用户来说，这就是确定感。
他不用反复扫码，不用刷新页面，不用怀疑自己操作错了。
日志不是给工程师看的
表面上日志是工程师看的。
但从用户体验角度，日志其实也是服务用户的。
因为有日志，问题才能更快定位。没有日志，用户说一句「我扫了没跳」，我们只能猜。
有了关键日志，就能知道二维码有没有生成，回调有没有发生，网页有没有收到，登录状态有没有保存。
定位越快，用户等待越少。
登录稳定就是信任稳定
登录不是一个小入口。
它连接着会员、书架、反馈、个人记录和跨端同步。
如果登录不稳，用户就不会愿意把数据交给产品。因为他会担心，下次还能不能进来，换设备还能不能找回，付费权益会不会识别。
所以昨天这件事给我的提醒很直接。
扫码登录的价值，不只是让用户少输入登录信息。
它真正要做到的是，让用户感觉到，这个产品认得我，也能稳定地带我回到我的数据里。
回到用户这边
我现在越来越愿意用一个很简单的标准看产品改动。
用户下一次打开时，会不会少一点犹豫。
如果答案是会，那这个改动就值得做。
少一点犹豫，听起来很小，但它会改变很多东西。用户不用猜按钮含义，不用担心状态混乱，不用反复确认自己有没有操作成功，也不用在遇到问题时组织一大段说明。
这些小地方一旦顺了，用户就会更愿意继续往下用。
产品不是靠一次大改建立信任的。
它更多时候是靠每一个细节慢慢积累。今天登录更稳一点，明天反馈更顺一点，后天页面更清楚一点。用户不会专门夸每一个细节，但他会在心里形成一个判断，这个产品是有人认真维护的。
这就是长期收益。
它让产品从一个能用的工具，慢慢变成一个让人愿意反复打开的地方。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。
作者，剑飞，本文是一篇昨日产品体验复盘。