微信的一个小“bug”

2 评论 3150 浏览 0 收藏 10 分钟

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

01

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

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

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

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

于是就出现了下图:

微信的一个小“bug”。

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

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

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

于是,我点击“上次分组”:

微信的一个小“bug”。

接着,我点开“不给谁看”:

微信的一个小“bug”。

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

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

微信的一个小“bug”。

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

微信的一个小“bug”。

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

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

微信内容我都编好了:

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

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

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

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

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

02

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

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

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

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

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

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

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

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

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

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

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

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

4. 这算一个“bug”吗?

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

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

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

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

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

所以,影响程度可控。

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

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

 

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

题图来自 Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
3人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 这是BUG嘛?当选择屏蔽类型为部分不可见时,不可见人员的选择可以是群,通讯录选择,标签三种渠道,并取这3个渠道的并集,你已经在标签里选中了某个好友作为不可见的人选,还怎么在通讯录这个渠道里把他去掉?

    回复
  2. 这个需求估计得P10+了

    回复