編輯導語：前端設計對于客服系統來說十分重要，而活用用戶體驗要素進行前端設計才能更好地完善整個客服系統。在本篇文章里，作者分析總結了有關前端設計的內容，一起來看一下吧。

用戶體驗5要素我們都不陌生，在人人上面一搜一大把，從0-1或者對整體架構進行框架改革的時候都會用到這個知識，這里簡單回憶下用戶體驗要素：戰略、范圍、結構、框架、表現層。

• 戰略層：通常指做個產品或功能的目標。戰略層有一套很詳細的分析方法，由于和本次主題相關性不大，我這里YY一個吧?？蛻粼谫徺I和使用公司的產品有咨詢訴求，公司根據產品技術棧創建專業的客服團隊，通過在線客服系統解決客戶的問題。
• 范圍層：通常是指功能范圍，確定產品的邊界，例如：確定客戶和客服的功能需求范圍。
• 結構層：簡單說就是確定用戶的整體路徑，確定用戶路徑之后，我們才可以進一步做頁面設計。
• 框架層：網上說的稍稍復雜了一點，講真每次看完網上講的我也有點懵逼，我把它轉換成自己的概念，即展示哪些信息給用戶看，我們要提供哪些按鈕給到用戶操作。
• 表現層：網上說了很多專業的詞，對產品來說它就是原型。表現層主要是給設計發揮的地方，在大廠可能會由設計團隊來把控，會由交互、視覺和重構三個不同崗位的設計完成。

在做前端設計的時候也會遵循這5要素進行搭建，下面我會詳細跟大家講下我在做前端搭建時的方法論。

一、范圍層：確定產品和功能的邊界

使用產品的用戶可以劃分為4類：咨詢問題的客戶、服務人員客服、質檢人員、管理者，當然不同的企業和產品會有更多的角色，本篇僅圍繞客戶和客服兩個角色。

以下模擬場景純屬虛構，如有重合純屬偶然。

1. 客戶

客戶尋求幫助的入口很多：群、微信客服、Web官網、app或小程序。假設一期用戶尋求幫助的入口只在小程序。

當“我”打開客服界面之后選擇訂單（或問題）召喚客服，客服解答完“我”的問題，向“我”發起結束會話請求，“我”認為客服徹底解決完我的問題了，“我”同意結束這次的會話。

“我”記得我之前還咨詢過某產品的使用，我想看下之前的聊天記錄，客服給“我”的解決方案是什么。

客服處理的態度太差了，“我”要評價反饋上去。

由此分析 用戶需要“會話工單（歷史服務訂單）的查詢界面”、“會話實時溝通和處理界面”、“服務評價功能”。

2. 客服

客服按照技術棧接收來自各個渠道的用戶訴求，需要實時與客戶溝通，當客戶表達不清楚自己需求的時候，“我”需要打電話給客戶。

“我”要下班了，還有沒有處理完的會話，一部分自己處理，一部分交接給同事吧。

這個不是“我”處理的問題，轉給相應的技術棧吧；這個問題培訓的 時候沒有說到需，升級技術棧處理下。

我確認客戶問題處理完了，給客戶發送結束會話的請求。又來了好多新會話“我”得趕緊切去查看和處理。

剛剛有人沒有按規范流程個做事提前走了，領導叫我們每個人都“認領”一些會話過來處理 。

由此分析，我們需要“實時溝通處理界面”、“會話處理工作臺”、“所有客服的會話列表”、“客服值班狀態管理”。

其實在這個階段還會做另外一件事，那就是競品的調研。

這個時候的調研就沒必要在調研戰略層了，直接調研競品和間接競爭的功能，并對每個功能進行描述并注明服務的角色。

之所以會做這一步的目的有兩個：

• 一是了解行業的設計邊界提高整個產品的高可復用性；
• 二是分析他們的價值并查漏補缺有哪些功能未來會有，而自己不知道的。

二、結構層：確定用戶路徑

用戶路徑是所有產品都必須掌握的基本功，用戶路徑的實用范圍也很廣。

數據產品經理也會根據業務產品經理繪制的用戶路徑確定埋點方案和數據方案，而我們也是參考前期繪制的用戶路徑確定整體的頁面架構方案。

1. 用戶路徑

客戶咨詢產品的用戶路徑：

關鍵路徑：用戶進入客服咨詢界面>>>點擊問題分類/輸入兩次問題>>>接入客服>>>處理問題>>>收到結束請求>>>同意結束>>>發送評價

關鍵路徑：

• 客服收到新會話>>>回復客戶>>>問題解決>>>申請結束>>>客戶同意結束>>>結束
• 客服收到新會話>>>回復客戶>>>無法解決>>>升級處理

2. 用戶路徑轉譯成頁面交互

在確定用戶路徑之后，我們其實就確定了用戶在頁面上的交互邏輯，通常會采用手繪的方式繪制出整體的框架結構。這個時候整個產品的就已經是“小荷才露尖尖角”的狀態啦。

客戶頁面交互路徑：

客服頁面交互路徑：

雖然畫的很好看，但這里并不是最終的方案，只是大概展示了頁面的結構。

框架層還會對內容里面的信息做更細維度的劃分。

三、框架層：信息清單和功能清單

信息清單和功能清單的作用圈定頁面展示的詳細信息，我們要提供哪些重要的信息給用戶查看，提供哪些重要的功能給用戶點擊。

信息清單和功能清單收益者還有設計，UI設計師是深耕在交互體驗上面的，我們提供到信息清單和功能清單給設計直接由他們進行頁面的UI設計。

信息清單和功能清單的梳理主要參考3樣東西：流程圖、頁面框架交互、站在用戶視角體驗梳理。

1. 信息清單

客戶側信息清單，站在客戶的角度分析客戶想要看到的信息。

客服側信息清單，站在客服的角度分析客服想要看的信息。

2. 功能清單

客戶側，站在客戶的角度分析流程中用戶需要的操作功能，界面中用戶需要的操作功能 。

客服側，同理。

四、表現層：交互原型設計

在表現層也會有一次競品分析調研，了解競品的交互模式。

我們有了用戶路徑、頁面的交互路徑、信息清單和功能清單了，此時就是進行我們頁面原型交互設計的時候了。

如果是對外給用戶展示的界面，表現層都是由UI把控；如果是給企業自己人用，在條件允許的情況下可介入UI，不然沒有太大的必要。

以下從3個場景闡述如何結合結構層和框架層設計表現層。

1. 客戶查看問題分類接入客服

2. 客服查看客戶信息

這塊一定要根據實際的場景分析客戶的信息清單是否梳理完全了且考慮到未來功能的延展了。

設計的步驟和1是一樣的，信息+功能 +頁面的交互，得出我們最終的表現樣式。

下述舉例了3種交互展示樣式，哪種的展示交互樣式最合適，需要與工作臺其他的元素和客服的工作場景模擬考慮結合，在保證界面簡潔的前提下，方便增加未來越來越多的功能應用。

3. 客服工作臺

這里截圖一些公開的客服工作臺，直接給大家參考界面。

但是實際上工作臺需要一些什么功能和信息都是由前期的信息清單和功能清單決定的。

如果是自己重新搭建工作臺的話最重要的還是前面的信息和功能的梳理，否則最后表現層設計出來的東西也是 無法滿足業務需求的。

如果無法滿足業務 需求則很容易出現頁面重構和系統的重構。如果滿足業務需求，即使頁面再丑它也是 一個 好的產品。

表現層里面的學問很多曾經為了做好表現層的交互設計，學習了很多關于交互設計的資料。

這里推薦一些我還不錯的：交互設計精髓3（現在4已出）、簡約至上，公眾號：AlibabaDesign、騰訊CDC體驗設計、騰訊云設計中心、UXD筆記等公眾號了解一下最新的交互模式。

這些公眾號對于非設計同學來說是很的很放松，俗話說的好，藝術與科學總在山頂重逢。以后有時間再根據交互進行深入的分享吧。

五、結語

本篇主要是分享搭建的思路和一些常用的功能。

再順便說一句如果這個頁面沒有交互設計和重構，你抄的哪個產品的交互，直接告訴前端開發，在一定程度可以減少很大的溝通成本。

當客服系統搭建起來之后，數據指標也是非常關鍵的。

面對一個0-1的產品我是怎么去確認 一個東西的數據指標呢？我們要怎么制作數據看板呢？

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

題圖來自Unsplash，基于CC0協議