起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品QTI用研模型：用一個方法完成問卷、訪談和測試，提高交互設計體驗！
編輯導讀：本篇文章先是簡述了產品交互設計中用研的重要性，給出了可用的敏捷式用研模型——QTI法，然后拿出APP從0到1的工作項目來舉例分析了該模型的運用流程，并在每一個環節筆者都做了非常詳細的操作說明和建議。
該方法論適合人群：
- 在校學生。幫助他們完成課程項目、學術論文中的用戶調研部分，提供清晰的可用思路。
- 中小型公司的產品經理或設計師。在無用研團隊提供支持的情況下，可根據QTI模型制定適合所在企業、團隊和項目的適用方法。
- 其他感興趣人員。有希望轉行的或對產品設計有興趣的同學，覺得傳統用研理論太多且過于學術化，可以參看本篇文章，了解實際的使用場景后再有目的性地去補充學習。
一、產品用研的現狀
1. 需求質疑實質
無論是在學校的互聯網產品類、設計類大賽評審，還是互聯網公司內部評審，永遠繞不過去的爭論主題是：
這個需求存在嗎？這個設計有用嗎？
這些問題的背后實質是：產品和UX團隊內部對目標用戶的認知不統一。
人都是基于自己的經驗來解讀用戶，自然導致對需求理解的不一致，更何況很多產品經理整理出來的需求本身就是畸形的，依據都是行業數據和報告參考，這種數據不是精確獨立、讓人信服的，因為大家都是拿到相同的數據，最后又淪為主觀否定主觀之爭。
2. 無用研的原因
大家當然知道用戶研究的重要性，但還是受到很多原因無法去做：
（1）內部原因：產品人的用戶意識不強
雖然很多非設計類產品經理轉行學習過相關的用戶需求知識，也有基礎的用戶意識，但很難變為行為上的重視。
（2）外部原因：公司部門的支持不足
耗時耗力耗錢是根本，中小型公司很難會花費大量成本在用戶研究這種“玄學”環節上，因為成果是“看不見摸不著”，但成本確是實實在在的。
3. 無用研帶來的問題
（1）影響其一：導致立項評審反復修改
俗話說，一鼓作氣，再而衰，三而竭，業務方會陷入反復修改的時間浪費中。
（2）影響二：開發理解不一致，驗收易沖突
產品經理、設計師和開發人員對產品以及目標用戶群體理念不統一，產品容易收到挑戰和質疑。
（3）影響三：運營方案定位存在問題，ROI過低
二、QTI敏捷用戶調研法
什么是敏捷用研？筆者斗膽定義：
基于現有項目限制條件下，選取并組合一定比例的結構性方法來對目標用戶進行分批次的迭代式研究活動。
而QTI法可以說是敏捷用研下的一個方法模型，是筆者根據自己之前用研經歷所使用的方法的總結
QTI由Questionnaires（問卷）+Test（測試)+Interview（訪談）三個部分組成。
1. 核心要素
- 要素Q：分為問卷調查和主觀體驗量表
- 要素T：分為可用性測試和協作測試
- 要素I：分為個人訪談和多人訪談（焦點小組）
2. 參考流程
首先大家要明確一點，沒有什么方法是一成不變的，QTI法并不是嚴格按照順序進行執行，該方法根據項目的不同情況可進行自由組合和適當增減。
（1）準備：制定了調研主題、流程和時間安排，完成問卷、訪談、測試的設計。
（2）挑選：向相關用戶群發送調查意向動態，從中選取合適的用戶
（3）預演：找非用戶人員進行預先演練，調整內容描述和流程
（4）實操：確定用戶排期，將用戶分成多個小組，先邀請若干用戶進行預調研，確保實際流程無問題
（5）正式：進行正式調研，流程包括問卷調查、產品測試、量表填寫、問題回顧以及訪談（QTQII）。
（6）多輪：第一組用戶結束后快速統計問題，解決掉有歧義的問題后進行第二組，此時重點關注第一組提及的問題，第二組結束后統計兩組的共同問題，涉及到產品操作問題的迅速記錄反饋給開發團隊，接著進行第三組，可適當側重共同問題，以此類推。
（7）結束：調研結束，表達感謝，贈送禮物
（8）整理：將各組的內容進行整理，提取關鍵的共同問題和差異點，盡快處理數據統計，遇到疑惑的地方可查看錄制的視頻或音頻，必要的時候可以聯系相關的用戶。
以上就是我處理用研的流程，基本上是按照實際情況進行調整的。
三、實際工作舉例
光說不練假把式，筆者有幸主導過app從0到1，故拿出該項目作為案例進行拆分解讀，給大家一個具有實際背景的事例作為參考，這樣能有一個直觀的感受。
該項目實際資料和用研文案都進行了脫敏處理（保護重要數據從我做起），但不影響觀看體驗。
項目背景：
在無實際用研結果下，只是用行業報告和產品人員的判斷確定了用戶需求和產品功能，app已經完成了團隊內部的測試驗收工作，但沒有實際的用戶使用過，故希望通過調研一批目標用戶來完成對產品的可用性測試和用戶需求收集工作。
1. 準備方案
（1）確定調研主題
發現可用性問題：
主要是通過產品的可用性測試和用戶反饋，來確定真實用戶在操作中遇到的卡點問題、歧義問題和BUG。
尤其是歧義和bug的地方，歧義主要是因為專業人員在開發的時候很容易地就用上了專業術語，如各類彈窗和toast里的“服務端數據異?！?、“接口錯誤”，還有些是“確定”“取消”傻傻分不清；bug主要是因為測試人員都是按照常規使用流程進行的測試，而實際用戶有各種想不到的騷操作，例如他會將某些“敏感”圖片作為頭像，這時候就得接入圖片審核。
收集用戶需求原材料：
最初不做用戶研究限于成本可以理解，但產品臨近上線，是一定要收集定量和定性的數據來做分析，作為后續功能迭代優化的依據。
通過問卷獲得人口學數據和定量數據，通過訪談和反饋來獲得用戶主觀的數據，當然，這些都是原材料，還需要進行分析與處理。
（2）確定方案
方案分為兩種類型，一種是流程性方案，即先做什么后做什么以及不做什么，另外一種就是執行方案，就是在某一環節使用的具體方案。這個好比功能流程圖和頁面圖的關系
流程性方案：
大致流程就是上面介紹的參考流程，可根據實際再做增添，記住，流程可萬變，但一定要實事求是。
這時候還需要確定活動所需成本，包括人力、精力還有錢，因為成本也是需要上報的（打工人淚目）。如：
人力：投入1個產品經理和1個開發同事
精力：產品經理抽出0.8個人日，開發同事抽出0.2個人日
錢：預計接觸20位目標用戶，準備20份獎勵，共1000元。
具體方案：
Q. 問卷調查設計
如下圖，基本結構就是用戶基本信息、問卷說明、容易問題、思考問題以及結束語。
- 用戶基本信息填寫要考慮是否有必要，如用戶姓名可用昵稱代替。
- 問卷說明寫明目的，最好寫出本方實際信息增加信任感，并且點明不會給到第三方（用戶隱私很重要！）
- 簡單易選問題，第一題目內容不歧義（能讓人讀懂），二是區間選項一定要窮盡無交叉，比如A是1～10，B是10～20，那用戶是10的話是選A還是B？
- 耗時思考的問題，一定要給預選項和補充項，因為很多選項是設計的時候考慮不到的，例如學習的目的，不可能將所有目的都能考慮到，這時候需要給予“其他”以及“：”。
- 結束，多說說感謝。
T. 產品可用性測試設計
如下圖，基本結構就是產品介紹、測試注意事項、具體測試任務和結尾。
- 產品介紹里寫清楚產品的定位，讓用戶有所了解。
- 注意事項里要提前說好可能會出現情況，尤其是要加“不會回答你的操作問題”。
- 具體的任務描述不能帶有指導性，例如，“你會選擇xx進入到xx”，“你使用xx功能”，而是要設立場景，即“當你遇到xxx情況時，你會如何？”。
- 多說謝謝。
Q. 用戶體驗量表設計
如圖，其實可以直接使用很多標準量表，如SUS量表，這個量表的使用率是相對比較高的。
因為可以計算得分，還可以根據等級表進行軟件評分評級。
注意，有些用戶可能無法理解有些問題的含義，畢竟是英文轉漢意的，最好能按照自己的語言再整理出一份，或者在測試的時候講解（費力）。
I. 回顧或簡短訪談
如圖，有訪談說明、訪談內容記錄和結尾組成。
- 問題內容根據實際情況而定，一般來說預設問題都是產品經理和設計師提前設定好的，多是定性的想了解的問題，其次一定要留有一個自定義問題空白，方便調研人員發現個人問題的時候進行詢問。
- 需要留有記錄空白，方便進行快速的關鍵詞編寫。
2. 挑選與預演
（1）挑選用戶
一般來說，一類目標用戶群體中不是每一個用戶都適合邀請過來進行調研的，尤其是對于訪談而言，很多用戶本身不太外向，導致問題無法深入交流，這比較考察調研人員的主持能力，是不可控的，所以需要對目標人群進行篩選。
合適類型：
- 如果是年輕人，可以在論壇微博、同類產品反饋（吐槽）里尋找到活躍用戶，向他表明來意，這類用戶一般是很愿意配合的，當然最好是本地的。
- 如果是中老年人，可以去當地社區或該類型人流量較大的地方進行觀察，再進行邀請，不過這個容易引起誤會，想當年我去農村調研被當成了手機販子，差點被POLICE抓了(汗）。
（2）內部預演
顧名思義，先幾個非項目組人員進行演練，千萬不要找項目內的，不然嘻嘻哈哈，都是自己開發的產品相當熟悉了。
這個時候，注重看有哪些流程是浪費時間的，哪些部分是需要去除或更改的，根據我的經驗，最起碼會修改兩到三次，如果一次都沒有是絕對不正常的現象。
3. 正式調研
確定用戶排期，將用戶分成多個小組，可以分為個人組和團體組，也就是個人調研和團體調研。
（1）實操
先邀請1到2位用戶，按照標準流程進行調研，這個時候還是注重流程問題，因為之前的內部檢查還是有很多細節沒注意到。
記錄好方案問題，立即返回進行修改，這個過程很短，不會耗費多少時間，但很重要。修改完整之后就可以作為最終版本正式進行大范圍調研了，調研期間最好不要做更改，以免數據不夠統一標準。
提前測試好硬件，有眼動儀、生理監測儀器當然好，但一切都可以從簡，準備兩套設備：三腳架+手機，一套俯拍用戶操作，一套錄制訪談。
（2）個人調研
一般來說流程是問卷Q+測試T+量表Q+訪談I，攝像頭和錄音筆準備好
問卷：
不干擾，直接填寫
測試：
就默默觀察他處理任務，手里可以簡單記下節點情況，一般來說是用戶疑惑（撓頭）或者是完成其他任務的情況。
在這個環節中，基本上每個用戶都會問：我做的對嗎？這種都是比較“討好”調研人員的表現，他們抗拒自己操作錯誤顯得“白癡”，此時你應該微笑搖搖頭，“你繼續使用就可以了”。
千萬不要去教用戶如何做，否則就是白浪費時間。用戶出現的這類問題很大程度上就是產品的問題，一定要觀察好。
量表：
可以提前解答每句話的意思，但還是建議用自己的話再寫一份量表。
訪談：
一個小tip：先送上禮物。經過前面幾輪，用戶有些不耐煩和疲倦很正常，提前給禮物能讓他更加積極！傳統理論里會讓調研者在結束后再給，其實沒有必要（一般人我不告訴他）
問的時候，有些用戶會很簡短，此時調研者要深入問下去，一直問為什么，得到答案后再敘述下。
例如：
- 你覺得平時英語學習中遇到的最大困難是什么呢？
- 答：聽力我覺得好難。
- 再問：是覺得什么地方難？
- 答：主要是聽不懂，雖然四級考試聽力聽說很簡單吧。
- 再再問：意思是說四級聽力在你看來是沒有那么簡單的是嗎？
- 答：是的，我聽過很多次，但總是抓不到重點，做選擇的時候就會錯過很多問題。
- …….
這樣，最后訪談的答案就不是一個簡單的“聽力難”的記錄了。
結束后，測試機子和app賬號記得清空或還原，避免歷史數據干擾！
（3）團體調研
團體調研一般來說是促進廣泛啟發溝通的，和個人訪談是相輔相成。
流程一般和個人訪談一樣，但不同點是在測試T和訪談I上。
測試：
不可避免，他們直接會相互交流，但好處是個人的問題可以得到群體性贊同，“這個我也發現了，我還以為是我一個人的問題”
訪談：
小組訪談，也被稱為焦點小組，是指調查者以一種無結構的自然形式與被調查者交流，通過傾聽一組從目標市場中選來的被調查者間的討論，從中獲取對一些有關問題的深度了解。
其中的問題，除了開始與個人訪談一致的訪談問題外，還需要添加之前個人訪談中出現的共同問題和特殊問題，以發動群體的廣泛討論，發現一些潛在的關鍵點。
但要注意，一群人里總會有“社交牛逼癥”，也就是意見領袖，用戶有時會因為受意見領袖發言的刺激而修改自己的發言，并且會加以主觀潤色，這很考驗主持人的控場能力，也得找個更為社交牛逼癥的理性主持人
（4）注意
尼爾森說過：“5個人測試可以發現80%的可用性問題?！?/p>
那么分成多個小組，每組五個人，就可以進行問題收集的迭代
也就是前面幾組可以收集到大部分顯見的可用性問題，如果開發足夠快，能快速解決掉前面問題，再用剩下幾組做測試，就能發現一些較小問題中的較大問題。
4. 結束與整理
- 表達感謝，送走用戶
- 整理數據，分析并可視化
在匯總完測試和量表數據后，出一份可用性測試報告，整理問題的優先級，然后交付開發，繼續推進上線工作。
同時根據問卷和訪談的數據整理出主要和次要的人物模型，人物模型后續大家感興趣的話，我再寫文章分享下如何簡單構建。
四、結尾
最合適的調研方法取決于調研目的、要解決的問題和生命周期中的階段。
經典調研方法論并不是要一成不變全盤使用，也不是毫不借鑒，而是要在實際訪談工作中，使用其理念，也就是定性和定量的運用模式、用戶情緒點的深刻把握。
很多產品和設計師，說自己所在團隊沒有多少資源可以用，做不了用戶調研，但還是用戶意識不到位，希望本篇文章的QTI方法能夠給大家啟發，其實成本真的不高（可能有點點高）。
如果你覺得分享的內容對你有所幫助的話，點個贊收個藏哦～
理論參考來源：《市場調研》《用戶調研與可用性測試》《用戶體驗面觀》
本文由 @loosaumin 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
- 目前還沒評論，等你發揮！
