用戶意見 :傾聽,但不要迷信!
用戶體驗研究對于產品設計來說至關重要,其中傾聽用戶的觀點和想法是必要的,但是用戶作為非專業人員,在產品設計方面具有一些認知障礙,他們的觀點和想法或許會帶有一些主觀色彩。所以,設計師在做產品設計時,要對用戶意見有一個全局性的思考,不過度迷信用戶意見。
多數用戶體驗設計師認為:讓用戶參與到產品的創造與改進中來是一個必不可少的環節,他們招募用戶來了解他們的需求、使用痛點、改進產品的想法以及自認為必要的功能。
但這實際是有風險的,因為讓用戶參與到產品開發過程中的目的是為了更好地了解用戶,而不是真的讓他們做出決定。這需要充分的準備,以及對于定性數據的慎重分析。
問題就是:多數設計師沒能很好地處理這一點,而是傾向于做出一些快速決策和改進。
為什么不該一味聽信用戶?
用戶表述很可能會成為設計人員驗證自己現有觀點或偏見的工具,這并非出于惡意,而是多數企業都在鼓勵做快速決策。
設計師可能會直接攫取用戶的表述,來證實自己已經相信的想法,然后做出決定并推進開發,而不是嘗試以全局視角理解用戶的生活狀況。這會讓我們無法從用戶身上獲取真正有價值的研究結果。
設計師不應該問用戶想要什么,而應該具備一種能構想出產品不同設計方案,并從中選擇最優解的眼界。同時,知道自己的產品可以如何解決用戶遇到的問題,改善他們的生活狀況。
用戶在真正看到和上手使用一個新產品前,是無法認識到它的價值或自己對它的需要的。當他們嘗試后,才有可能愛上這款產品。
傾聽用戶是一件難以把控的事情,用戶通常并不知道自己真正要的是什么,即便知道,在溝通中也可能存在表述與理解偏差。
設計師一般通過結構性與非結構性的手段收集反饋,前者是由設計師提前構想反饋內容的分析方法,備好提綱以獲取預期的信息。
但在這種情況下,提綱有可能會將用戶反饋限制在一個特定的范圍內,客觀性就會下降。而非結構性的反饋收集方式又會讓后續的數據處理變得困難重重。
如果將用戶期望的東西都實現只會讓你的產品愈加復雜,甚至于,那些讓你添加功能的用戶也不會用你的產品。
一般來說,設計師會詢問并記錄用戶在使用產品中碰到的問題,但卻忘了去了解哪些設計是有效的。他們通常認為用戶沒抱怨的地方都沒問題。
設計師問錯問題或問太多問題時,就會誤導潛在用戶,導致用戶無法理性、客觀、誠實地回答問題。
設計師通常會偏信掌握話語權的人,這種現象很常見,且通常會在團隊中出現。在討論設計稿或原型時,設計師可能會把注意力集中在那些掌握話語權的人身上,而忽視了其他人。
當用戶產生誤解或碰到產品可用性問題時,設計師不能完全依賴于用戶提供準確無誤的反饋。因為在回答設計師的問題時,沒有用戶能夠主動地思考那些細節?;蚴撬麄兛赡軙噲D在「咄咄逼人的」設計師面前展現出更好的一面,因此給予有偏差的反饋。
用戶會說:“這里加一個按鈕,我就可以……”如果設計師能夠繼續深究問題,也許會意識到這個用戶期望實現的動作,其實可以自動為用戶完成,根本就不需要在界面上再徒增一個按鈕。
那該怎么做?
我們可以通過觀察用戶與界面交互的行為來判斷哪個設計更優。
這個方法非常簡單,但許多人卻忽視了它的價值,總想著通過其他方法來做可用性測試。
可用性測試可歸結為以下三個基本法則:
- 觀察用戶的真實行為。
- 別相信用戶說他們會怎么做。
- 更不要相信用戶預測他們未來會怎么做。
任何數據(包括用戶反饋和量化數據)都可能是有關的,但如果你收集的不是有效數據(或數據量不夠),那么,你的行動可能依然會基于猜測或個人經驗進行。
因此,當設計師將更多注意力放在用戶的真實行為時,才能設計出用戶體驗最佳的產品。
自我報告通常是不可靠的,用戶對于自己未來行為的預測也一樣。用戶不知道他們真正要什么,也不會知道他們使用新產品時會有什么反應。通常情況下,他們會表現出與日常生活截然不同的行為。
總之,通過觀察用戶與產品的真實交互行為是最重要的獲得用戶反饋的方法。但這并不意味著可用性專家就不需要傾聽人們的想法,而是應該在觀察用戶行為后再聽聽他們的感受。
不論是記錄用戶數據、傾聽他們或是觀察他們使用產品,最為行之有效的方式還是讓他們在進行操作的同時“發聲思考”,說出自己的想法。這可以讓你了解到更多產品的不足,以及真正了解普通用戶的思維模式——他們的想法往往與你的想法存在差異。
即便如此,人口統計學數據的分析(不論是在實驗室還是實際場景中)依然是產品設計與優化中的主要部分,而觀察用戶真實行為則是可用性測試的基石。
有一些設計者會謹小慎微地聽取用戶意見,記好筆記,會意地點頭,答應滿足他們的需求,然后按照自己認為產品應該的樣子做出來,再努力說服用戶:這就是你們想要的產品。
但如果你聽取了上文的建議,就不需要這樣做了。
多說一點
講一個小故事:
二戰時期,同盟國面臨著一個問題:戰機在執行轟炸任務時的墜毀率超出50%。
他們嘗試研究返航的戰機機身,查看各部位的損壞程度,進而判斷出哪里最需要加固。然而,墜毀率并沒有因此下降。
問題就在于:他們研究的是歸來的戰機而不是墜毀的戰機,因為還能回得來的戰機身上的損壞部位顯然并不致命,他們需要的是墜毀的戰機的數據。
數據采集是必要的,但要確保你所獲取的數據是準確并有效的。
如果條件允許,可考慮使用一些產品內的可用性觀察手段:
1. 內部審核跟蹤(Internal Audit Trail)
用戶所有的行為變化數據都會被記錄到產品的數據庫中,包含有:日期時間、原始數據表格、改變的字段列名、原數值、新數值、“從哪個頁面跳轉?”以及,“誰的行為發生了改變?”。
通過它可以了解到:用戶真正使用的是哪些功能?以及,到底是哪些人在使用你的數字產品?
2. 內部事件日志(Internal Event Log)
不論是產品異常,或是用戶的登錄登出,都會記錄在日志中。你就可以知道哪些人登錄了產品系統,有多少人成功登出,或是放著等待會話過期。由于數據記錄了用戶ID、登錄時間以及事件發生的日期與時間,設計師與程序員也可在「審核跟蹤」數據中找到相應的信息。
所以,有時候其實可以通過詳細的用戶日志了解用戶的真實行為,而不需要直接觀察用戶(雖然這么做也是有用的)。
關鍵是日志只能反映出用戶做過什么,而直接觀察用戶可以讓你知道用戶會花多少時間完成一個操作決定,從而了解你的產品體驗如何,交互界面是否讓用戶產生困惑。
通過面對面的溝通,你還能了解:用戶當時想做什么?以及,他們的實際行為。
舉個例子:日志可以告訴你網站地圖中的點擊數是多少,但它并不告訴你用戶是不是不小心來到這個地方,或者用戶選擇這個路徑是不是因為他不理解導航欄的提示。
總之,不要盲目地相信你的用戶!
內容原創作者:Maxim Grozny,翻譯:F.Lee
譯文地址:http://uxren.cn/?p=61229
本文由 @黑眼鏡的貓 發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
- 目前還沒評論,等你發揮!