用户习惯和用户认知是一个很神奇且值得敬畏的东西。
用户需要的不是更好的解决方案，而是一个符合自己习惯和认知的现有方案。
用户很难告诉你他想要什么，但会告诉你他不要什么。
用户会设想很多解决方案，产品经理别把方案当需求。
上周，微信公众号发布了一个更新，支持作者和读者的多轮留言回复，我还专门写过一篇文章聊过。
上手新版后我就发现有一个用户习惯的改变，并觉得这一定会对很多公众号作者的已有习惯造成冲击。
果不其然。
先看下新版在用户端的效果，也就是公众号文章底部留言区的效果。
再看下作者后台的效果，也就是公众号后台或订阅号助手 App 的效果。
星星被点亮绿色的代表设置成了精选，也就是会在前台文章底部出现的，没点亮的在前台无法看到。
按照新版的用户操作路径，从作者角度包括以下几步：
1、收到读者留言；
2、回复读者留言；
3、设置留言精选或者回复精选；
4、收到读者二次回复或作者进行二次回复；
与老版相比，用户习惯差异最大的是第 3 步，读者留言和作者回复需要分别设置精选。
而在老版上的用户操作路径，从作者角度看包括以下几步：
1、收到读者留言；
2、回复读者留言；
3、设置留言精选；
作者只需要设置读者留言为精选，自己回复的内容就会默认一起被设置为精选上墙。
那么问题就来了。
因为新增了留言多轮回复，所以微信团队将读者留言和作者回复的精选关联给取消了。
改成了留言和回复分别独立精选。
这次产品升级，改变了原有用户习惯，我在内侧群就看到了有好几个用户反馈觉得很不爽。
曲面屏那个真把我逗笑了。
不知道微信团队在设计订阅号助手 App 时有没有考虑到这一点，确实很尴尬。
而且作者明明回复了，按照之前的习惯以为都上墙了，结果只把读者留言上墙。
对于回复喷子的作者，实名打脸尴尬。
说实话，我自己在使用新版的初期也遇到了这个问题。
习惯性的设置读者留言为精选，但忘记把自己的回复也设置为精选。
后来进入前台文章底部看才反应过来，然后又跑到后台去给回复也设置精选。
多操作几次以后，就发现了窍门。
其实直接把自己的回复设置为精选就可以了，因为这样会默认把关联的读者留言也设置为精选，同样是一步操作。
比如将第二条回复设置精选后，读者的留言就会自动设置成精选（小星星点亮）。
区别就是，需要和老版中的原有用户习惯进行逻辑倒挂。
多适应几次就能习惯。
群里也有用户提出了自己的解决方案。
我敢打赌，给方案的这个用户肯定不是产品经理。
场景需求上，作者确实会有不上墙的回复需求。
比如一个读者留言，我回复几个回合后， 其中有一条回复涉及敏感或隐私信息，那我就不会设置精选。
产品方案上，这显然不是技术限制，而是一个产品规则和交互方案设计。
如果默认给回复上墙，那就和前面提到的场景需求相冲突了，而且这种后向取消的逻辑对作者着实不友好。
就好像先扔出去一个雷，然后又跑出去捡回来掐灭，说不好刚跑出去就炸了（比如被截屏）。
其实也不是没有办法，这里斗胆提出一个思路。
作者在后台回复留言时，在留言输入框右侧添加一个设置精选的按钮（默认不选中），其他设计不变。
作者在输入完回复内容后如果觉得要精选，就可以可以快捷选中（图示以 iOS 版订阅号助手为原型）。
相比回复完成后再去单独设置精选，这种方式在操作连贯性上会显得更顺滑一点。
此外，还能起到视觉提示的作用。
如果按这个优化，用户操作路径就变成了：
1、收到读者留言；
2、回复读者留言、选择是否设置精选（设置则留言和回复自动上墙）；
3、收到读者二次回复或作者进行二次回复；
其实这对原有方案没有任何改变，只是在交互路径上新增了一个操作。
当然，相信微信团队一定能给出更优雅的解决方案。
话说回来，任何一次产品升级都会带来一些连带效应，可能是对用户习惯的改变，可能是对用户认知的颠覆。
微信这次改变，可能部分用户觉得自己被「坑惨」了。
其实从长期价值看，我认为这是一次积极的改变，只是需要一段时间的适应而已。
回到最开始的话。
用户习惯和用户认知是一个很神奇且值得敬畏的东西。
用户需要的不是更好的解决方案，而是一个符合自己习惯和认知的现有方案。
用户不会告诉你他想要什么，但会告诉你他不要什么。
用户会设想很多解决方案，产品经理别把方案当需求。
最后，我说的也不一定是对的！
··················END··················
你好，我是唐韧！前非著名程序员，现不知名产品人。
写过代码、做过产品、出过一本书，在创业公司厮杀过，也在大厂服役过，如今是一个自由职业者。
爱跑步、喜欢车、主要跟文字打交道，在这里记录自己想表达的一切！
