如果不想用戶閱讀時受到幹擾真的是張小龍的想法，那麼想實現從微信文章快速跳轉到聊天的功能就沒有我們想象的那麼容易瞭。
前兩天看瞭幾篇談優化微信閱讀體驗的文章，裡面都不約而同提到瞭微信文章和聊天頁面之間切換麻煩的問題，給出的優化方案大致也是一個意思：當閱讀文章收到新消息提醒浮層時，可點擊該浮層後彈窗快捷回復，無需退出文章頁面。說實話，當我看到這個方案時心裡暗自叫好：" 這才是我想要的嘛！就應該這樣才對！"，相信大部分用戶也都是這樣想的吧。
可是轉頭一想，連我們都知道這個問題，追求極致用戶體驗的微信團隊會想不到嗎？為什麼微信團隊在 2017 年 1 月 20 日上線的 6.5.4 版本中加入瞭簡陋難用、雞肋般的 " 在聊天中置頂 " 功能後，就再也沒對這一功能進行迭代瞭，是否有別的原因？
1. 什麼原因讓微信無視用戶痛點？
網上傳言是因為張小龍不想用戶閱讀時受到幹擾，所以才一直沒有提供便利的閱讀時回復消息功能，想借助回復消息的復雜操作在一定程度上逼迫用戶先看完文章。
有人可能不相信，我倒覺得這很正常，畢竟這種事不是沒發生過：微信在今年 3 月發佈的 6.5.6 版本中將查找聊天文件的入口隱藏起來，據說就是小龍為瞭不讓微信淪為文件儲存器而拍板的。
2. 張小龍真正的目的是什麼？
作為中國第一產品經理，張小龍肯定不可能無緣無故地做出有損用戶體驗的事情，或許他這樣做有更深層次的思考。我們可以多問幾個為什麼並嘗試站在他的角度探究一下：
（1）為什麼不想用戶閱讀時被打擾？
——因為不想用戶中斷閱讀。
（2）為什麼不想用戶中斷閱讀？
——因為想用戶能夠專註於閱讀，培養用戶沉浸式閱讀的意識。
（3）為什麼想用戶獲得沉浸式閱讀體驗？
——因為目前的碎片化閱讀使人們難以集中註意力對信息內容進行深度閱讀與思考。
（4）為什麼想要用戶對內容有深度閱讀和思考？
——因為想讓每一次閱讀對用戶思想和內心更有意義。
當我們追問為什麼得到的每一個回答，都不同程度地反映瞭回答者的內心需求，問的為什麼越多，越接近內心的真實需求。所以，通過上面一系列的為什麼，我們大概能猜測到張小龍的真實需求——改變碎片化閱讀的現狀、培養沉浸式閱讀習慣、讓閱讀更有意義。
3. 有什麼解決方案？
從上文的分析中我們得知，用戶的需求很明確——希望能夠在文章頁和聊天頁快速切換。而張小龍的真實需求——改變碎片化閱讀的現狀、培養沉浸式閱讀習慣、讓閱讀更有意義和用戶需求並不是完全矛盾的。當我們對矛盾雙方的需求有瞭完整把握後，接下來就好辦多瞭。思路有很多，下面我提供一種方案：
3.1 對於用戶需求
如果滿足用戶 100% 的需求，多少還是會和張小龍的需求有沖突，所以我們隻能滿足用戶需求的 70%-80% ——增加一個入口深但操作快捷的今日閱讀記錄功能：
今日閱讀記錄自動保存用戶當個自然日閱讀過的公眾號文章列表，之所以限保存一天，是為瞭避免用戶過度依賴功能，將它當成是儲存未讀文章的地方（所以保存實效甚至可以縮短到幾小時）。但相對於目前的在聊天中置頂功能，今日閱讀記錄有以下優點：
（1）前期更少的切換步驟
當有新消息時用戶可以直接點擊消息提醒快速切換到聊天，回復完信息後隻需退出聊天頁 - 長按搜索打開閱讀記錄 - 點擊文章三步就能返回閱讀，整個切換周期隻需 4 步，比目前的在聊天中置頂功能至少 7 步的切換簡單很多，而且閱讀完之後還少瞭取消置頂步驟，大大方便瞭用戶的切換需求。
（2）後期更多的切換步驟
使用在聊天中置頂功能後，除瞭第一次切換步驟比較復雜，之後一個切換周期內隻需要三步：直接點擊消息提醒快速切換到聊天 - 聊天結束退出聊天頁 - 點擊置頂欄打開文章頁。但每次使用閱讀記錄切換時的步驟是相同的，永遠都是 4 步。所以當在閱讀時頻繁回復時，使用閱讀記錄切換的性價比不高，從某種程度上暗示用戶在閱讀時不要頻繁切換，一定程度上滿足瞭張小龍的需求。
（3）更隱秘的入口
長按搜索按鈕打開今日閱讀記錄，和需要長按才能發純文字朋友圈原理類似，隱蔽、復雜的開啟動作，在保留瞭入口的同時，引導用戶非必要情況下盡量不要使用該功能，能在一定程度上抑制用戶頻繁切換。
3.2 對於張小龍的需求
我們通過分析，猜測到張小龍的真實需求是想改變碎片化閱讀的現狀、培養沉浸式閱讀習慣、讓閱讀更有意義。這是一個蠻大的目標，需要通過持續地優化閱讀體驗、讓文章更有吸引力來慢慢引導，並不是一篇文章能說完的，所以這裡就簡單提幾個方向：
小結
雖然提出的方案是建立在關於張小龍 " 欽定 " 的假設成立的前提下寫的，但無論關於張小龍 " 欽定 " 的傳言是真是假，上文隻是想借這個功能為產品經理在面臨老板需求和用戶需求沖突時提供一種思路：通過深挖需求本質、降低需求標準、尋找替代需求等途徑化解、緩解正面沖突，錯開雙方需求的重心。
最後，如果哪天微信團隊或小龍站出來打我臉 …… 那就當搏各位一笑吧。
作者：Endy 公眾號：赤腳君二
本文由 @Endy 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議
