起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識聊一聊，B端體驗走查
編輯導語：通過設計走查，我們可以及時發現產品設計中可能存在的問題，進而提前或快速地解決問題。而體驗走查是設計走查中的一種，可以幫助設計師站在用戶體驗的角度，推動產品的迭代優化。那么，B端產品的體驗走查應該如何行進？本文作者做了總結梳理，一起來看一下。
一、什么是體驗走查
1. 概念
體驗走查是設計走查的一個類型，設計走查顧名思義是根據一定的設計標準和設計原則，對產品中的設計方案頁面從頭到尾進行一次問題的發現與總結，便于修改與完善。體驗走查則是站在產品用戶體驗的角度出發，以這個維度進行界面中的問題發現。
體驗走查類似于我們去醫院體檢，按照一定的檢查項目對身體進行檢查，最后得到一個體檢報告，根據體檢報告看出身體的健康狀況。
2. 復雜性
走查的過程是復雜的，需要設計師一定的積累。
在一定程度上，B端產品是一個復雜的系統，產品牽涉到場景、用戶、業務等多個因素。對產品優劣的評價，也不是一句話一個角度就能說清楚的。對于設計師而言，產品設計優劣不能僅僅是好與壞的評價，而應該有更加精準的評價，好在哪里以及為什么好。因此，對設計稿的走查需要較為客觀全面的維度。
在實際的項目中，作者通過實踐，整理一份較為成熟的B端產品的設計走查流程，和大家分享一下我個人的經驗，也希望能得到你的反饋和交流，讓我們之后的體驗走查能更有成效。
二、為什么需要體驗走查
1. 體驗走查的使用場景
體驗走查的優勢在于快速評估產品的用戶體驗，發現鏈路中的關鍵問題。因此非常適合周期短、對時效性要求高的項目。
體驗走查可以服務于整個產品生命周期，在上線前用于發現方案未覆蓋的用戶需求，加深內部對用戶的理解，為新產品功能和設計賦能，確保新流程合理、風險可控；上線后，可用于搜集體驗問題，為產品后續優化迭代輸出建議。
B端產品相較于C端而言，產品功能多，角色復雜，業務龐大，，在項目前期難免會出現產品的各種問題，通過及時的走查能夠快速發現問題并解決問題。同時從體驗角度出發，去評測某些核心高頻功能是否能夠達到體驗目標。
2. 走查工作的時間和頻率
1）研發大版本決定
走查的頻率可以根據研發的大版本來確定，例如作者所在的某B端產品公司內部進行一次產品大版本更新和發版，那么體驗走查的時間可以定在正式發版前的一個月進行。
選擇這個時間發版，可以保證提供給客戶的產品及界面經過了我們設計師的走查后保證了更高的一致性和合理性，還能避免在發版后由于少了必要的檢查而出現大的系統bug。
所以各位設計總監在制定年度計劃的時候，可以根據產品大版本迭代的發版時間來規劃我們體驗走查的時間，整個走查的計劃時間也不能太長，在我們發現問題后需要留給開發一些修改時間，這個時間在一周左右是比較合理的。
2）時間和需求數量決定
第二種確定方法可以根據研發時長和需求數量來確定。
比如每個季度一次或者在研發的需求達到一定的數量級以后，可以進行一次體驗走查。在產品團隊所完成的需求達到一定的數量之后，功能以及界面的質量可能會出現下降，所以需要我們設計體驗團隊針對產品需求界面進行體驗走查，從而提高各個需求功能點的質量。
3）日常任務
接觸一個新產品，優化一個舊功能，驗收一個新特性，階段性的點檢整個產品的體驗，可以說體驗走查一直貫穿著設計師的日常。
- 設計迭代前，通過體驗走查，發現現有產品的體驗問題；
- 設計進行中，通過體驗走查，審視當前設計方案存在的體驗問題；
- 設計開發時，通過體驗走查，檢查開發在還原時存在的體驗問題；
- 設計上線后，通過體驗走查，發現真實環境中存在的體驗問題。
所以設計師的體驗走查工作不僅僅有助于提高產品的交付質量，也能夠讓設計師快速了解業務，快速成長。
三、B端對比C端體驗走查差異
1. 產品側重點差異
B端的走查過程主要關注數據、業務、操作路徑和效率，看組件是否搭配得當。從設計角度來看，結合交互，結合部分的業務需求、業務場景去來完成這個過程。
C端的走查過程集中在操作性和數據反饋方面，對某一功能操作以及埋點數據進行走查。對于未達到體驗目標的功能進行操作漏斗分析，找到其中數據未達預期的原因，提升數據。
2. 體驗目標差異
很多中小型的B端產品公司，在產品初創期時往往更注重功能的實現模型，而忽略了表現層和用戶心智。
市場上很多的中小型B端產品公司都是開發擔任產品經理，通常會從實現角度出發去考慮功能，有時候會忽略產品的體驗。所以對于這個階段的產品來說，體驗的走查目標更多是要發現界面中的問題和使用體驗方面的問題。
C端產品相比于B端，往往都是小而美的產品。這也間接體現了產品業務不同而導致的目標差異。
C端往往用戶人群簡單，業務簡單，沒有太多的專業壁壘，操作簡單的情況下產品更希望各個功能能夠達到體驗目標。打開一個產品，找到你準備走查的第一個頁面，從本能層次出發，去體驗當前頁面的設計是否主次分明、合理、一致。作為設計師，在本能的感官層面，我們要求當前頁面的設計，一定要好看、好懂、好找、好點。
3. 走查過程差異
1）走查前期首先會制定計劃，確定走查范圍
由于B端產品架構和功能頁面很龐大，在有限的時間內不可能走查完整個系統所有頁面，所以需要確定走查的范圍和所涉及的功能版本。
2）確定體驗走查量表
由于B端和C端產品的差異，導致兩類產品在體驗量表上使用標準可能會存在一些差異。
最常見的可用性量表——尼爾森十大可用性原則，但是從1995年提出到現在，已經過去了二十多年，互聯網世界已經發生了巨大的變化。
在這樣的情況下，尼爾森的十大可用性原則明顯有些不那么符合，或者說不能給出針對現今產品太全面的啟發。各大用戶體驗部門會針對產品的實際特性重新整理了一套可用性原則，以更適應現代的C端產品。
四、如何做B端的體驗走查
1. 確定走查計劃和范圍
在走查開始之前會確定走查的范圍和大致計劃，例如走查涉及到哪些產品、哪些模塊、使用哪個環境。詳細的走查計劃能夠讓我們設計師了解到走查的內容和計劃，我們可以按照計劃內的時間進行走查任務分配和規劃。
走查計劃可能并不一定是由設計體驗部門牽頭發起的，但是作為設計師我們也需要了解。完整的走查計劃需要包含如下內容：
走查目標、產品的版本、所涉及的產品的功能模塊、走查時間、報告時間、項目組問題修改時間、復查等。
2. 制定走查標準
1）走查標準表
體驗設計部門需要針對產品制定走查標準，最常見最經典的是尼爾森十大可用性原則量表。做交互的童鞋們應該很清楚尼爾森十大可用性原則，我們在做體驗走查的時候很多標準都是根據十大可用性原則來測試判斷的。
尼爾森的十大可用性原則，但是從1995年提出到現在，已經過去了二十多年，互聯網世界已經發生了巨大的變化。在這樣的情況下，尼爾森的十大可用性原則明顯有些不那么符合，或者說不能給出針對現今產品太全面的啟發。
在這種背景下，很多產品的體驗部門重新整理了適合自己產品的一套可用性原則，使得可用性原則更針對現今互聯網產品，基本可以覆蓋到所有出現的用戶體驗問題。
例如：京東最新21條可用性原則、VIVO體驗問題評估標準V1.0等。
我們可以在尼爾森十大可用性原則的基礎上去制定適合自己產品的可用性原則，也可以在其基礎上進行簡化，使其適合B端的產品。
2）走查問題評估等級標準量表
在產品頁面中出現了某項問題，我們需要針對這項問題的嚴重程度進行評估，每個等級對應的評估標準也會記錄下來方便定位，問題通常分為四級：致命、嚴重、一般、輕微。
問題越嚴重處理的時候優先級越高，后續輸出走查報告的時候開發需要優先處理優先級高的問題。
3. 體驗走查思路
走查時有一個思考的路徑就是想要優先解決什么體驗問題，第二要解決什么問題，進而開展走查的過程。
走查的思路可以是由下至上的，首先關注產品的底層可用性問題，基礎體驗是否理想、基礎視覺體驗是否合理統一規范、使用的組件是否符合規范等。往上一層是體驗層面的內容就是用戶體驗是否足夠友好清晰；一些反饋的關鍵的信息，視覺上能不能起到決策的效率是否突出。
最頂層就是認知品牌傳遞層面的內容。就是整個產品設計是否體現公司與產品的品牌價值，是否符合產品的特性。
走查的思路上，可以沿著思路從最基礎的問題去建立，把基礎打好，才可以解決更上層的問題。
找完問題后需要對這些問題進行分類，從三個角度考慮：
- 從規范UI樣式考慮（即組件和規范合理性）；
- 從體驗操作反饋，反饋與操作保持統一；
- 考慮品牌傳遞價值，產品所傳遞的價值是否符合品牌傳遞價值以及符合品牌的特性。
4. 輸出體驗走查報告
對于查找出的問題，也將其區分等級：
- 致命：數據丟失、缺失，功能不可用，按鈕點擊無反應；
- 嚴重：功能設計與需求嚴重不符，數據結果錯誤，程序接口調用錯誤等；
- 一般：功能未實現但不影響使用，操作時間長，數據字段過長，頁面樣式（頁面布局不規范、顯示重疊、不該顯示不隱藏、描述不清，晦澀難懂未注釋、默認提示不準確、文字排列不對齊、光標圖標寓意不正確）；
- 輕微：建議問題，不影響使用，只是體驗差點。
與之相對應的處理等級是緊急處理、優先處理、一般處理、暫不處理。
產品體驗流程梳理優化，主要分為三大部分，流程優化、功能優化、視覺優化。下面逐一詳細說明。
- 流程優化：我們是否要保留兩套流程，如果保留，要分析出核心流程是什么。利用核心流程引導用戶。對于非核心流程的關鍵環節進行優化，某些頁面、交互對用戶是否存在干擾。
- 功能優化：對于冗余、復雜的功能進行刪除或者合并，文案的整理修改優化。
- 視覺優化：優先級最低的優化，頁面結構、信息層級、顏色控件等細節優化，情感化元素的增加修改。
根據走查結果輸出一份體驗走查報告，并設置好開發的負責人，以及修改時間。將文檔整理好后通過正式郵件發送給產品部門。
5. 推動體驗問題解決
產品部門在接到走查報告后，需要根據問題進行修改，其中部分問題可能需要設計師的配合，例如UI樣式方面的問題需要重新進行UI設計；體驗流程方面的問題需要重新進行交互設計。在遇到需要設計部門配合的時候，我們設計師一定要積極響應產品部門的需求，早點修改完問題早點結束走查。
同時對于產品部門不愿意修改的問題，設計部門也需要及時跟進，了解他們不修改的原因。這些原因需要備注好，并要求產品部門承諾修改時間。
在問題修改完成后，設計部門會進行最后的驗收，在驗收過程中將有問題的地方進行再次走查，問題修改完成后我們就算進行了一次完成的體驗走查工作了。
本文由 @晨屹 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
致命的其實就是bug
入職第一周，產品團隊讓一周輸出產品體驗的問題報告，然后就通過尼爾森十大原則和5E原則對產品進行了一輪走查，走查出來10+個體驗問題，但是在迭代的過程，領導覺得解決這些問題太小了，不值得啟動研發迭代優化。讓設計啟動更大一輪的用戶調研與需求定義，這個局，設計要怎么破嘞。
走查出來的問題，肯定是需要設計和開發及時去解決的。這樣保證了產品更新迭代的頻率，產品發版交付肯定都是有時間的，小改動才能趕得上迭代計劃。
領導覺得解決問題太小，說明領導還是很重視產品質量的，這是好事。但讓設計重新調研改進，這樣時間成本非常高，設計出現了大的改動，開發有時間做嗎？這些環節都是有時間計劃的。
設計可以在固定的時間和頻率按照領導的計劃去開展更大一輪的調研，可以作為團隊的季度計劃，提前與其他研發線成員溝通好~
問題修改完成后我們就算進行了一次完成的體驗走查工作了。我們也是這樣子
可用性原則更針對現今互聯網產品，基本可以覆蓋到所有出現的用戶體驗問題。