文章分析了微信交互設計中的幾個細節問題，與大家分享，希望能夠給大家帶來一定的啟發。

微信小程序開閘后果然立即成為這個霧霾格外嚴重的冬天中的一抹亮色，關于小程序將如何給互聯網應用生態帶來沖擊的討論迅速在朋友圈刷了屏，小至小程序和WebAPP體驗的對比、低頻APP的危機，大至微信在庫克眼皮底下的暗度陳倉、引流與分流的博弈，太多的可能性值得我們拭目以待。

此時作為一枚安靜的設計汪，注意力還是回到微信傳統的聊天、朋友圈、公眾號這三大模塊的交互設計本身吧。原本以為伴隨著微信小程序的發布，會有一次比較大的版本更新，但9號醒來后發現iOS端的版本號依然是2017年1月3日更新的6.5.3（說「開閘」結果真的是開閘而已啊……）。三大模塊中一些可用性方面的交互細節問題依然堅挺。本篇將從我的個人體驗、朋友閑聊中的反饋、知乎上「微信設計的渣細節有哪些？」這一帖子下的一千余條吐槽中，選擇其中10個比較有代表性的問題，對可能的優化方案進行簡單的重設計和探討。

當然，這里雖然暫且稱之為「問題」，但僅僅是純粹從用戶角度出發、在使用過程中在交互方面可能感到的一些不便之處?？紤]到微信面對的億級用戶群體，任何一個功能的新增和改動的決策風險也都不是團隊外的人可以妄加評論的。設計方案的優劣本就沒有非黑即白的定論，我也有理由相信微信作為國內最成功的IM（以后會不會是OS？）團隊，關于這些問題都是經過推敲和取舍的，甚至有的在用戶看來是「問題」的地方是產品方出于業務目標考慮有意為之的。

因此，相比討論我做出的10個重設計方案是否合理，我倒是更期待去了解經過千錘百煉的原版方案中為什么會這樣做。如果有幸被知情人士看到這篇文章，并有機會一起聊聊的話，就再好不過了：）

本篇重設計和討論將基于iOS端6.5.3版本進行，因為小程序僅處于發布初期，可以說仍然是測試和逐步完善的階段，因此討論范圍將暫時不涉及小程序。

目錄

1. 公眾號閱讀與聊天的切換
2. 連續添加多個公眾號
3. 訂閱號的分組查看
4. 群聊消息的完全屏蔽
5. 刪除會話時的危險操作警告
6. 收藏表情的排序整理
7. 將非表情圖片添加為表情
8. 朋友圈的返回頂部操作
9. 朋友圈消息通知的兩個優化
10. 意見反饋通道的簡化

以上10個可用性細節中，第1~3點針對公眾號模塊，第4~7點針對聊天會話模塊，第8~9點針對朋友圈模塊，第10點則是關于輔助流程中的意見反饋功能。

1. 公眾號閱讀與聊天間的切換

在閱讀公眾號文章的過程中，小手機忽然虎軀一震——你知道收到了新消息，你擔心是來自女朋友或是上司的「指示」，生怕回得不及時，便忙不迭地返回了會話列表，但當你查看并處理完這條新消息后，想要繼續閱讀公眾號，又要重新從「會話列表」→「訂閱號」→「你想讀的公眾號」→「公眾號會話頁」→「剛才在讀的文章」這一路徑重新回到文章頁面。這一路徑雖然并不算非常冗長，但當你好不容易繼續閱讀后，如果小手機又虎軀一震呢……想必如此往返幾次，再耐心的人也會抓狂吧。

其實現在微信已經很人性化地幫助用戶在第二次進入文章頁面時，自動跳轉到上次閱讀到的位置，至少重新回到文章頁面后不用滾動半天找到剛才的進度了。但仍然缺少一個可以在新收到的消息和正在閱讀的文章之間直接往返的路徑。

這種不支持多任務的做法很符合「用后即走」（在這里或許說「看完再走」更合適）的理念，通過提高往返成本，讓用戶盡量看完后再離開文章頁面。在文章長度一般、收到新消息的頻率和緊迫性都不高的情況下，用戶可以盡量做到讀完再走。但當文章較長、收到新消息的頻率比較高、消息也比較重要的情況下，沒法一鍵返回繼續閱讀就真的會導致體驗受損了。

我個人的習慣是打開一篇文章，先看一下是不是很快能讀完的，如果是長文就直接點擊「…」→「在Safari中打開」，不過對于竭盡所能把用戶留在微信中的產品方，也是一萬個不希望大家都用這種方法去解決多任務問題吧。

對此，重設計中在文章頁提供了一個提示新消息的控件，有別于原有「返回」操作，通過這一控件返回會話列表查看并處理新消息時，可以在聊天頂部看到一個返回繼續閱讀文章的入口，從而方便地一鍵返回文章頁面、繼續瀏覽。

其實，類似小程序中在Action Sheet中提供「顯示在聊天頂部」選項，允許用戶手動將文章保留在聊天頂部的設計方式也是一種可行的方案。但考慮到公眾號文章頁點擊「…」后調出的菜單已經較為復雜，而且用戶在沒有收到新消息的情況下，主動中斷閱讀前往其他頁面的場景可能并不多見，因此最后還是選擇了上面這種重設計方案。

2. 連續添加多個公眾號

當你通過非精確的關鍵詞搜索，查找關于某一領域的公眾號時，你可能對搜索結果中的多個公眾號都有興趣。而當你進入其中一個公眾號的「公眾號信息頁」并點擊關注后，關注成功后的狀態會一閃而過，然后進入「公眾號會話頁」并收到公眾號的歡迎語。此時點擊導航欄的返回按鈕將直接返回「微信」頁的會話列表。想關注剛才搜索結果中的其他公眾號的話，你只能重新再搜索一次。

個人覺得任何一個頁面的「一閃而過」對用戶而言都是不太好的體驗，不但沒有太大必要（閃一秒反正也看不清），也容易讓用戶對自己的操作產生不可控的沮喪感。因此，關注成功后，要么直接（不顯示關注成功后的狀態）進入「公眾號會話頁」，要么停留在已成功關注狀態的「公眾號信息頁」，都是更好的做法。

而回到剛才的場景，如果要為用戶提供一個連續添加多個公眾號的入口，那么后者，也就是關注后停留在已成功關注狀態的「公眾號信息頁」更為合適。用戶此時可以自由選擇，想添加其他搜索結果時，可以通過「返回」回到搜索列表；無意添加其他搜索結果、只想開始瀏覽當前公眾號時，可以通過「進入公眾號」進入「公眾號會話頁」；想直接退出當前流程，回到會話列表時，可以通過新設的「關閉」直接退出添加公眾號的流程，回到「微信」頁。

3. 訂閱號的分組查看

這個問題對關注訂閱號的數目不是很多的用戶來說并不明顯，但對于身邊一些關注了數十個公眾號的「訂閱號控」們來說，無論是從「微信-訂閱號」這一入口按消息更新順序翻找，還是從「通訊錄-公眾號」這一入口，在訂閱號和服務號等全部公眾號中按字母表翻找，都是一件痛苦的事情。

兩種入口中，經過詢問多個朋友的使用習慣，包括自己的個人習慣，都是更習慣使用「微信-訂閱號」這一入口，實在找不到時才會嘗試從「通訊錄-公眾號」按字母表查找，因此本節討論暫針對前者進行。

如果用戶想找的是一個訂閱號時，可以在「通訊錄-公眾號」中按字母表查找，或者使用「置頂公眾號」功能暫且解決。

而如果不是一個，而是一類呢？例如，用戶想重點關注幾個質量特別高的公眾號，或者此時只看某一類別的公眾號時，就變得有點棘手了。

對此，重設計中利用「訂閱號」頁面的導航欄右端，提供了一個篩選控件，默認顯示「全部」，點擊后可以篩選并選擇只顯示特定分組的訂閱號，從而提高用戶閱讀特定一類公眾號的效率。而訂閱號的分組可以在「公眾號信息頁」中進行設置和管理。

4. 群聊消息的完全屏蔽

群聊無法徹底屏蔽應該是一個很多人吐槽已久的問題了，尤其是鵝廠自家的QQ明明在消息接收模式上很好地滿足了用戶多樣化需求的情況下，微信中群聊只支持免擾、不支持屏蔽的特點，在對比下就成了一條廣為詬病的設計，微信拖討論組不需要對方同意更是把這一問題進一步放大。各種想加入的、不想加入的群，無時無刻不在接收著巨量的消息（其中還包含漫天飛舞的表情包），無論對存儲空間還是流量的消耗上都讓很多用戶怨聲載道。

重設計中，在「消息免打擾」功能下方設置了「消息屏蔽」的選項，打開后即可停止接收消息和圖片文件。不過，我猜測微信遲遲不引入這一簡單的功能，應該不是沒意識到、也不是無法解決的技術問題，而是出于某種業務層面的考慮，并不希望用戶有機會徹底屏蔽群聊吧。

5. 刪除會話時的危險操作警告

左滑會話可以調出刪除按鈕是一個iOS下很常規的交互操作，但微信中刪除一個會話意味著所有聊天記錄、圖片文件也都隨之徹底刪除了，無法恢復，關于這一規則的設置，我猜應該是聊天記錄的存儲機制導致的技術問題，總之微信自有自己的道理，不必過多計較。

但既然要同時刪除所有聊天數據又不進行任何提示，看似是簡化了不必要的二次確認，但卻很容易造成問題。對中級和專家用戶來說，或許對此早已心中有數，而對于基數最大的新手用戶（尤其是年齡段較高的用戶）來說可能未必如此，很容易由此造成的聊天記錄和圖片不可逆的損失。

重設計中，在調出刪除按鈕、點擊后會多出一步確認操作，用于提示用戶，在刪除會話的同時，聊天記錄和文件會同時刪除。同時，也允許用戶在熟知這一操作背后的危險性后，選擇「下次不再提示」。

6. 收藏表情的排序整理

表情包是當前年輕用戶使用IM聊天時不可缺少的一部分（當然，中老年用戶也使用表情包……雖然不是一類表情）。而當用戶收藏了數目較為可觀的表情后，將最常用的表情以特定的順序放在最方便的位置，就成了一個很普遍的訴求。

最方便的位置，顯然是表情面板的第一屏，可惜寸土寸金的第一屏已經被碩大的「+」入口、猜拳和骰子占掉了三個座位，只剩下5個位置可用的情況下，一定程度上加劇了上述需求出現的頻率。

而在整理表情時，用戶經常會按照其他應用中類似場景下的使用習慣，理所當然地覺得表情是可以通過長按拖動，實現自由的排序的，可事實上微信的表情整理只支持「移到最前」這一種方式，這就讓表情的順序調整變得很笨拙，尤其是小范圍內的精細調節時，比如下面這個例子。

重設計中，補充了長按拖動這一功能，這一符合用戶已有使用習慣和心智模型的交互方式并不需要太高的學習成本。大范圍地調節時，可以選中后一起「移到最前」，小范圍地局部調節時，可以長按拖動。兩者相輔相成，我想可以大幅優化用戶管理表情包時的體驗。

另外，對「讓常用表情出現在更方便的位置」這一需求，按使用歷史或者使用頻率自動降序也是一種看似可行的方向。不過，Genie解釋過這個問題，無論是按使用歷史還是頻率，自動排序都會導致用戶想找一個表情時不確定位置在哪，大大提高尋找表情的時間成本。也就是說，這種做法只方便了查找最常用的幾個表情，而偶爾要找一個不算很常用的表情時，這種做法的弊端就會很明顯。

因此，重設計中還是考慮通過長按拖動，允許用戶更靈活地自定義固定排序即可較好地解決表情管理中的這一問題。

7. 將非表情圖片添加為表情

同樣是關于表情包的一個問題?！笧槭裁从械谋砬榭梢蕴砑拥阶约旱谋砬?，有的不行？」這個問題已經不止一次聽到朋友或者同事聊起。

原因很簡單，不過解釋起來有點繞。會話中的圖片我們看上去都一樣，但其實有兩種格式，暫且一種稱之為「表情」、一種稱之為「非表情」吧?！副砬椤故瞧渌脩粢呀浲ㄟ^正確的方式轉化并添加到收藏的「真正的」表情，而「非表情」則只是單純的圖片（雖然這個圖片本身可能是一張金館長熊貓臉的表情），并沒有轉化成微信內部「表情」的形式，而是在聊天中通過「發送圖片」、「轉發」等形式四處流傳的，這樣的情形不多，但偶爾出現時，無法收藏進自己的表情也常常會造成用戶的困惑。

熟悉表情管理的用戶一定知道，如果想把一張「非表情」添加為「表情」，可以先將其保存為圖片，再經表情面板的第一個「+」按鈕→「我的表情」→「添加的表情」→點擊表情列表末尾的「+」格子→從相冊中導入這一圖片，從而將其從「非表情」格式轉化為「表情」格式（這一過程這里不再贅述）。但對很多不熟悉這一流程的用戶來說呢？還是通過下面這個小例子來說明吧。

重設計中對「非表情」也添加了「添加到表情」功能，從而一鍵代替現有方案中冗長而繁瑣的添加表情流程。至于功能的位置，原本考慮直接在會話界面長按圖片調出的快捷菜單中設置一個「添加到表情」功能，但在已有5個選項的情況下，再添加一個五個漢字的選項并不合適，所以還是把這個功能收進了大圖模式長按圖片調出的Action Sheet中。

當然了，我猜測微信這樣設計可能是有意為之的，有可能是為了避免過量的「非表情」圖片變成可以更便捷地流通的「表情」，導致加劇表情包大戰的風氣，才刻意提高了這一操作的學習和時間成本。不過純粹從用戶體驗角度，我想應該有比當前方案更合適的解決途徑。

8. 朋友圈的返回頂部操作

這一點嚴格來說不是問題，因為iOS端的應用實際上是內置了「點擊狀態欄快速返回頂部」的功能，但和上面提到的很多問題一樣，對中級和專家用戶來說不言而喻，不代表對新手用戶不言而喻。在熟知這一個功能的人看來，這種小技巧只要知道一次以后就都不言自明了，但事實是相當數量的人至今還不知道，我就親眼目睹過很多人不停地向上滾動屏幕以返回朋友圈頂部的操作習慣。

重設計中，考慮到用戶并不一定能正確區分「狀態欄」和「導航欄」這些術語，便將返回頂部的功能賦予了區域更大、更容易點擊的導航欄中部，并顯式地告知了用戶「點擊這里就可以返回頂部」。

9. 朋友圈消息通知的兩個優化

關于朋友圈的消息通知，聽到過頻率比較高的兩種抱怨。

第一種抱怨，是關于朋友圈更新的紅點提醒。

A：「朋友圈老是有紅點，我又有見到紅點不刷不舒服的強迫癥，只好不停地去刷，時間就這么過去了T_T」
B：「那你關了唄」
A：「關了更會想，雖然沒提示，但是不是有更新呢……于是刷得更頻繁了」
BCD：「……」

這類抱怨的本質不是用戶想不想接收提示的問題，而是用戶被提示吸引進行了刷新操作后，看到的信息并不一定是他們感興趣的。所以，現有方案中簡單的非開即關的設置很難有效地解決這一問題，用戶需要這一提醒功能，只不過希望更有質量的提醒，而并不是完全關閉。

第二種抱怨，是關于共同朋友間互動的計數氣泡。朋友圈出現紅色的計數氣泡的情形分以下三種：

• A：你發了朋友圈，則你共同朋友的點贊和評論（無論評論有無指向性），都會出現計數提示。
• B：你點贊了X的朋友圈，則你的共同朋友（包括X本人）的點贊和無指向性評論，都會出現計數提示。
• C：你評論了X的朋友圈，則你的共同朋友（包括X本人）的點贊、無指向性評論和指向你的評論，都會出現計數提示。

而抱怨主要是針對B和C類的。

A：「我給朋友曬結婚證的朋友圈點了贊，然后一整天都在收到別人點贊和評論的提醒?！?/p>

B：「說明你朋友人緣好唄」

A：「可是，不停地看到紅色數字，點進去卻發現全是別人之間的互動，自己發的朋友圈無人問津，會很失落的」

ABCD：「……」

其實這類抱怨因人而異。有人喜歡看共同朋友之間的互動，比如八卦一下「哎呀原來A也這么關心B」、「天吶C怎么說話這么酸」，對他們來說，現有的提示機制就很得歡心，甚至巴不得連朋友之間有指向性的互相評論也有提示更好。

而有人則對和自己沒有直接關聯的互動毫無興趣，卻又不得不逐條看完別人之間的點贊和評論，對他們來說，只有A類和C類中指向他的評論，才是他所關心的。對他們沒興趣看的互動，數量有限時或許還好，但對一部分微信好友數量比較可觀的用戶來說，每每動輒幾十條的話，久而久之可能就干脆懶得看了，我想這也不是產品方愿意看到的后果。

兩類用戶都有一定的數量，不過在我的圈子和詢問的用戶范圍內，后者稍微占多數。

關于紅點提醒和計數提醒的抱怨代表了兩個用戶訴求，那么綜合這兩種需求，我的重設計方案考慮如下：

• 首先，允許只對部分朋友的朋友圈在更新時顯示紅點提示，從提高提醒質量的角度解決第一個需求。
• 其次，允許用戶關閉朋友之間互動產生的計數提示，即只保留上述分類中A類和C類中指向用戶自己的評論。

10. 意見反饋通道的簡化

最后想說的一點，是關于微信的意見反饋功能。
意見反饋作為一個每個APP必備的常規輔助功能，原本并非核心流程，也不容易出現什么明顯的問題。但微信的意見反饋路徑……實在是我所見過最長的。

長的原因首先是和常見問題的FAQ公用一個入口，這個出于簡化「設置」頁信息元素的考慮也無可厚非。

但同時，微信的意見反饋要求用戶必須幫助產品方將問題進行兩級細分后，才能抵達輸入意見的頁面。如果用戶選擇的不是「其他異常反饋」而是某個細分的選項，那么在輸入意見時還要進行第三次關于故障位置的細分。

這種設計的實質就是將用戶反饋的收集和分類工作，由產品方轉嫁給了用戶。一級分類或許還可以理解，但二、三級的分類簡直是讓用戶有放棄的沖動。不過假如這是出于資源有限的考慮，有意將提交意見反饋的流程復雜化，從而提高反饋的質量、同時大幅降低反饋數量的話，倒也不難理解。

如果不考慮這些，單純從用戶角度出發，個人覺得應該有更好的方案可以考慮。重設計中，我首先將「常見問題」和「意見反饋」的兩個入口分離，「查詢既定幫助文檔」和「直接提交反饋」兩種場景的差異還是蠻大的，在「設置」頁的信息沒有過載的情況下，分離開來利大于弊。

「常見問題」保留除意見反饋外的全部原有內容，此處不再贅述。而「意見反饋」則直達輸入意見的頁面，其中「問題分類」選項允許用戶視自己的意愿是否提供細致的分類（逐級細分的選擇流程參考現有方案，不再贅述），并通過文案告知用戶，如果愿意提供準確的分類，將有助于你提出建議得到更好的反饋，即「誘導」而不是「強迫」用戶替代產品方對反饋進行細分的工作。

作者：Qinsman，通信行業UE設計師，微信公眾號：西市饅頭鋪子。博客：http://qinsman.com/，歡迎大家與我交流。

本文由 @Qinsman ?原創發布于人人都是產品經理。未經許可，禁止轉載。