互聯網產品往往都有自身的生命周期，處在不同階段的產品，對應的產品目標也有所不同。那么在不同階段，應該如何對產品進行功能體驗升級呢？本文作者結合自身的工作經驗分享了他的看法，一起來看一下吧。

互聯網產品往往都有自身的生命周期，處在不同階段的產品，對應的產品目標也有所不同。產品剛剛誕生之初往往以核心功能優先，用來滿足一類人的共性需求，此時產品主要滿足“可用”的目的。而成熟期的產品，由于用戶量上升，功能也比較完善，產品目標就變為保證這群用戶的留存與轉化，此時產品就需要滿足“好用”跟“易用”的目的。而這個時候，也就是交互設計師發力的時候。

筆者目前負責的產品就是處于較成熟的階段，有一定的用戶群體，功能也比較完善。但是由于前期都是滿足產品的功能架構，導致功能的操作流程冗余，且體驗不佳。所以當前主要就是對現有產品的各個功能與流程進行走查（產品體檢），然后根據產品的排期，做后續的功能體驗升級，那該如何去做？本篇文章筆者就結合自身的工作經驗來跟大家聊聊。

一、了解業務與使用場景

產品功能是基于業務屬性及用戶使用場景設計的，如果不深入了解就意味著設計出來的功能可能會跟預期發生偏離。由于之前沒有參與相關行業的設計，以及剛來公司不久，所以在進行功能優化之前，我都會去主動熟悉當前的業務目標跟場景痛點，確保產出方案的合理性。

舉個例子：

電商產品中，待付款訂單是指用戶在提交訂單以后，由于某種原因取消支付或支付失敗后，訂單所呈現的狀態，用戶可在待付款列表中查看待付款的訂單，以便發起繼續付款等操作。

以下是公司產品當前版本的待付款列表：

在了解功能的業務場景以后，針對用戶的使用場景產生了疑問，用戶是基于什么原因沒有完成支付的呢？根據團隊成員的腦暴及前期的用戶調研，主要總結出了兩點原因：第一、對應支付賬戶余額不足，返回待支付頁面選擇新的支付方式；第二、暫時不想買了或者部分不想買了，從而退出支付。根據用戶在該場景下的痛點出發，來看看當前功能的合理性。

針對第一點，如果用戶是為了更換付款方式，那么在返回待付款頁面時，第一操作應是選擇新的支付方式。而當前流程是讓用戶提交訂單到選擇支付方式頁面，再進行選擇，無疑是不符合用戶的操作預期且操作鏈路變長，所以我們可以考慮將付款方式前置，放在待付款頁面供用戶重新選擇。

針對第二點，如果用戶是不想買了，那返回后就沒有其他操作了，但是如果僅僅是部分不想買了而退出支付，那就需要考慮用戶如何去支付部分商品。目前公司的業務是待付款狀態會將用戶提交的不同商家的商品進行拆分，所以當用戶想買其中的某幾樣時只能單獨分次購買，比較麻煩，而為了讓用戶便捷支付，考慮加入“批量支付”功能與流程來解決當前的用戶痛點。

二、走查功能流程與體驗

所謂“知己知彼、百戰不殆”，走查功能流程就是知彼的過程。走查也不是僅僅就截幾張圖這么簡單，根據我平時走查的流程，我把走查分為了前、中、后三個階段。

1. 走查前：明確走查目標，提前做好準備工作

走查是帶有明確目的性的，在開始前明確此次的目標，能減少在走查的過程中減少彎路。比如我們此次的目標是“優化用戶下單的鏈路”，那我們就應該在用戶下單中的流程進行走查并定位問題，找到影響用戶流程的因子，而下單后的陪伴由于不在此次目標中，就可以弱化。

那么走查前要做哪些準備呢？我們知道一個完整的功能與流程除了正常流程外，還有很多“非正?！钡拇嬖?，比如各缺省狀態、各彈窗等等。所以為了能覆蓋該功能所有的流程與頁面，我們需要與測試同事合作，除了申請測試賬號用來查看完善的流程，還需要根據不同的情況為賬號賦予不同的權限與屬性。

2. 走查中：根據頁面的信息架構與操作流程定位問題

如何開展走查工作？一般我都會分成兩部分進行：

第一，明確頁面信息結構合理性。主要包括頁面的信息層級以及功能按鈕的位置等內容。根據頁面當前信息呈現，來判斷是否存在問題，比如信息過于分散或者重要信息不明顯等，以及根據頁面的功能特點，來判斷按鈕是否有優化的空間，比如按鈕文案是否有歧義，主要操作按鈕位置是否難以點擊等。

第二，梳理各觸點操作流程。主要是對頁面中所有可點擊區域，如卡片、按鈕等進行逐一點擊，來判斷當前流程是否有問題。比如跳轉的頁面是否符合用戶的心理預期，用戶完成一次任務的跳轉次數是否過多等等。

那么我們又如何判斷頁面是否有問題呢？雖然問題的產生大多時候都是設計師的主觀感受，但是絕不是說僅代表設計師的個人觀點。交互設計師往往在設計流程的時候是站在用戶的角度，所以在走查功能的時候也是通過用戶的視角來看流程的合理性。同時為了提出問題的專業性，我們還需要豐富自己的專業知識，比如通過尼爾森十大原則、設計心理學等相關用戶研究結論，來輔助與驗證我們提出問題的合理性。

3. 走查后：輸出相關功能體驗文檔

所謂“好記性不如爛筆頭”，在走查的時候我們需要對定位的問題進行記錄，從而為后面能提出體驗升級需求與迭代做依據。那該如何制作功能體驗文檔呢？

一般我會先將本次走查定位到的問題做個數量的匯總；然后根據“是否嚴重影響操作流程與體驗”做個程度劃分；接著將所有有問題的頁面與流程進行展示，并記錄問題內容；最后根據這些問題，梳理后續的優化方向。

三、競品分析

通過前兩步，已經知道了該功能的業務目標、用戶使用場景與痛點以及當前存在的問題，接下來就需要針對當前問題去尋找合適的解決方案了。競品分析是一種很好的幫助我們形成方案的辦法，也就是“知彼”的過程。目前市面上對競品分析的方法介紹已經很多很全，這里就不再贅述了。但是我想通過一個案例，來聊聊我在做功能的時候是如何利用競品來完善自身方案的。

在做公司搜索功能的體驗升級時，發現當前版本的搜索框，采用的是默認關鍵詞填充，即“輸入關鍵詞搜索”，走查時發現該方式主要存在三個問題：第一、占位符文案并沒有明確告知用戶能用什么方式搜索；第二、該形式占位符文案無法形成有效的點擊率轉化。帶著這些問題，我進行了競品分析。

通過對不同類型競品進行分析后發現，目前大部分的搜索框占位都采取“關鍵詞推薦”的形式，即動態輪播搜索關鍵詞。而選擇什么關鍵詞一般基于兩點：用戶行為數據以及后臺配置。那是不是意味著當前產品就要加入這個功能呢？這要基于當前的業務屬性來進行考量。

首先，根據用戶行為展示關鍵詞，就需要對用戶的操作行為進行埋點與分析，如果直接復用競品內容而不考慮當前技術成本與難度，就會使這次的體驗升級陷入困境。

其次，當前公司業務是不是需要關鍵詞推薦。目前公司商品還不夠完善，所以經常有用戶搜不到的情況，加上經常有折扣商品或者希望用戶下單的商品存在，所以從業務出發，是可以將這些商品配置成搜索關鍵詞，增加用戶“被動搜索”的權重，減少因用戶主動搜索為空帶來的挫敗感以及增加目標商品的轉化。

所以，競品分析不是單純的“抄一個功能”，而是通過對當前市面上產品的分析，了解該功能市面上的常規玩法，再結合目前的產品與業務屬性，來權衡是否有必要引用該玩法，或者做定制化的優化與升級。

四、方案產出

通過上述的步驟與流程，就差不多已經完成了產出方案前的準備工作，接下來就是針對本次的升級改版輸出交互方案，而為了讓方案能緊跟產品開發節奏以及適應不同的場景，我一般都會把整個方案的產出分為以下四步：

1. 主要功能頁面原型制作

這個階段主要是針對功能的主要頁面進行信息布局以及功能入口的完善，來展示改版后的功能能完成用戶什么操作，并通過對比原有頁面，組織產品及相關人員對方案進行評審，來判斷方案的可行性（技術可行性、業務可行性等）

2. 二級頁面及異常狀態頁面補充

這個階段是在確定了主要功能頁面后，進行的次級頁面以及不同狀態頁面的補充，主要是將該功能所有頁面進行設計與呈現，主要目的是便于UI設計師根據當前原型頁面數量評估時間。

3. 所有頁面串聯

這個階段是將所有的原型頁面產出完成后，對所有的頁面分場景、分功能串聯流程，主要目的是組織技術等人員在進行交互方案宣講時，能便于知道各觸點、各頁面的跳轉流程與邏輯。

4. 交互文檔補充

這個階段是在進行交互評審后，此時已經確定了此次迭代的整個交互方案，根據前期的設計想法以及評審中反饋的建議，進行所有頁面的交互文檔的輸出與補充，主要目的是為了留存方案的交互邏輯，便于技術測試人員在開發以及編寫測試用例時查看。

五、驗證與反饋

交互設計師的工作不是在產出方案以后就結束了。功能體驗升級往往是用戶體驗設計師驅動的，而如何才能證明此次迭代的價值，除了前期定位的當前版本存在的問題說明外，最主要的還是要驗證此次迭代版本的效果，而如何驗證？一般我都通過如下兩個方式進行：

1. 跟進用戶反饋

由于公司屬性，產品的用戶都有對應的客戶運營人員，這樣就便于收集用戶使用產品及功能的意見反饋，而一般的體驗升級的需求也往往是基于用戶的“吐嘈聲”中誕生的，所以迭代上線后，持續跟進用戶的使用反饋，能很好的驗證此次方案的效果，以及尋找新的突破口為產品的后續迭代做準備。

2. 收集相關數據

一般在進行功能迭代升級時，為了能后續驗證方案的效果，會進行相關的數據埋點。以上述提到的搜索為例，在設計“輪播關鍵詞填充”的功能時，就需要對用戶搜索對應推薦關鍵詞的數量以及最終的購買轉化率做個跟蹤統計，從而來輔助判斷此次功能升級的效果。

六、總結

以上，就是筆者根據過往的工作經驗，分享的一篇關于如何做體驗升級的文章，后續也會繼續分享自己在實際工作中的一些產品與交互心得與感想，經驗有限，歡迎大家批評指正與交流。