起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識體驗走查之——啟發式評估
編輯導語：相信很多人都聽說過用戶體驗走查，但你真的明白其中的內涵嗎？這篇文章作者詳細介紹了體驗走查之——啟發式評估的相關內容，感興趣的小伙伴一起看看吧。
今天，要講的內容是用戶體驗走查（User experience evaluation）。其中重點是：啟發式評估的相關內容。
首先明確一個前提：體驗走查不是考核。
不要簡單的挑界面上物理層的問題（顏色、字號、大小是否統一），這些只是基礎一致性問題，還要透過產品功能流程考量是否符合用戶行為，它們之間的映射關系是否合理，以及產品使用完成給用戶帶來的情緒變化，是否是正向的、積極的，是否符合用戶的認知。
體驗走查實際價值不是發現問題，而是改進問題，從而通過重新設計影響用戶體驗的因素，提升體驗。
體驗走查，是每個設計師的日常工作：
設計迭代前，通過體驗走查，發現現有產品的體驗問題；設計進行中，通過體驗走查，審視當前設計方案存在的體驗問題；設計開發時，通過體驗走查，審視研發還原時存在的體驗問題；設計上線后，通過體驗走查，發現真實環境中存在的體驗問題。
這是常見的幾種體驗評測方法，我們今天重點講的是，啟發式評估在日常項目中如何運用。
簡單說一下它的優缺點：
這個方法相對其他用體驗評測方法比較快捷簡便。它能夠提供有關網頁可用性的快速概覽，并凸顯出可能影響用戶體驗的一些主要問題；
啟發式評估在所提供價值和所需資源方面來說是比較高效的。相比其他的用戶體驗評估方法（例如問卷調研、用戶訪談等）成本更低；
由于啟發式評估不涉及用戶測試和用戶行為分析，所以缺乏“證據”，有時候可能顯得比較主觀（當然也有些改進型的啟發式評估，例如協作式、全景式，這些都有適應的場景和團隊，我們暫不細談）；
評估前需要簡單準備和培訓，但是成本低。
一、什么是啟發式評估？
啟發式評估法（Heuristic Evaluation）是一種用來評定系統（產品）可用性的方法。使用一套相對簡單、通用、有啟發性的可用性規則進行可用性評估。
最早由Nielsen和Moclich（莫里奇）90年代提出的一種由專家完成的產品可用性評估?法，由多位評估者對照一些可用性準則和依據自己的經驗來對用戶界面的可用性進行獨立的評估，啟發式評估的目的不僅是找出系統中潛在的可?性問題，更是為了改進問題。
有時侯產品的可用性不能夠完全依賴于沒有設計知識和經驗的用戶來實現。而且限于隱私、經驗等問題，用戶的真實想法并不一定能夠完整的傳達出來。因此通過設計專家（交互）對產品/原型評估，通過豐富的設計經驗來發掘問題并進行有效規避。
二、啟發式的主要特征
包含以下主要特征：
啟發式評估的其他特征（優點）：
快速/劃算：使用已擁有的內部團隊資源來管理評估；
靈活：在設計過程的任何階段都可以進行評測，評估線框圖、原型、線上產品——或以上所有；
詳盡：可以全面掃描產品當前的UX設計；
嚴重性評級：組織可用性問題，并根據問題的嚴重程度解決它們；
可用性原則：遵循一組啟發式準則可以識別特定用戶流程中的問題；
兼容：可以同時結合其他可用性測試方法。
三、什么情況下使用啟發式評估？
啟發式評估并不限于某個特定的時間段或產品階段，在任何需要交互專家來評估和驗證方案的地方，都可以使用。
甚至你可以理解為，設計團隊內部討論某個方案或者某個交互細節，這時候找來設計主管給出指導，這也是一種形式的啟發式評估。
啟發式評估可以發生在原型測試階段，按照正常的設計流程，原型階段正是驗證想法以及測試可用性的階段，在此時發現可用性問題并進行糾正的成本最低，因為產品尚未開發，沒有投入太多資源。
對于已經上線的產品仍然可以進行啟發式評估，甚至已上線產品更接近真實產品，因此結合用戶的反饋，更容易找出最終的可用性問題。只是修改成本變得略高一些。
補充：一些大型復雜系統項目或重要變現業務需要嚴謹的、基于數據實驗的用戶體驗流程。
然而，很多規模較小的快速跟進項目通常要求更快、成本更低的評估方法（與基于用研和實驗評估相比），很多時候我們希望能夠以較低的代價實現較大的效果，而啟發式評估就是典型代表。我們將這些評估方法稱為“經濟評估法”。原因是它們更快速、更節約成本。
要讓全員參與到體驗走查中來，我們必須為全員提供一個簡單、易懂、可信賴的體驗走查參考標準。方便全員日常和專項走查時，能夠以此為參照，正確、全面的發現并表述體驗問題。
而尼爾森10大可用性原則一定是我們要參考的經典設計準則。
以下是對尼爾森10大可用性原則的重新梳理。它們是有關交互設計的非正式準則、經驗法則或通用方針。
這個時候，有的同學會質疑？尼爾森10大可用性原則都過去二十多年了，還適用于當下的產品設計嗎？
先說一下，我的感受存在幾個階段的變化：
初識尼爾森10大可用性原則，哇！這么精煉的設計準則，這不就是設計方法論嗎？
而做了幾年設計之后，更多大廠開始玩起了數據分析，有部分人質疑槽尼爾森那一套東西東西過時了，當然，我也曾這樣覺得…
再識尼爾森10大可用性原則，今年有機會深入的再次研究了10大原則，并用我蹩腳的英語逐個單詞親自翻譯了一遍。
深刻的發現，市面上各類解讀文章翻譯的太不準確了，而且最初10大原則適用的是Web端的產品設計，但是各類文章偏偏愛拿移動端去做例子…
仔細研究發現，尼爾森對于這些準則的抽象很精煉，與其說是設計通用準則，更多是關乎用戶產品使用過程中的心理變化注意事項。
因此，我認為它并不過時，特別在B 端的工具型產品，依然是很高級、精煉的設計通用準則。
以下是尼爾森本人筆記中回顧：
Jakob的筆記：
我最初于1990年與Rolf Molich合作開發了啟發式評估的啟發式方法[Molich和Nielsen，1990年；Nielsen和Molich，1990年]。四年后，我根據對249個可用性問題的因子分析[尼爾森1994a]完善了啟發式方法，以得出一套具有最大解釋力的啟發式方法，從而產生了這套經修訂的啟發式方法[尼爾森1994年b]。
2020年，我們更新了這篇文章，添加了更多解釋、示例和相關鏈接。雖然我們略微完善了定義的語言，但自1994年以來，10種啟發式本身仍然相關且保持不變。當一些事情已經存在了26年時，它也可能適用于下一代用戶界面。
當然畢竟過去20多年，放眼當下產品設計，根據評測項目不同，是允許由團隊對評估原則進行調整和修改；而評估原則的制定是核心難點，建議通過團隊協作的方式制定，并定期補充和改進。更多詳細的“UE體驗走查問題分類及歸因”可參考，另外一個文檔表格。公眾號回復“UE體驗走查問題分類及歸因”獲取。
說了這么多，我們講一下啟發式評估的實施流程
啟發式評估的整體流程主要包含：組織評測人員、制定評測計劃、實施具體評測、召開評測會議、總結評價結果5個部分。
評測人員數量確定
按照尼爾森2000年的實驗，一個人評估大約能發現35%的問題，經過公式計算，大概5人就可以發現：50%-95%問題，其平均值為85%，余下20%，通常也是一些重要程度不是那么靠前的問題。
這只是個參考，我認為人數不是重點，重點是事情我們要去做，持續走查缺陷并推動解決，再好的評測方法也不是一次就可以解決所有問題的。
除此之外，還有一些評測過程中需要注意的要點，也是我們要注意的。
同時，根據缺陷對系統可用性所造成的影響，把可用性問題按照其嚴重性分為4個等級。這是對于發現問題嚴重性的定義描述，需要設計師在評測前學習掌握，因為個人差異對于問題嚴重程度的理解不同，我們需要統一標準。
以下是具體頁面評測格式示例：
可用性缺陷包含兩個方面和四個因素：缺陷的位置及標識；問題及依據。
一個可用性缺陷就是用戶界面中特定位置的某個特特征或設施，要通過某個特點問題或困難來加以描述，還要根據某些原理或依據說清楚為什么它是一個可用性問題。
需要注意的是：我們的評測不只是提問題，還有考慮問題的嚴重性（緊急度），所以我們又做了問題嚴重性的等級劃分，從一般問題到嚴重問題劃分為4個等級。
另外一點是：我們不只是在挑錯，描述問題的同時，我們還要分析原因，并盡量提出合理化建議。這樣客戶看到的分析才是有理有據，不僅發現了問題，還有解決思路。
四、評估問題匯總
在整體功能流程我們走完，要做問題的整理匯總，填寫體驗問題記錄表。這樣便于客戶查看，也便于我們最后做匯總整理。而且，所有問題的類型、嚴重性、數量都會有編號，這樣我們整理時，統計編號就好了，整體效率會更高。
五、收集了一堆問題之后的處理
通過小組會議討論，把相同/相近的問題統一，可優化的問題保留下來，不是體驗或可用性的問題的去掉，然后整理到一起。這些就是評測范圍內存在的大大小小、各式各樣的問題了。
可視化整理，便于直觀感知：
首先，對問題記錄進行歸類，以模塊橫向對比或流程區分。例如：把首頁/課程中心等頻道頁做為模塊用圖表形式展示問題數量分布，可視化對比各模塊問題數量及嚴重程度分布情況，一目了然。
體驗評測結果量化：問題數量/問題嚴重等級
看到問題數量，大家肯定嚇一跳，但這就是啟發式評估的特點，也是存在的問題：容易查出的問題太多了。因為基于多位成員的評測，及自身經驗的不同，在統一評價標準下雖然已經避免一部分主觀因素，但是還會存在發現大量問題的情況。
不過這并不要緊，因為即便如此，用戶實際中的大半問題已經被我們預測出來了，剩余的問題也不能說沒有意義。其中仍然代表廣泛用戶的心聲。
當然，最后我們肯定話鎖定主要問題進行解決，以及確定問題解決的排期和優先級。
以B2B電商的下單流程為例：
宏觀展示，各模塊問題嚴重性分布，主要在哪些模塊中，任務流程前后問題出現的線性關系。
堆疊面積圖和基本面積圖一樣，唯一的區別就是圖上每一個數據集的起點不同，起點是基于前一個數據集的，用于顯示每個數值所占大小隨時間或類別變化的趨勢線，展示的是部分與整體的關系。
體驗走查完成并不代表結束，如何推進后續優化方案才是重頭戲
首先需要PM及研發團隊的認可走查結果，這涉及信度問題，在方法概述中，已提到。
啟發式評估天然存在精度不高的缺陷（受評測人員經驗、評測方向、人數等多方面因素影響），所以我們在信度上只能相對的，以通用準則統一評測標準；以商業B端常見度量指標為評測方向、以競品相似功能的良好體驗為橫向佐證。
發現一個可用性缺陷并不意味著必須處理它。至于糾正還是暫時擱置所發現的缺陷，這是一個技術性的管理問題，取決于缺陷的嚴重程度、糾正缺陷所需的費用及現有資源的多少等多方面因素。
體驗走查的宗旨始終是：即使在發現缺陷之后決定推遲糾正缺陷或忽略這些缺陷，但知道問題出在何處總比不知道好。
六、總結
那些對產品有較大影響、極為復雜的可用性問題，估算其資源消耗可能比較困難，但對其他的可用性問題改進消耗的人力和工時還是可以粗略估算出來的。
歸根結蒂，這是一個管理問題，即根據受影響范圍、修改問題所需的資源、現有資源情況等因素，對是否以及何時著手解決已發現的可用性問題做出相應的決定。
經常有這樣的情況，有些問題一直拖到后期才得以解決，有些則可以完全忽略。因此，這樣的決策非常重要，是靠理性而不是隨便做出來的。
發現問題并不意味著必須要改正這些問題，但是了解一下所有存在的問題總比忽視不管要好一些。
當體驗問題收集上來后，根據體驗問題評估標準，對其進行分級，并按照問題嚴重級別，分步推進：所有嚴重/致命的體驗問題，直接轉化為需求，提到項目側優先解決。
一般和輕微問題，則由設計師以功能模塊為單位，按照功能的重要性和問題的多少進行分類：（a）對于問題比較多的模塊，設計師先設計解決方案，再推動到項目側解決；(b) 對于問題比較少的模塊，則等到日常需求迭代時，把遺留的體驗問題納入一起優化。通過這樣三步走的方式，逐步推進所有體驗問題的解決。
作者：UX老王；公眾號：體驗為王
原文鏈接：https://mp.weixin.qq.com/s/KyIXU795hD99Xd5Qa7whMg
本文由 @體驗為王 授權發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
學到了
遵循這些法則，能夠讓你離用戶更近，做出體驗更好的產品。給文章點贊。
之前有聽說過用戶體驗走查，看完這篇文章才真正了解了它的內涵。