先給大家做個測試，根據下圖的流程，最后一步應該返回哪個頁面(為了更能體現效果，建議大家拿出手機跟著步驟做)：

這個問題是我們在做一款IM產品時遇到的，為了說明該問題的廣泛性，就拿微信舉例子了。開發GG完成了版本的交付，我們正在驗收產品，到處開始找碴，突然一測試妹紙跑過來說有個地方有問題，然后她一步步的演示給我們看：先從通訊錄隨便找個聯系人，然后進入該聯系人詳情頁面，再次點擊“發消息”按鈕進入聊天頁面，然后她問我們：“在聊天頁面點擊返回應該返回哪個頁面？”我們幾個想都沒想，下意識的回答到：“當然返回之前的那個頁面了?！?/p>

然后妹紙細嫩的食指一點，這時候奇跡發生了，結果如下圖：沒有返回之前的頁面，而是返回到了消息列表頁面。

我們幾個愣了愣，然后快速把PRD文檔和交互稿都翻了出來，“到底是開發開發錯了，還是我們設計錯了？”。壓根兒沒想過這么做是對的，因為從哪兒進肯定從哪出，返回肯定返回上一界面，正常的邏輯都是這樣的。然后發現交互稿也是這么設計的，接著快速把手機拿出來打開微信(因為當初就是抄的微信的，現在懷疑抄錯了)，我們又愣了，微信也是這么做的，雖然返回按鈕寫了“微信”兩個字，但是沒啥用，第一反應還是返回上一界面。

“微信出Bug了？” “微信的設計也不一定合理吧？”各種猜疑慢慢浮出，甚至差點腦袋一拍決定改了(難得產品、交互、視覺、測試的意見如此統一)。還好改之前多了個心眼：“為啥微信用了這么長時間，從來沒發現這兒不合理啊，感覺完全是無縫銜接的，一點疙瘩也沒有哈？”

繼續分析，根據我們的設計來，優勢有兩點：

• 符號邏輯和用戶預期，從哪兒來，當然從哪兒出，形成閉環；
• 如果我想給第二個用戶發消息，更加方便，因為返回的是用戶詳情，再點一下又回到通訊錄了。

微信這么玩好處在哪兒了：用戶可以快速回到消息列表，不需要一步步返回。

如果僅僅分析到這兒，感覺微信這么設計還不具較強的說服力。

現在開始回到場景吧：小明好久沒跟小紅聯系了，最近怪想她的，于是小明準備找她好好聊聊人生。首先小明進入通訊錄，然后找到了小紅，點擊小紅后進入小紅的詳情介紹，然后又點擊了“發消息”進入聊天頁面開始跟小紅暢談人生。最關鍵的來了：小明和小紅暢談了好久，該說的都說了，不該說的也說了，完全沒話說了，這時候小明如果還留著微信app里，他下一步可能想干嘛了？

• 再找小花聊聊天？ ——聊了這么久也該累了吧，如果跟小花經常聊天的話，應該不需要到通訊錄再去找小花了，入口太深要點擊很多次，直接在消息列表找小花聊吧；
• 看看有沒有其他人找我？ ——回到消息列表；
• 看看群里有沒有什么八卦和段子？——回到消息列表；
• 看看公眾號，學習學習？——回到消息列表；
• 刷刷朋友圈？——消息列表是一級tab，更快速；
• 其他？——好像回到消息列表優勢更明顯哈；

回到現實場景后，好像確實是這樣的，難怪用了這么久的微信都沒發現這兒有坑?，F在兩種設計方案再進行對比的話，從邏輯上來講，確實是返回上一界面更勝一籌；但是從用戶場景來看，明顯微信的方案更符合習慣和自然。后來我們又把來往、易信、陌陌拿過來試了下，也都跟微信一樣(不排除相互抄的可能)，看來這么多的產品決策都是：場景重于邏輯。

到這里終于有人開始支持微信的方案了，但是幾個人意見還是不一致，仍有人覺得方案一更好。于是，我們做了這件事：寫了個簡單的用戶測試案例，找了幾個其他項目組的GG和MM試了下，結果大獲全勝。

場景重于邏輯，其實用戶真的沒有我們想象的聰明，有時候他們壓根兒沒有邏輯。測試過程中，我們問了幾個人：你覺得返回之前的那個頁面怎么樣？ ?“之前是哪個頁面？” …

本文由 @BingoSun 原創投稿，并經人人都是產品經理編輯。未經許可，禁止轉載。