起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識訪談中，用戶無法準確回答的8個情景
訪談是用戶研究中使用最普遍的方法。由于人類記憶的局限性，用戶無法回憶起所有歷史經(jīng)驗或細節(jié)體驗，因而表述的內(nèi)容會存在與實際不一致的情況。但在用戶研究中，訪談也是不可缺少的過程，研究人員知道哪些問題適合提問、哪些問題不適合提問這是非常重要的。本文介紹了哪些不適合直接提問（用戶無法回答的問題）的情景，以及面對這些問題，如何通過其它方式獲得答案。
在訪談中會遇到一些尷尬的現(xiàn)象，研究人員會問一些受訪者無法回答的問題。因此，研究人員知道哪些問題用戶可以回答、哪些問題用戶不好回答，對于訪談是非常重要的。這也是用戶體驗研究中更多地觀察真實情景下的用戶行為而不是開展訪談、問卷調(diào)查、焦點小組的一個原因。雖然這些訪談方法也是有用的，但用戶實際行為與用戶說的也存在不一致的情況?；谡鎸崍鼍暗挠脩舨僮餍袨?，同時進行觀察與訪談，可以讓研究者更準確地了解用戶特征、用戶行為、使用情景。
但在用戶體驗研究中，單單觀察用戶也是不夠的，在研究中進行適當訪談是有必要的。因而，在不同的用戶體驗研究中都會進行不同形式或不同程度的訪談。除非你在訪談前對用戶行為的背后動機有了對應的假設，否則在觀察用戶操作過程中同時會產(chǎn)生一些問題。因此，在理解用戶行為時，用戶訪談是必要的。
有些問題用戶比較容易回答，有些問題用戶回答是有些困難的。接下來將介紹一些用戶無法準確回答的情形。
情景1：要用戶回憶過去的細節(jié)內(nèi)容
當咨問用戶對產(chǎn)品的使用體驗或觀點時，用戶只能描述整體印象和行為，但很難描述具體的細節(jié)內(nèi)容。舉個例子，當進行一個洗車廠家網(wǎng)站的可用性測試時，作為汽車購買周期的一部分，研究者會問用戶最近在汽車網(wǎng)站的使用行為。用戶可能會回答你最近看過哪些網(wǎng)站、在網(wǎng)站上做了什么、對這些的網(wǎng)站整體看法，但是用戶描述網(wǎng)站的具體細節(jié)內(nèi)容是非常有困難的。人類的記憶是不精確并且容易出錯。假如用戶能夠回憶起一些特別好或特別糟糕的體驗細節(jié)，那是非常好的。當用戶不能回憶起更多細節(jié)內(nèi)容時，研究者不能要求用戶回憶更多內(nèi)容或引導用戶回憶更多內(nèi)容。
怎么了解用戶的歷史體驗？
如果能夠運用好用戶的記憶局限性，研究者是可以提問關于歷史體驗問題的。以下是幾個提問的小tips：
問一些用于了解用戶整體體驗、看法的問題，而不是期望用戶提供一些無法提供的細節(jié)內(nèi)容。
讓用戶來談論一些用戶記憶深刻的事件，但用戶可能不能回憶起具體細節(jié)內(nèi)容。
用戶談論時，直接呈現(xiàn)相應的網(wǎng)站、軟件或產(chǎn)品。讓用戶先用一下產(chǎn)品，方便用戶描述他們的歷史體驗，用戶可以演示一個操作或指出某個具體的內(nèi)容，而不是完全依賴記憶。
情景2：要用戶預測未來
用戶不善于預測自己未來會做什么、不會做什么，或基于某個特殊情景進行預測。如果你要他們預測，他會向你提問很多問題，他們的預測可能不能準確地反映他們未來真實的行為。舉個例子，如果你問用戶是否會使用某個新功能，有些人會說會去使用，主要原因是他們自己不能排除可能會去使用的可能性；有些人可能會說不會去使用，主要原因是他們自己不能想出使用的理由或場景。對于不存在的東西，用戶很難提供判斷或觀點。
怎么預測用戶未來？
等到產(chǎn)品原型完成時，才去了解用戶對這些具體新功能或設計元素的態(tài)度。相對于抽象概念，實際原型能夠讓用戶更容易進行評價。雖然這樣還是無法準確預測用戶未來是否會使用，但這樣的調(diào)研結果還是可以用于判斷設計是否成功。
情景3：脫離情景討論操作細節(jié)
在傳統(tǒng)的用戶訪談中，用戶可以描述一般的操作任務，但是讓用戶準確回憶每個步驟是有困難的。用戶在操作時很多情況下是無意識的，不會去思索每個操作步驟，這種情況下用戶脫離情景下描述每個操作步驟是極其困難的。舉個例子，想象一下教一個孩子自己系鞋帶，如果旁邊沒有鞋子，你能否教會孩子如何系鞋帶？
怎么了解用戶操作？
與其抽象的談論用戶操作，讓用戶自己演示操作就容易得多了。用戶在自然環(huán)境下操作，研究者觀察用戶的的操作行為。我們可以在用戶完成操作后進行訪談，也可以用戶在操作過程中進行適當?shù)那榫霸L談。核心是觀察用戶在自然狀態(tài)下的操作行為，并在用戶操作情景中進行適當訪談。
情景4：通過訪談確定用戶需求
直接問用戶要什么或直接接受用戶說的內(nèi)容，那是會范錯誤的。用戶可以告訴你他們遇到的問題或影響他們的東西，但用戶很難表述他想要或需要的東西。受訪者可能提出解決問題的建議，但這樣的建議可能不是解決問題的最佳方案。
如何確定用戶需求？
觀察自然狀下的用戶操作，并進行適當訪談，這是發(fā)現(xiàn)用戶真實需求的最好方法。當用戶提出建議方案時，不能因為用戶的面子問題而簡單的全部接受，也不能不考慮這些建議方案，而是找出更多的問題以及背后的原因。與用戶更多地討論具體問題是如何影響他們的，他們嘗試如何解決這些問題，對于這些解決方案是如何看待的。有了這些信息，設計師可以形成設計方案來解決問題，從而滿足用戶的需求。
情景5：讓用戶對概念進行想象
不要讓用戶對沒有見過或使用過的概念進行想象或評價，對于只有簡單文字描述的概念，用戶通常難以想象這是一個什么樣的設計方案、功能或交互方式。雖然你能提供一個好的描述，你能確定用戶的想象的東西與你要表達的內(nèi)容是一樣的嗎？向受訪者展示一個具體的實體通常好于單純的內(nèi)容描述，但只是簡單地看，那也是不夠的。受訪者能夠操作原型，這樣才能獲得最好的用戶反饋。
如何獲得用戶反饋？
給用戶一個可操作并且會有反應的可交互原型，用戶更容易進行反饋?？紤]到到原型保真度的限制，在低保真度的原型中，一些復雜的或特別的交互無法實現(xiàn)，這樣也阻礙了受訪者獲得概念原型的真實感知。
情景6：讓用戶來改進設計
受訪者一般不是設計師。受訪者可以告訴你什么東西看起來是有用的、什么東西不容易理解、為什么操作失敗，但是他們通常不能提供具體的設計解決方案。雖然他們可能會提出一些簡單的改進建議，但無法給出有重大作用的設計建議。
如何發(fā)現(xiàn)設計改進方法？
由于受訪者不是設計師，所以不能期望讓他為你做出設計決策。可用性測試的目標是發(fā)現(xiàn)哪些是有效的、哪些是無效的，設計師根據(jù)這些信息來改進設計，而不是向用戶要解決方案。目標是找出用戶使用過程中遇到的問題，然后設計師根據(jù)自己的判斷改進設計。最后，拿著改進后設計進行再次用戶測試，驗證優(yōu)化后的設計有沒有解決用戶遇到的問題。
情景7：讓用戶區(qū)分不太重要的設計差異
有些設計師期望將所有設計爭議都進行用戶測試。當然，相信用戶測試那是件好事，但不能將所有設計決策都放在用戶身上。用戶測試不是用于讓用戶告訴你如何設計，或者幫助你解決每個設計爭議。
實際上，有些微小的設計差異，用戶都感知不到差異的存在，更別說對設計方案的偏好了。在測試中，有時你會發(fā)現(xiàn)用戶產(chǎn)生疑問：我看不出這些設計有什么差異，為什么要讓我選擇更喜歡哪個呢？
如何測試多個設計方案？
對比性可用性測試用來了解用戶對多個設計方案的評價。當用戶只看到一個設計方案時，用戶可能不知道說些什么，如果同時看到多個設計方案，用戶會提供更多有用的反饋。
但在，在一個用戶測試中，供用戶測試的設計方案最好不要超過3個。如果對比方案過多，用戶在選擇時會產(chǎn)生選擇困難或困擾。同時，需要保證設計差異對用戶來說是有價值的。
情景8：讓用戶解釋行為產(chǎn)生的原因
觀察可以知道用戶是怎么操作的，但不知道用戶為什么這樣操作。當你問用戶時，用戶有時也沒不知道自己為什么這么操作，結果他給你了一個貌似有理的解釋。用戶也不是故意說慌，的確是用戶不知道自己為什么這么操作。
怎么理解用戶行為？
由于受訪者也不能準確地知道為什么這么操作，有些研究人員建議只關注用戶的操作行為，而不關心用戶說的內(nèi)容。這種做法也是極端的，是不合適的。觀察只能讓你知道用戶是怎么操作的，但是不能知道用戶這樣操作的原因。
適當?shù)奶釂柣蛟跍y試過程中讓用戶邊操作邊說，這樣有助于了解用戶行為的真實原因。操作后，也可以進行適當提問，這樣可以了解更多的信息。雖然用戶說的內(nèi)容無法得到所有原因，但這樣做還是有助于了解用戶的心智模型。記住，不要盲目地接受用戶的解釋。相反的，我們要從用戶說的內(nèi)容，分析提取真實的用戶心理。
后記：做用戶很容易談論的事情
在用戶研究中，當用戶在操作實際場景中經(jīng)常操作的任務時，我們可以獲得最準確和最有用的信息。在可用性測試中，與受訪者簡單地看一下設計原型并給了一些整體性評價相比，讓用戶嘗試多個方案并進行對比評價，這樣可以獲得用戶最有效的評價。在任務操作完成后，立即對受訪者進行適當?shù)奶囟ㄌ釂?，這樣可以獲得用戶最佳反饋。
在用戶研究中，重點關注用戶的真實操作行為而不是用戶說的內(nèi)容。當然，你也必須要傾聽用戶說的內(nèi)容，但主要關注用戶談論的使用痛點問題。
只有知道了用戶不容易回答的問題后，才能避免一些沒有效果或誤導性的問題，而是集中精力問正確的問題，同時得到最有效的結果。
譯者：戴均開
- 目前還沒評論，等你發(fā)揮！
