可用性測試:讓交互設計變被動為主動的利器
大家都知道“可用性測試”是做什么的,它能判斷產品易用性的好壞,指明產品后續的改進方向。但是有多少設計師真正利用好可用性測試這個強大的武器,若沒有適當的武器捍衛自己的設計,那么你會處于如下境地。
交互設計師的尷尬境地
作為交互設計師的新人小白通常都會遇到這樣的一些人和事:
1.對設計過多干預的產品經理
這類產品經理在提及需求時,大多腦海中已有大致的原型效果圖,即使不十分明確標簽、按鈕、功能入口的位置,卻對頁面上該有什么、不該有什么非常明確。
好處在于方便指導設計(尤其是新人設計師)按照自己的想法做產品,壞處在于對設計理解不到位,功能與層次可能混亂,用戶行為理解不到位,這樣的設計很難讓用戶跟隨你的腳步,后續不好用,那么交給設計改改。
2.忽略設計而只重研發的產品經理
確實有這樣的產品經理(可能部分是研發出身,對研發掌控較多),他們覺得一些設計任務可以交給研發,因為研發輸出最終產物。
這樣的產品經理可能在前期沒有帶著設計團隊參與需求研究,并且認為現在只需要增加一個小的按鈕或功能,“這是非常小的改動”,這個讓研發直接添加個按鈕文字就好了,添加的位置呢~~可能這片區域比較空,就這里吧。
3.時間緊任務重的研發團隊
當然,強勢到直接在設計評審中干預設計的研發比較少,大多數人嘴上說好,身體卻很誠實。他們的產出與設計稿差異很大。
即使設計師對功能區塊做了明顯區分(比如產出完善的交互文檔,說明,額外的解釋,或者開過評審會),但在這個環節依然跑偏。
可能因為研發周期緊,任務重,人少,也可能因為研發認為這個設計點用戶不會理解錯,設計不需要做這些額外的設計標注來區分這些內容。
總之,在上下游直接出現這樣的蘑菇,還真的是非常非常多。場景還不限于上述情況。雖然大家都希望流程正規化,但是時間和人員可能會不允許。那么互相體諒吧~
這些情況,作為設計師的新人肯定會很郁悶,因為你的設計被改動了,你顯得相當被動。你很難辯駁自己設計的哪里好,別人為什么不應該亂改。不想當任人擺布的線框仔,那么找一個武器捍衛自己吧。
明白“可用性測試”的目的意義嗎
網站關于可用性測試的流程很多很多,但是實際中,能有設計師主導起來的倒是不多。
拿自己想要的果實,而不是別人嚼過的~。
市場、運營、產品都喜歡說自己有一手的用戶反饋,但是,對于設計師,那些不是最新鮮的一手需求,我們設計師確實需要親臨現場,看看用戶怎么使用你設計的產品。
設計師主導可用性測試的目的:除了測上一版本產品好不好用之外,設計師們可以利用測試結果,提出設計思路和改進方案。
可用性測試報告的結果是直接從用戶身上得到的,我們能夠采集到目標用戶特征,觀測到使用前、中、后用戶的狀態和想法,收集到用戶反饋與建議。
你的設計,有用戶站在你背后,誰會說你的設計很差呢?
設計師的執行要點
明確目標
沒有明確的目標就去找用戶聊產品,這樣的家常話可不是改善產品設計思路的好主意。設計師需要改進設計、提高用戶體驗、給出設計方案與思路。需要知道當前的產品問題在哪里,哪里不好用,用戶的心理預期如何,怎樣的設計能幫到用戶達成目標任務。
測試過程
有原型設計的帶上原型設計,沒有的話拿紙質的也可以,填寫表格和任務設計最好由設計師或團隊成員完成。
你出的題,你來測試,測試當中,你就有了心理預期。
結果分析
客觀的分析可用性測試結果,千萬別忘了最后需要一份設計改進的方案,這個主導你的設計的強大后盾。可能,在所有團隊中,沒有誰比你更懂得人性化的考慮了。
產品要考慮商業化,研發盯著技術難點,只有設計師是唯一人性化考慮產品設計的人。
結束語
以上是我個人的經驗總結,因為有了可用性測試的結果,這個答卷會有說服力。
別忘了可用性測試完成后,答卷抄送給團隊及領導,評審中好好講述你的設計理念,因為你是用戶體驗的設計師~
可用性測試是幫你變被動為主動的好工具,明白了意義,就快行動起來,不用謝我,經常交流就行了~
本文由 @葛達尼尼 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
問題頻數乘以4,這個4是怎么得到的?