對于 B 端設計師而言，競品分析是解決設計難題、把握行業趨勢的核心工具。但實際工作中，很多設計師都會陷入 “難試用、術語多、無結果” 的困境 —— 要么拿不到競品賬號，要么被專業術語繞暈，要么漫無目的地點擊瀏覽，最后只留下 “這個界面不好看” 的淺層評價。其實，B 端競品分析的核心不是復刻產品功能，而是通過拆解表象、挖掘邏輯，為自身設計提供可落地的思路。本文結合實戰經驗，從核心價值、競品分類、分析方法到資源渠道，全方位拆解 B 端設計師該如何做好競品分析。

本文為「蘭亭妙微」轉載并編錄的行業實踐經驗分享。原文圍繞產品設計驗收的意義、流程與評估方法展開，并結合齊治設計團隊在網絡安全產品DSG項目中的實際案例，系統闡述了如何通過標準化、體系化的驗收機制提升產品體驗與業務成效。希望能為關注產品設計質量與團隊協作效率的同行提供參考。

一、設計驗收的價值何在？

設計驗收是指設計人員按照設計方案對研發人員的落地內容進行逐項檢驗，理想狀態下，最終達成設計方案的完全還原。

由此可見，設計驗收的直接目標是保證設計還原度。那么設計還原度究竟可以為產品帶來些什么？我們假定設計方案不存在問題：

• 從需求層面來說，高還原度意味著用戶的功能需求得以滿足
• 從體驗層面來說，高還原度意味著用戶的操作體驗得以保障

設計驗收追求每一個設計細節的切實落地，由此帶來的正面效益會傳遞給用戶更好的產品體驗，也進一步提升業務交付的滿意度。

那么如何在日常工作中高效高質地開展設計驗收、發揮其價值，以下是齊治設計團隊結合網安產品DSG項目的驗收實踐給出的答案：

二、驗收流程的標準化：四個階段

規范工作流程有助于提高驗收效率，保障驗收質量。

在制定設計驗收流程前，首先思考以下幾個基本問題——

1. 何時開始驗收？
2. 什么輸出內容？
3. 輸出給誰？
4. 是否需要根據需求體量區分驗收方案？
5. …

最后，我們將設計驗收拆分為四個階段，明確以下標準流程用于指導設計驗證的開展：

1、準備驗收階段

確定設計驗收的開始時間、驗收環境以及賬號密碼是設計人員開展設計驗收的必備條件。

理想狀態下，設計驗收的開始時間應該是功能驗收基本完成，流程無阻斷性Bug之后，即發布前的最后2-3輪提測。但是考慮到具體項目執行的變化，本流程建議設計人員主動向研發或測試負責人確認開始前的條件信息。

2、具體驗收階段

通過比對設計方案與落地方案，設計人員可以發現落地方案未還原的內容，以及少數設計方案不完善、不合理的地方。然后，為了更好地服務于問題修復階段的設研協作，設計人員需要將這些問題形成驗收表，并以在線文檔的形式共享給研發人員。這樣可以大大減少信息混亂、溝通低效、追溯困難等問題。

3、問題修復階段

設計人員發現問題并記錄于驗收表后，驗收就進入了最關鍵的一環。嚴格按照“溝通問題-修復問題-再次驗收直至問題被解決”的循環工作流來消滅問題，有助于切實提升設計落地的還原度。同時，出于驗收質量的要求，建議設定一個循環次數的紅燈值，這是對設計人員與研發人員雙方的更高要求。

通過DSG項目的執行驗證，我們發現「溝通」在這個階段至關重要，這包括所有問題的整體澄清以及具體問題的修復溝通。尤其當問題總數較大時，設計人員與研發人員之間的充分溝通會讓問題修復進展得更加順暢、大家的協作體驗也會更好。

以下兩點可以看作提高協作效率、推動問題修復的關鍵任務：

• 設計人員應當及時澄清待修復問題（開始修復之前）
• 研發人員應當快速明確問題修復的負責人員及完成時間

4、復盤階段

DSG第一個上線版本的設計驗收修復質量不佳，遺留問題過多。為了有效改善這個情況，版本上線后，設計人員組織研發人員、測試人員一起進行了該期設計驗收的復盤會議。會議主要圍繞著「明確遺留問題的處置方案」和「反思修復問題的限制因素」展開。通過復盤，我們主動發現本次驗收過程中的不足之處，并討論未來工作中的優化措施。反映到DSG項目來說，二期驗收修復率較一期提升了26.24%。

由于在項目實踐中顯而易見的顯著效果，復盤階段也被引入到標準流程當來。我們擴寬了復盤的行動范圍，首先由設計人員進行遺留問題的整理以及修復率等驗收數據的統計，然后據此判斷本次驗收質量。質量較低時組織全體性的復盤會議，明確后續改進方案；質量較高時則以更輕量的方式與項目團隊成員進行信息對齊，如我們目前采用的方式是：具體問題由相關責任人及時溝通；整體驗收情況與遺留處置計劃放到下一期的設計澄清會議上進行全體對齊。

三、驗收機制的體系化：一張表

建立起標準化的設計驗收流程后，如何進一步形成體系化的設計驗收機制來指導工作？我認為可以是對工具/手段的探索，如驗收結果的輸出內容就是一個不錯的方向。

設計人員向研發人員告知驗收結果的方式可以靈活多樣，但無數的經驗告訴我們，當問題數量一多，簡單的口頭溝通或面對面演示等方式在問題管理、修復追蹤等方面的缺陷就顯露無疑了。故在本驗收機制下，我們還提供了一個設計驗收表的內容模版。

這個驗收表采用「設計-研發共同編輯」的協作模式，畢竟設計驗收不是一個人或一個團隊的事兒，需要設計與研發乃至產品、測試多方的溝通與努力。

此外，我們目前還未針對該驗收表內部分需要細化的項給出范圍定義與填寫說明，如「問題類型」的囊括范圍、「嚴重程度」的判斷方式，這都有待后續完善。

找到一個可用的工具是第一步，怎么把工具用好則是接下來真正的挑戰。

四、驗收效果的量化：一個數據

那么如何度量設計驗收的效果呢？下圖是我們在DSG項目中對驗收效果量化所做的探索：

從實踐中沉淀，我們引入了“修復率”這個數值，他的獲取門檻較低，又直觀反映了問題的存在——

修復率=修復問題數/（驗收問題總數-無法修復問題數），其中問題總數=當期發現問題(新)+遺留問題(舊)；無法修復問題是指極少數現階段難以改變的問題，一般多是技術限制導致的。

隨后，我們可以通過同產品不同期、不同產品同期等對比方式來分析修復率，量化設計驗收；或者結合更多維度的產品體驗數據，對修復率的數值范圍進行劃界，進一步給出設計驗收執行效果的通用衡量標準。

當然，量化設計驗收效果，答案或許不止這一個，我們也將繼續探索并沉淀。如上文提到的修復循環次數的紅燈值，亦是一個不錯的切入點。

五、合抱之木，生于毫末

當然，本文構想的設計驗收機制仍處于初級階段，后續還有很長的路要走。比如以下幾個初步設想：

1、通過更多項目機會驗證該機制（包括階段設計、表設計等）的完整性、合理性

2、總結歸納四個階段在執行過程中的注意事項，形成指導原則

3、定義說明驗收表內部分使用起來存疑的信息字段

4、探索沉淀更多有價值的量化數據

5、深入考慮當前機制如何充分適應不同需求體量下的設計驗收

為團隊提效，為業務賦能，愿我們秉承初心，繼續探索行之有效的設計驗收機制。

轉載：人人都是產品經理

蘭亭妙微（藍藍設計）m.0391cbd.com 是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。

在電商平臺，中后臺系統工作龐大且復雜，而中后臺系統是否有規范的邏輯、是否有高效的體驗，則會體現在用戶的身上。本篇文章作者總結自身經驗，為我們總結中后臺體驗優化的思路和方法，一起來看看。

自 18 年 6 月底介入電商中后臺交互設計工作以來，筆者有幸做了很多和以往的交互設計不太一樣的工作，除了日常需求的交互設計支持以外，更多的精力放在了系統整體體驗提升和設計規范上。

本文整理了之前在中后臺體驗優化實踐中的思路和方法，如何從設計角度高效地優化整個系統的體驗，如何而非僅僅停留在表現層，希望能與大家交流碰撞。

一、問題背景

1. 后臺為什么需要考慮體驗？

在產品初期的時候，后臺系統只是為了支持前臺，實現功能即可，但隨著產品越來越龐大，每一個前臺的小小的功能優化，都可能是由后臺一整套支持體系，和一整個運營產品組來維護的。因此，后臺系統的體驗也時刻影響著團隊成員的工作效率，影響著一個產品在用戶面前的形象。后臺系統的體驗提升，并不僅僅是使用體驗提升，更多的是效能提升，和產品邏輯的規范。

2. 后臺系統體驗優化有什么不同？

系統體驗提升的任務，相較于其他工作，不同的地方在于交互設計師并非被動地接受某個單點需求，也沒有一個既定的模式去執行，而是要主動地去思考如何衡量體驗，如何全局地管理體驗，以及如何更好地規劃方案。在這樣的前提下，交互設計師更應該為全局的體驗負責，所以發揮設計師的主動性非常重要。

3. 如何去做？

基本思路是：衡量 → 收集 → 規劃 → 設計。

前三步都是與畫稿子無關的部分，但卻是非常重要的部分，在整個過程中，溝通非常重要，正因為后臺系統的業務專業性強，邏輯復雜，需求方多，所以需要更多地與各方進行溝通，調動大家的力量，一起來參與體驗優化。

二、衡量體驗，收集反饋

正如現代管理學之夫彼得·德魯克所說，如果我們不知道平臺的現狀，“提升”也就無從談起。

在 C 端產品中乃至部分B端產品中，我們有很多聰明的辦法去衡量一個產品的現狀，比如凈推薦值，跳出率，任務完成率，可以直接從數據觀察到用戶流失的環節，方便又客觀。但是對于公司內部使用的中后臺系統來說，一個是數據樣本量少，不一定能準確代表問題；更重要的是，不管體驗如何，用戶出于完成工作的目的，也必須完成系統的任務，所謂完成率和體驗沒有必然聯系。

當數據少的時候，不妨倒過來想，數據分析本來就是為大體量的產品客觀分析所有用戶的行為，而把每一個用戶抽象成了一組數據，再來綜合評估。那么如果你的每一個用戶都至關重要，且不需要花費太多的精力就可以與他們來一場面對面的對談，豈不是更有助于你去了解你的用戶？用戶訪談、可用性測試、用戶體驗地圖都是非常適合用在這種場景下的。

最終，我們在本次優化中選擇了 3 種方式來衡量系統的體驗：

1. 滿意度問卷，把抽象的體驗用用戶的主觀評分來衡量，具象到某個數值；
2. 用戶體驗地圖，整體定位系統痛點和機會點；
3. 流程時效，把時效的提升作為系統體驗提升的一個體現；

1. 滿意度問卷

一般來說，滿意度問卷在結構上會包含：產品整體滿意度，通用指標滿意度，業務功能滿意度三部分；為了精細化分析，我又添加了一部分用戶屬性的內容，和最后的開放性意見，主要是為了更好地幫助后續分析重點優化方向和搜集用戶意見。

在設計問卷的問題和答案時，不要用太過專業的術語，答案也不一定要用標準的五級量表（非常滿意、滿意、一般、不滿意、非常不滿意），可以更具象地去描述1-5級的答案，方便用戶選擇。

如上述問題，將比較抽象的 “系統穩定性” 轉化為“頁面打開速度和出錯頻率”來描述，答案也做了更具象的描述，方便用戶確定他們的滿意程度。

下圖是某個系統的功能滿意度，很明顯可以看到 D、E 模塊的滿意度是低于其他模塊的，后續可重點關注這2個模塊；同時，海外用戶的滿意度普遍低于所有用戶，確實在這之前海外用戶的需求，比較難觸達到產品組內部。

2. 用戶體驗地圖

滿意度問卷已經幫助我們客觀地了解到用戶對于系統的滿意程度，也有了一定的優化重點，但對于落地方案來說，還是比較籠統而零散。作為一次完整的體驗提升優化，還需要站在更全局的角度去仔細審視系統的每一個環節。

前面提到，中后臺系統往往有很高的業務壁壘，體量大，流程長，涉及角色多，對于某個單一角色來說，想要快速深入到系統底層，找出所有問題，是不現實也不客觀的。

對此，我的想法是，借助用戶和項目成員的力量，共創用戶體驗地圖。

用戶體驗地圖

用戶體驗地圖是產品設計中常用到的一種設計方法，它讓我們平時零散獲得的抱怨、吐槽，變成有序的階段體驗，直觀地呈現出用戶在每一個目標任務下的行為、思考、痛點和機會點。

在此不再詳述用戶體驗地圖的定義和使用方法，具體可參考螞蟻金服的實戰案例：https://www.uisdc.com/user-maps-design-ali-case#

中后臺系統共創用戶體驗地圖，要在擁有用戶意見的基礎上，邀請產品、技術、設計、業務方共同參與，當涉及多個業務方時，也需要同時邀請，一起來思考站在用戶角度的痛點，和站在自己角度可以提出的機會點。

往往此時，不同的業務方之間，以及和產品方、用戶方之間，視角不同，都會存在或大或小的利益沖突，大家共創的過程也是不斷碰撞、同步的過程。在大方向（提升系統體驗，促進業務成長）一致的前提下，所有人的意見是可以在討論中互相磨合，最終達成細節共識的。

在此過程中，有非常重要的一點，在于設計師要提前和各方確認好系統的主流程，并在會議上引導成員按照主流程框架來進行思考和討論，控制好節奏和話題走向，切記千萬不要讓體驗地圖共創，變成了七嘴八舌的「吐槽大會」。最終只是收獲到了一堆抱怨，卻沒有結論和共識。

提前確定好的主流程

最終的用戶體驗地圖

三、規劃方案，輸出設計

在有了較為全面的用戶體驗地圖后，我們就可以全局地去考慮系統體驗提升如何落地了。事實上，在共創的過程中，包括后續的整理中，我們可以看到除了業務相關的機會點外，許多體驗上的問題是相通的，例如：復雜表單填寫缺少規范、系統通知混亂、流程進度不透明、小屏幕展示不友好等等，雖然這些問題會出現在不同的業務模塊中，但是從交互設計的角度來說，它們的解決方案是一致的，可復制的。

可以和產品一起把這些需求仔細評估一遍，分為三個部分：

• 不需要設計方案的優化：一句話需求，系統 bug，讓優化先開始起來；
• 框架性設計或共性問題：導航、首頁、全局通知、表單填寫規范等，搭好框架才能在處理細節問題時更加高效；
• 不可復用的復雜設計：細節功能優化，涉及具體業務的底層邏輯變更，新功能等；

在此重點分享一下首頁、通知分級、流程節點透明化等參考價值比較高的框架性設計，也就是第二部分。

1. 首頁重設計

對于首頁改版，最重要的是明確設計定位，之后就是填充支撐定位的內容模塊，設計展現形式。

1）明確設計定位

作為一個以協同辦公為主的平臺，我們對于系統首頁的定位為：

• 新用戶-了解平臺的快速開始入口；
• 老用戶-處理事項的快速協同入口，業務激勵內容露出的看板；

2）填充內容模塊

由此，我們會需要官方公告、幫助引導、待辦事項、業務附能等內容模塊，可以根據用戶角色的不同分別顯示。

3）設計展現形式

2. 通知分級

當用戶抱怨通知消息太多，細細追究又發現每個通知都有必須存在的理由時，我想，可能是系統沒有做好通知分級。

正如我們設計每個頁面時會對頁面上的信息進行分級，給到不同的展示效果一樣，當系統龐大到某種程度，我們就需要對系統的通知進行一次「通知分級」。把重要緊急的消息直接傳遞到用戶面前，弱化一些反饋型通知。

所以就需要我們整理整個系統流程里需要提醒的事，以及確定它的重要程度分類，包括：

• 重要且緊急，需要用戶盡快處理的事，可以通過郵件、短信等系統外的渠道及時通知用戶；
• 重要但不緊急，在系統明顯位置給到提醒，保證用戶看到即可；
• 不重要不緊急，但需要給到用戶的反饋，例如某個流程完成的通知，可適當收起，根據用戶自身習慣選擇性查看；
• 甚至某些非常大量，且不重要不緊急的事項通知，可以考慮直接去掉，轉化到具體頁面中能查詢到即可；

部分通知分級示例

3. 復雜表單填寫優化

在中后臺系統中，經常會涉及異常復雜的表單填寫，不僅僅是內容多，而且每個填寫項涉及業務規范，缺少填寫指引，容易出錯，流程反復駁回，對接低效。

于是，在必要流程前添加了準備資料階段，列出了所有需要準備的資料，注意：

• 每個資料都需要有示例，并標注審核要點；
• 清晰描述資料的業務規范，容易遺漏出錯的內容需要高亮說明；
• 需要用模板填寫的資料提前給到模板；

明確的填寫指引，再配合針對審核人及時的通知提醒，目標將原來 41 天的流程時效降低到 21 天。

4. 流程節點透明化

中后臺系統會有非常多的流程協作功能，但是之前系統的做法僅僅是完成了流程的「功能」，卻沒有照顧到用戶的「心理」，沒有告知用戶每個流程應有的節點、規范、當前進度。用戶在等待流程推進的時候仿佛進入了一個黑箱，不知道現在的進度如何也不知道什么時候會完成，不僅是體驗不好，而且會浪費大量的人力、資源在溝通流程進度上。

所以在整體優化時，引入了流程進度模塊，清晰地展示了整體流程的節點，對應的操作人，截止時間，以及完成節點的操作記錄。這節省了非常多內外溝通的時間。

流程節點透明化

四、總結

以上，就是本次中后臺系統體驗提升的大致過程：

1. 定位系統體驗；
2. 收集各方反饋；
3. 提煉通用體驗問題；
4. 設計解決方案。

中后臺大多數業務復雜，體量龐大，設計剛剛接觸時會覺得無從下手，利用這樣的一套流程不僅能幫助我們與團隊成員一起優化系統體驗，還能讓我們深入到用戶場景，和各業務方、用戶方深入交流，對后續的工作也很有幫助。

筆者一直認為，雖然中后臺是前臺用戶看不見的地方，但后臺系統邏輯的規范，體驗的高效，最終會透過層層映射展現在用戶面前。對于電商來說，可能更多體現在發貨、物流、質檢等屏幕外的體驗上，但這也是產品體驗不可忽視的一部分，需要我們為此添磚加瓦，不斷加分。

轉載：人人都是產品經理

蘭亭妙微（藍藍設計）m.0391cbd.com 是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。