編輯導語：B端的走查過程需要看各項指標數據以及業務、組件等是否搭配得當，同時也是對許久為參與的項目產品進行一致性的修改，并整理出一套可行并且規范的標準，用于應對后續新的設計。本文對設計走查過程進行了一個詳細的梳理，一起來看看。

前言：B端的走查過程和C端差異的比較明顯，看數據、看業務、看操作，看組件是否搭配得當。從設計角度來看，結合交互，結合部分的業務需求、業務場景去來完成這個過程。

需要對長久未參與的項目產品進行一致性的修改。也借此做一次設計走查，整理出一套合適的規范標準需要設計、開發遵循，來應對新的需求。

搞清楚幾個問題：

1. 什么時候做設計走查
2. 為什么決定要做設計走查
3. 怎么做設計走查

一、什么時候做走查

以真實內容說明這個問題。

參與的項目，開發到現在兩年了，持續迭代中，目前階段處于平穩迭代中。平穩期間開始做走查任務。

原因：初期項目開發，業務復雜，場景變化多，現成的前端框架能夠滿足需求，后續的項目推進，加入更多的場景，更多的需求，前端被迫忽略了組件規范要求。

目前：操作上出現的問題也越來越多，控件套用，體驗上的問題也顯著出現。比如說標簽導航，也用作按鈕功能；切換篩查標簽也當作按鈕使用了

二、為什么決定要做設計走查

對小公司來說，做走查不是件容易的事，所以只能邊走邊看，邊修改邊完善。

通過和產品進行一個小時的討論，主要有以下幾點：

• 前期設計參與，有對布局一致性有把控，在之后一年多時間，設計退出，問題出現了；
• 討論過程中，容易偏離主題（比如開始是討論布局間距，到按鈕，之后容易被場景帶入，聊到按鈕應用場景，越來越偏離中心）；
• 系統中存在組件混用，濫用情況。

希望設計給出一個標準化的規范指導界限，明確哪些內容應該怎么做，做到什么程度。盡可能避免一些操作上的問題。

三、怎么做設計走查

1. 找問題

所見即所得，引起大家共識，明白哪里的問題。

把所有不合適的，不準確的頁面截圖，找出來，合集到一塊，再對這些截圖進行分類，并配相應的文字說明。

一定要找全類型問題，一定要，一定要，重要事說三遍。

只有問題找全才能更全面解決好問題。

找問題的方式，等同于設計組件前期的對所有問題組件的歸納分類。

2. 分類

找完問題后需要對這些問題進行分類，從兩個角度考慮：

一是從數據組件的分級（即組件的應用）；二是從業務的核心度，將涉及主流業務打上標簽，便于優先處理；三是考慮擴展性，數據是動態的，所以在邊走查邊考量擴展性。

這里不對數據組件進行特別的說明，組件從設計規范的時候就已經有完整的交互樣式了，但在走查表中也要標識出來。組件不能滿足的業務需要的才會增加新的組件。

走查主要從操作業務流程出發，檢查組件應用的合理性，即組件是否滿足場景需求。

帶著業務場景去操作一遍，通用的方式，了解主流程，操作分流程，分流程完成了，主流程不會斷。

整理操作依據表（業務相關的，還是由產品出）。

對于查找出的問題，也將其區分等級：

緊急：數據丟失、缺失，功能不可用，按鈕點擊無反應；

嚴重：功能設計與需求嚴重不符，數據結果錯誤，程序接口調用錯誤等；

一般：功能未實現但不影響使用，操作時間長，數據字段過長，頁面樣式（頁面布局不規范、顯示重疊、不該顯示不隱藏、描述不清，晦澀難懂未注釋、默認提示不準確、文字排列不對齊、光標圖標寓意不正確）；

次要：建議問題，不影響使用，只是體驗差點；

與之相對應的處理等級是緊急處理、優先處理、一般處理、暫不處理。

3. 實施

找茬小分隊的人員分配。

產品主要找緊急與嚴重等級的，設計主要找一般和次要的以及部分嚴重等級的。其他人根據上邊的表格查找流程的問題。將體驗出的問題以表格內容記錄下來，并給這些問題標記路徑、等級和處理等級，以及修改建議。并將重復內容合并。

之后將開發（前端+后端）也拉出來，展開一次會議討論，將問題處理人指派到人。

四、總結

建立一套規范切切實實的讓組成員遵守規則。也通過每一次的總結，將每一次的任務內容沉淀下來。

本文由 @Ychen（啊嗚計） 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議