避免引導性提問以得到更好的測試反饋

原作者：Amy Schade ／ 原文章：Avoid Leading Questions to Get Better Insights from Participants ／ 發布時間： 12-17-2017／ 翻譯：小球娘

幾句話概述：在用戶體驗研究中，主持測試的人所使用的語言可以影響被試者的反饋或行為。

小測驗：以下哪種追問的說法能得到更加準確的訪問測試結果？

- 「我看見你在使用導航的時候有困難，能否具體談談？」

- 「你為何在使用導航的時候出現困難？」

- 「在尋找你想要的內容時，覺得遇到了哪些困難還是覺得容易？」

第三個提問方式會讓你得到最可靠的反饋，為什麼呢？因為前兩種提問方式都有引導性 - 就是提出問題時遣詞造句的方法包含或暗示了你想要的答案。

讓我們看看前兩個問法的弊端在哪：

提問1:「我看見你在使用導航的時候有困難，能否具體談談？」

弊端：提問人重新描述了被觀察的產品對象，但這個對象有可能並不是用戶的注意力所在。對於提問人或觀察者來說，看起來被試者彷彿是困在了導航上，但其實她可能在想哪個信息是最有用的，或被任務本身迷惑，或壓根就是在看網站的其他部分。這個問法同時提到了一個界面元素——導航——對於這個名詞用戶可能知道，也可能不明白，對不上號，或一般不這麼說。

提問2:「你為何在使用導航的時候出現困難？」

弊端：同樣的，這種問法暗示了答案並假定了導航就是問題所在。同時它在質疑被試者而不是網站。它把關注點放在了被試者的行為上，而不是放在可能對用戶行為產生了影響的網站元素本身。

提問3:「在尋找你想要的內容時，覺得遇到了哪些困難還是覺得容易？」

好處：這個問法把用戶放在關注的中心——在網站內尋找內容——沒有用名詞或感受去影響用戶。被試的用戶可以在不用反對提問人的情況下回答在站內遊走很容易或困難。這個提問用了相關主題的大概框架，而非暗示其答案。

很多時候用戶體驗研究是觀察性的——我們觀察用戶使用。但是，我們同樣也去聆聽用戶告訴我們什麼，很多情況下，我們需要把用戶告知的東西弄清楚。我們在測試任務完成以後還要追加試後問題。我們也可能在某個時刻要求用戶分享更多信息。在測試開始的時候，我們還需要詢問或確認用戶的基本信息。

對用戶研究來說，得到誠實的，無偏見和傾向性的被試者的反饋極為重要。當我們問問題的時候，我們是希望去更了解用戶行為。為什麼這一部分的內容很清楚？為什麼一個頁面元素引發困難？引導性的問題有弊端是因為它們混入問題本身影響我們想聽的答案。它們讓被試者在表達不同觀點時覺得為難或彆扭。這一點在測試——研究之間的互動中特別明顯，因為往往在做測試的空間里，提問者是「權威」，很多被試者並不想與之背道而馳。

引導性提問會導致帶偏見或虛假的答案，因為回答的一方會不自覺的簡單重述提問人所說的話。我們如何對問題遣詞造句不僅可能影響用戶反饋，還可能給予他們關於界面的額外線索。於是我們可能最終得到不準確的反饋，其可能沒有如實反映用戶體驗，思維模式，或思考過程。又或者，更糟的可能是直接使得用戶行為在剩下的測試環節中改變方向。比如，一個經驗不足的訪問者問「你覺得這個按鈕是幹什麼的？」於是用戶就意識到那個她之前指向的文字實際上是個可用鏈接。

引導性問題會剝奪我們從用戶那裡聽到無法預見的反饋的機會。我們的提問越是具有引導性，用戶就越不容易給出令我們驚訝或引發思考，或促使我們以新的角度解決問題的反饋。引導性問題可能適用於「確認」設計，但對於測試設計絕對是非常不好的。始終牢記有時候最好的提問其實不是問出問題，而是幫助用戶保持他們自己的思路的引導。那麼當我們需要提問的時候，如何避免引導用戶呢？

是什麼導致了引導性提問

你可能會很熟悉法庭情境的電視節目里聽到過所謂引導性問題，律師大喊：「反對！他在引導證人！」很多方法都可以讓我們暗示一個用戶去簡單的重複或確認我們的偏見，步驟，或假定。有人可能是故意為之，試圖得到對他們自己的理論里什麼設計可以什麼不可以的驗證。然而，我們絕大多數從業者這麼做是無意識的。為了收集用戶反饋，我們應該問開放性問題——誘導用戶主動作出解釋的問題，而不是簡單的是，否，或多選答案。我們如何提問對於所得反饋是否有價值和可用是很關鍵的。以下是一些常見弊病需要避免：

• 不要用自己的語言描述

被試：「我注意到這張圖...」

研究者：「你剛提到那張圖很有幫助。你為什麼喜歡它？」

改進：「你剛提到了那張圖是嗎...?」

• 不要建議回答

「在工作日里，這會如何幫你節省時間？」

改進：「這可能會對你的工作效率有什麼影響？如果有影響的話」

• 不要提界面元素名稱

「頁面一邊的相關鏈接——你覺得它們指向哪裡？」

改進：「頁面一邊的這部分區域...[指著它]你覺得這是什麼？」

• 不要以為你知道用戶的感受

「當你為這個任務焦慮的時候，具體是什麼情形？」

改進：「覺得完成那個任務簡單或難在哪裡呢？」

多練習才會完美...至少變得更完善

有些我們問被試者的問題是提前準備的——例如，我們可以用一個常用問題列表來開始或結束一個測試環節。這種情況下，我們可以很容易的多次根據需要改進或改寫問題，從而讓它們變得中性。

如果在測試進行中臨時提出問題而完全不影響用戶反饋則困難的多。每個人在組織語言的時候經常都會出錯，而且問出一個從各方面看都沒有偏向性的問題是非常困難的。但是，意識到問題的存在是著手解決它的一個好的開始。要警惕那些容易問出有引導性的問題的情況，如果看到別人犯了這個錯誤，留意觀察它是如何影響用戶反饋的。

小球娘的話：

自從NNG開始掛出一些不痛不癢的視頻「文章」開始，我就有些失望，因為感覺那些視頻只是讓你去花錢上他們培訓課的廣告。這篇文章一出來我就好激動，終於有點乾貨了。我在之前的文章里大概提過做用戶訪問的深坑，（低可視性和可發現性：通過四種方法找出其原因）今天這篇算是談了些實質性的方法。聊勝於無吧。

另外，今天紐約暴風雪，來大家一起涼快涼快～