编辑导语：当发现产品可能出现“bug”时，产品经理需要从多方面思考问题出现的背后原因、解决方法，以及可能的迭代方案是什么，由此，才能实现更好的产品优化与自我提升。本篇文章里，作者结合微信设置朋友圈“不给谁看”时发现的问题做了思考，一起来看一下。

01

话说周末，镜同学躺在床上，吹着空调，正在峡谷游走，一不小心就用云樱打出来个三杀。

对我来说，这可是有史以来第一次啊，朋友们，我也想低调，也想猥琐发育，也不想浪，可奈何实力不允许啊。

俗话说，独乐乐不如众乐乐，众乐乐不如朋友圈。那咱得赶紧分享战绩，分享到朋友圈去，哼，尤其镜同学要让二傻子看看，我云樱又回来啦。

就在我点击确认的一瞬间，我突然意识到，不能暴露我方坐标啊，毕竟虽然咱无比崇敬的领导对咱本人没有误解，但却对王者荣耀有深深的偏见呐，于是，咱就想把领导屏蔽一下。

于是就出现了下图：

我一看，哟，这是咱上次总结二傻子和领导的相同的优点，在发朋友圈时，屏蔽了二傻子和领导们，选择了领导们和二傻子不可见（排列纯属巧合，请勿深度解读～）。

这次虽然还得屏蔽我亲爱的领导们，但我得把二傻子的屏蔽给取消掉啊。

不得不承认，微信作为国民级应用，张小龙作为国内产品经理的教父般的领袖，江湖地位那不是吹的，你看，直接将你上次选择屏蔽的给你带出来了，只需要把二傻子取消掉就好了，多方便。

于是，我点击“上次分组”：

接着，我点开“不给谁看”：

咱接着，点击从通讯录选择，就在点开“二傻子”时，惊奇的发现，点击头像还可以移除，选择好友又可以添加，多贴心呀。

可是，当不选择好友时，“完成”按钮竟然不可点击，也就是说，你可以替换好友，但不能取消已经屏蔽的某个好友：

↑- 有好友选择时，“确认”按钮可以点击

↑- 没有好友选择时，“确认”按钮灰色不可以点击

这一刻，咱激动的就要跳起来了，我发现了微信的一个BUG，我要告诉张小龙。

微信内容我都编好了：

当发送朋友圈且设置“不给谁看”时，若上次选择的有某个好友和标签，本次通过“上次分组”入口，在通讯录里，无法删除掉已屏蔽的某个好友。

哇，哇哇，这特么可是个大事呀，我抓起手机就要找小青蛙?头像，要是别人，肯定就抓起手机发送信息了，可咱镜同学是谁？那是茅坑拉屎脸朝外的汉子，咱走南闯北，啥大风大浪没见过？咱在九个县当过县长，别着急，稳住，我们能赢，先看看有没有解决方案呢？

找了老半天，正当镜同学就要绝望时，我终于发现了解决方案：

先点击一下“部分可见”，再点击“不给谁看”，就将上次的数据清空了，就可以重新选择了。

但这样体验并不好啊，直接在好友为空的时候，可以确认不就行了吗？

02

作为一个十八线城市的优秀高级产品助理，镜同学脑子里有很多问号，咱必须要问个为什么？

当我从产品角度分析时，奇怪的事情发生了。

1. 通讯录与标签的区别是什么？

首先，要清楚从通讯录选择某个好友和通过用户标签选择的联系与区别，从通讯录选择的一个好友和标签选择的一类好友，本质上都是选择的用户。

实际上，用户标签也相当于是分组，是对用户的标记，也就是说，从通讯录选择或者通过标签选择，都是对用户的筛选，不同类型的入口而已。这也解释了，如果你从通讯录选择的是A，从标签分组里选择的也包括A，并没有任何影响，因为都是对用户的筛选。

2. 上次分组的同步逻辑是什么呢？

上次分组实际上只是对筛选后的用户数据做的记录，通讯录只是一个入口，标签也是用户分组的入口，本质上都是同步的标记后的用户数据。

3. 那为什么好友为空时，不可点击确认？

镜同学仔细想了下，从我浅薄的产品知识来看，首先，第一次从通讯录入口，去选择某个好友不可看时的逻辑为：

选择头像代表选中某个好友，点击完成则记录选中的用户ID，进行用户标记筛选，而且，如果为空，则认为没有选中好友，则不显示“完成”按钮，只有通过返回按钮回到上级页面。微信应该是这样定义的：既然点从通讯录选择了，多少不得选择一个，你一个都不选择，那就点击左上角“返回”按钮返回呗。

其次，上次分组只是将筛选后的历史数据回显了过来，通讯录选择某个好友不可看只是功能入口。按理说，当不选择某个好友时，“完成”按钮完全可以设置成可以点击，系统认为没有选择某个好友就好了，但是，上次分组只是同步数据记录，入口还是一样的，也就是，通讯录的选择好友逻辑不变，还是上面的逻辑。

所以，不选择好友时就不会出现“完成”按钮，就导致上次有记录，这次想去掉，就比较麻烦，体验性不好。

4. 这算一个“bug”吗？

个人认为，这算得上是一个体验性的bug。

因为，虽然上文有解决方案，但不是最优解，一是，交互路径长；二是，好多人想不到，镜同学这么聪明，第一次也只好选择一个不相关的人员来替代。

5. 那要解决吗？应该怎么解决？

要不要解决，一是要看造成的影响程度，二是要看解决的成本。

影响程度来说，其中一点就是问题出现的概率，我认为这个概率应该不是很高。因为上次选择的人员，只有在本次需要去掉，而不是替换的时候才会暴露这个问题，单独替换是不存在这个问题的，所以，概率不是很高。其次，真出现了，也有替代的解决方案；再者，功能定位上来说，也不是啥大的业务问题。

所以，影响程度可控。

解决成本来说，我觉得可能主要是老版本的迭代背景。但，我仍然觉得选择为空时，可以点击“完成”按钮，如果为空，就不记录用户标记，是个友好的解决方案，而且，应该不难实现。

以上就是镜同学一点浅薄的思考，由于镜同学主要做B端产品设计，对于C端的产品领悟力有限，分析可能存在偏差，欢迎在留言区指导交流哦。

本文由 @公众号：产品大峡谷 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议