昨天審核設計稿的時候，發現投訴詳情頁的處理軌跡存在問題。這個界面的場景和流程是這樣的：客戶在小程序發起投訴，售后人員溝通并記錄在后臺，后臺再返回數據至小程序，讓客戶看到投訴結果。

更多干貨

你可以代入客戶角色來理解一下：你收到了商品，使用后沒有達到你預期的效果，現在要投訴。公司派了售后跟你聯系，先跟你溝通退 30%的錢，你不太滿意這個結果；于是進行第二次溝通，說給你退 50%的錢，你覺得可以，完結了這一次的投訴流程。

這個過程，肯定只有一個人跟你聯系，不管是不是同一名售后客服。不會存在 A 跟你說退 30%，B 跟你說退 50%，讓你選一個方案的情況。因此，在你同意售后方案之前，你也不知道下一步是什么，都是溝通后才會得出結果。

基于這個場景下，你看看下面這個界面，場景和界面是不匹配的：

界面做出來和場景不匹配，可能是在某個環節發生了誤解。于是我跟設計溝通，看看她是怎么理解原型做出來。下面是她的理解：

她認為這是一件事的三個固定步驟。第一個步驟已經處理完了，第二個步驟正在處理，第三個步驟待處理。

回想一下剛才說的用戶場景：“在你同意售后方案之前，你也不知道下一步是什么，都是溝通后才會得出結果”。又怎么會存在固定的三個步驟呢？又怎么會知道下一步待處理的是什么呢？她問我，我們的分歧是不是左邊的狀態跟右邊的文案順序反了，產品經理是不是需要改文案。

我察覺到設計師可能還是沒理解用戶場景，導致我們不在一個維度討論。她也沒有把小程序和后臺的操作對應起來，沒考慮到后臺進行了什么操作才會產生這樣的前端頁面。于是我把小程序對應起后臺，結合場景帶她走一遍流程，讓她知道產品原型為什么會這么體現：

在售后客服處理投訴的時候，會存在今天跟客戶溝通，但客戶不滿意方案的情況。這種情況下，客服會選擇「處理中」這個狀態，下一次再接著跟進溝通。

產品經理將后臺的「處理中」和「已處理」的數據，全部反饋回小程序。要注意，會有多條「處理中」的數據。即可能會出現以下的軌跡：

如果你是用戶，看到下面這個界面會不會懵掉：我的投訴到底多少個人在處理？為什么又有已處理，又有處理中，又有待處理？現在到底是處理完了沒有？

產品經理在規劃小程序和后臺的原型時，是從 B 端考慮數據回顯到小程序，但是沒有從 C 端用戶的角度去考慮——他們在這個頁面需要獲得什么訊息。

客戶發起投訴，最關注的就是處理結果和處理進度。整個事件的結果，應該有且僅有一個狀態，即「待處理、處理中、已處理」三者之一。我們只需要讓客戶看到一個狀態。至于處理的軌跡，只需要按照時間倒序排列即可。

跟產品經理溝通后，她表示我們這樣改是對的，同時建議我們可以不用圖標來表示進度的狀態，因為每個狀態都是售后在后臺實際操作之后生成的數據，不存在等待下一步。下面是正確的界面：

做完需求后，我們跳出彼此的角色去復盤。在設計層面，設計師應該立足場景，結合小程序與后臺，將數據一一對應起來，做之前先思考這么體現是不是正確的；在產品層面，產品經理應該分清小程序與后臺的兩個不同用戶群體在界面中應該獲得什么信息。張圣煥教授說過：脈絡和洞察在先，設計在后。產品設計是為人而生，為解決問題而生的。思維與分析很重要，排版和視覺只是結果。

整個過程，我們從設計層面出發，看到設計表達與場景的不匹配，沿著思路比對原型，從原型中理解產品經理的思路，再結合場景調整做法，與產品經理商量哪種方式更合適，最終解決了這個問題，這是一次有效的產品設計溝通。

本文中原型與界面已脫敏，已經過產品經理與設計師的同意，將本次溝通過程發表成文章。

歡迎關注作者微信公眾號：「牙線y2x」