大家都知道“可用性測試”是做什么的，它能判斷產品易用性的好壞，指明產品后續的改進方向。但是有多少設計師真正利用好可用性測試這個強大的武器，若沒有適當的武器捍衛自己的設計，那么你會處于如下境地。

交互設計師的尷尬境地

作為交互設計師的新人小白通常都會遇到這樣的一些人和事：

1.對設計過多干預的產品經理

這類產品經理在提及需求時，大多腦海中已有大致的原型效果圖，即使不十分明確標簽、按鈕、功能入口的位置，卻對頁面上該有什么、不該有什么非常明確。

好處在于方便指導設計（尤其是新人設計師）按照自己的想法做產品，壞處在于對設計理解不到位，功能與層次可能混亂，用戶行為理解不到位，這樣的設計很難讓用戶跟隨你的腳步，后續不好用，那么交給設計改改。

2.忽略設計而只重研發的產品經理

確實有這樣的產品經理（可能部分是研發出身，對研發掌控較多），他們覺得一些設計任務可以交給研發，因為研發輸出最終產物。

這樣的產品經理可能在前期沒有帶著設計團隊參與需求研究，并且認為現在只需要增加一個小的按鈕或功能，“這是非常小的改動”，這個讓研發直接添加個按鈕文字就好了，添加的位置呢~~可能這片區域比較空，就這里吧。

3.時間緊任務重的研發團隊

當然，強勢到直接在設計評審中干預設計的研發比較少，大多數人嘴上說好，身體卻很誠實。他們的產出與設計稿差異很大。

即使設計師對功能區塊做了明顯區分（比如產出完善的交互文檔，說明，額外的解釋，或者開過評審會），但在這個環節依然跑偏。

可能因為研發周期緊，任務重，人少，也可能因為研發認為這個設計點用戶不會理解錯，設計不需要做這些額外的設計標注來區分這些內容。

總之，在上下游直接出現這樣的蘑菇，還真的是非常非常多。場景還不限于上述情況。雖然大家都希望流程正規化，但是時間和人員可能會不允許。那么互相體諒吧~

這些情況，作為設計師的新人肯定會很郁悶，因為你的設計被改動了，你顯得相當被動。你很難辯駁自己設計的哪里好，別人為什么不應該亂改。不想當任人擺布的線框仔，那么找一個武器捍衛自己吧。

明白“可用性測試”的目的意義嗎

網站關于可用性測試的流程很多很多，但是實際中，能有設計師主導起來的倒是不多。

拿自己想要的果實，而不是別人嚼過的~。

市場、運營、產品都喜歡說自己有一手的用戶反饋，但是，對于設計師，那些不是最新鮮的一手需求，我們設計師確實需要親臨現場，看看用戶怎么使用你設計的產品。

設計師主導可用性測試的目的：除了測上一版本產品好不好用之外，設計師們可以利用測試結果，提出設計思路和改進方案。

可用性測試報告的結果是直接從用戶身上得到的，我們能夠采集到目標用戶特征，觀測到使用前、中、后用戶的狀態和想法，收集到用戶反饋與建議。

你的設計，有用戶站在你背后，誰會說你的設計很差呢？

設計師的執行要點

明確目標

沒有明確的目標就去找用戶聊產品，這樣的家常話可不是改善產品設計思路的好主意。設計師需要改進設計、提高用戶體驗、給出設計方案與思路。需要知道當前的產品問題在哪里，哪里不好用，用戶的心理預期如何，怎樣的設計能幫到用戶達成目標任務。

測試過程

有原型設計的帶上原型設計，沒有的話拿紙質的也可以，填寫表格和任務設計最好由設計師或團隊成員完成。

你出的題，你來測試，測試當中，你就有了心理預期。

結果分析

客觀的分析可用性測試結果，千萬別忘了最后需要一份設計改進的方案，這個主導你的設計的強大后盾?？赡?，在所有團隊中，沒有誰比你更懂得人性化的考慮了。

產品要考慮商業化，研發盯著技術難點，只有設計師是唯一人性化考慮產品設計的人。

結束語

以上是我個人的經驗總結，因為有了可用性測試的結果，這個答卷會有說服力。

別忘了可用性測試完成后，答卷抄送給團隊及領導，評審中好好講述你的設計理念，因為你是用戶體驗的設計師~

可用性測試是幫你變被動為主動的好工具，明白了意義，就快行動起來，不用謝我，經常交流就行了~

本文由 @葛達尼尼 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議