微信的一個小“bug”

2 評論 3223 瀏覽 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+了

    回復