如何做啟發式評估 Heuristics Evaluation？（上-準備篇）
想像有個情境，公司預期在 2–3個月內上線產品的迭代優化版本，產品經理咚咚咚的跑來，拿著這個小朋友（產品當前版本）來找你。
「阿～你可以幫我看看這個嗎？」
如果你恰巧身為 UX 設計師、研究員或產品設計師，甚至產品經理，可能對上述的情境心有戚戚焉，有過貼身經歷或正遇到類似的需求。
這篇文章想分享，我們如何以設計研究來分析產品問題，幫助產品團隊，給予優化建議，另一方面也算幫助自己紀錄工作中的經驗，總結得到的想法。
今天我們就來談談傳說中的啟發式評估 Heuristics Evaluation （或稱為介面經驗法則評估）吧！
近日接獲一項需求，公司想在其中一項產品上線前，了解產品有沒有操作或介面上的問題。於是～就換我們上場啦～
為什麼要做啟發式評估？
啟發式評估可以帶來什麼好處？簡單來說，其實很多研究方法都可以帶我們分析或發現產品的易用性問題，例如流程順不順利？介面上有沒有容易讓使用者誤會或操作錯誤的地方？
那為什麼我們要選擇用啟發式評估來做研究？這就要說到啟發式評估跟其他研究方法相比，可以帶給我們的好處。相比於成本較高，需要找尋、篩選真實使用者條件的易用性測試，啟發式評估可以以較低時間成本且快速的方式找到產品流程或介面上問題。相比於更簡單的認知走查，啟發式評估可以發現更深入且有效的問題。
所以如果產品在上線前，時間與設計還有些可調整的空間，團隊可以規劃 1–2 週進行產品的啟發式評估，了解目前的版本有沒有可能的操作性問題，作為上線前調整項目的依據。
如何訂定評估標準？
既然要評估產品，想當然爾一定有一套評估標準或依據。我們 UX 設計師或研究員可以依據產品本身的特性或階段，訂定一套評估準則。
「可是目前團隊難以訂出一套評估標準，該怎麼辦？」
沒關係。普遍來說，如果想要找到產品可能的易用性問題，我們可以透過易用性大師 Jakob Nielsen 與他同事開發完成的專家易用性評估方法(1994)，也就是我們熟悉的「十大易用性原則」，來幫助我們進行。
十大易用性原則網路上蠻多資料的，下方我有稍作翻譯，建議也可以看原文。如果有需要，在 NNgroup 的網站中也有對應的 pdf 模板與適應相關產業的評估準則說明可以參考～
介面十大易用性原則 10 Usability Heuristics for User Interface Design
- 系統狀態的能見度 Visibility of system status
設計應該保持相同的模式，透過適當的回饋反應機制，在合理的時間內通知使用者，讓使用者了解正在發生的事情。 - 系統與真實世界的關聯性 Match between system and the real world
設計應該要運用使用者的語言，使用他們熟悉的詞句、短語、概念，而非專業術語。遵循真實世界的語句習慣（natural mapping），自然且合邏輯的順序出現，幫助理解更直觀。 - 使用者的操控自由 User control and freedom
使用者時常「試試點擊看看」來測試產品功能，他們需要一個明顯的「離開」，且不需要太多步驟，以來結束不想要的操作。 - 一致性和標準 Consistency and standards
使用者不應該在介面中需要猜測不同的字彙、狀態、動作是不是代表同一件事。 - 預防錯誤 Error prevention
設計上提供易於理解的錯誤訊息是重要的。不過比起提供訊息，更重要的是防止使用者發生錯誤。例如去除容易出錯的情況，或在使用者要提交時，提供確認的選項幫助檢查。 - 辨識而非記憶 Recognition rather than recall
盡量減少使用者需要記憶的事情、行動以及選項。 - 彈性與使用效率 Flexibility and efficiency of use
思考如何滿足不同操作經驗的使用者，包含新手與老手。例如快捷功能可以幫助老手操作，但對新手來說可能不太必要。我們可以提供快捷或自定義的按鈕，讓使用者選擇他們希望產品如何工作。 - 美觀與簡化設計 Aesthetic and minimalist design
介面不應該包含不相關或很少需要的訊息。每一個多餘的訊息都在與必要內容競爭使用者的注意力與降低相對的可見度，我們應明確的定義與了解每個訊息對使用者的重要性。 - 幫助使用者認識、偵錯並從錯誤中恢復 Help users recognize, diagnose, and recover from errors
當使用者發生錯誤時，我們應該用通俗的語言說明，精確指出問題與提供解決方式，而非難以理解的代碼。 - 幫助與說明文件 Help and documentation
如果系統不需要任何額外的解釋，那是最好的。但是，我們還是可能需提供說明文件，來幫助使用者了解如何操作系統完成任務。
另外，產品的不同成長階段可能有不同的評估目的，我認為，團隊可以評估自身的需求來調整欲使用的原則。
通用的易用性原則可以是評估的參考標準，但不一定是唯一，取決於設計師、研究員或產品團隊一起深入思考與討論產品本身的特性與開發的階段，不一定每一條都要適用。以最後一點（第10點）的產品說明文件為例，我們可以思考這是此階段我們需要著重的評估標準嗎？產品目前提供了哪些功能？之前是如何與使用者說明或提供幫助的？我們是否有更有價值的評估角度？
不是有句話嗎，「規則是死的，人是活的。」也是一樣的道理。
開始規劃一次啟發式評估
明確、詳細地撰寫一份研究企劃書是重要的。
在了解研究需求，開始進行研究前， UX 設計或研究團隊可以擬定一份研究企劃書。企劃書會包含幾項內容，例如：研究目的、研究方法說明、如何執行研究、篩選找尋的研究對象與其背景需求、如何執行…等。由團隊一起梳理此次研究的目的、方法和整體規劃，幫助確認研究共識，確保大家之後分工研究時，不會有理解或分析方向偏誤，讓後續合作更順利。
確認研究的流程與介面
「要研究哪些項目內容呢？」每個研究開始前，大家可能都會疑惑。
一般來說，各方都可以提出希望研究的操作流程或特定產品介面，例如，客服團隊可能提出哪個頁面或流程尋求客服支援的頻率最高，或者工程團隊近期開發了一個新功能，希望獲得一些評估建議。產品的 PM （Product Manager）接獲並理解各方需求後，與大家一同討論，彙整成此次希望研究的共識項目內容。再由我們設計師或研究員接手，確認需求後將項目吸收轉化，製作成評估人員的任務清單。
另外，在完成研究規劃後，我們也可以向產品團隊的其他成員或 stakeholder 分享研究目標與執行流程唷！讓成員們知道研究員正在進行的項目與了解之後可以獲得的成果也是很重要的，除了可以加強團隊的參與感，也可能獲得意想不到的幫助呢！
「誒～我記得XX部門的XXX好像蠻懂這個，或許可以問問他的意見！」
「哇～太好了。」
以啟發式評估來說，我們會找尋具有產業或設計相關背景的專家來擔任評估人員，雖然越多人協助測試越好，尤其有不同背景的評估人員時，團隊更有可能發現不同的問題，但人力預算和時間限制通常會影響項目評估人員的數量，普遍來說大約3–6人足以發現大部分常見問題。
當然我們在找專家評估者時，會需要排除產品本身的設計師或團隊夥伴，因為他們太熟悉產品了，可能已經被教育啦😂。
邀請評估者
確認邀請的對象後，我習慣開設一個通訊軟體群組，把評估人員與設計師、研究員都加入。在群組和大家溝通時間，公告評估的進行流程或預先提供一些表單，讓大家可以先暖身熟悉。另外，測試日期的前幾天也可以在群組中和大家多聊聊天，活絡下溝通氣氛與提醒大家評估日期。避免評估人員忘記，研究員…被….放鳥。
這次很幸運的，在公司內部有找到具有對應評估背景需求的同事，請他們協助進行研究，大家都很樂意幫忙與提供自身的想法，讓這次研究很順利且效果良好、收穫滿滿。
下一篇再來與大家分享如何做啟發式評估下篇－執行實戰！
Hi 我是 Julia，
希望可以透過工作與生活紀錄，分享 UX /產品設計師的日常，甚至更多幫助世界一點點。如果覺得這篇文章不錯或有幫助到你，歡迎幫我多拍拍手（鼓勵長按50個拍手👏）或轉發給朋友唷！
如果想要與我討論或聊天，也歡迎在文章底下留言～