以下文章來源於XuX遊戲 ，作者立風Ukyo
很多人會說，遊戲不同於產品，遊戲的設計點不像產品那樣來源於用戶痛點，往往玩家在見到某款遊戲前，也並不了解自己想要什麼樣的玩法，為什麼遊戲也要有用戶調研？
遊戲設計者設計遊戲，總會希望給玩家帶來一種與眾不同的心理體驗。而往往遊戲設計者和遊戲玩家之間存在著種種不同，使得遊戲設計者需要時刻了解，玩家所體驗到的是否就是他們所設計的。因此，在遊戲開發的不同階段，邀請真實玩家，對特定的遊戲內容進行體驗，以檢驗遊戲的體驗性和樂趣性。
遊戲用研的核心
解決問題，探尋可能。探尋真實的用戶需求與反饋，確保遊戲良好的用戶體驗。
遊戲用研的標準
及時：緊跟項目的開發節奏，時刻輔助項目開發。有效：需求明確，產出明確，結論可靠。可用：可以落實，可以直接改進。
用研測試的目標
基本目標：發現當前遊戲項目遇到的問題是什麼？可以定位問題並提供參考意見。進階要求：探索未發現的問題。多思考、多歸納，多分析潛在的問題和隱患。
完整的遊戲用研測試流程
完整的遊戲用研測試流程主要包括以下四個步驟。
一個合格的UE人員應該可以獨立負責整個流程。
1.溝通需求和確定目標
首先要和遊戲項目方進行測試的目標溝通，明確「問題是什麼」，和「用麼方式測試」，心中要逐步確定一份「測試需求列表」和「評價標準」。要始終記得——
本次測試就是為了解決這些問題！
溝通的對象
首先我們要知道找誰來溝通，一般是誰主要負責測試內容的就和誰主要溝通，通常都要和負責跟進相應模塊的責任策劃溝通較多，較為重要的系統也會和主策劃溝通。
還要拉上誰？如果測試內容有涉及到相關其他職位的人員，也需要與之溝通，如交互、視覺、美術、音效、營銷等。
溝通的核心
溝通需求時，我們需要圍繞著測試問題進行。對和需求方溝通問題，也要拿出來用研人的看家本事，進行一次「用研訪談」，以分析出我們需要的問題。
什麼問題——從來裡來——到哪裡去
什麼問題：需要通過測試解決或了解「什麼問題」。
為什麼想做這個測試？
比較想了解哪些內容？
目前有什麼設計上的難題和選擇麼？
從哪裡來：這個問題的背景和前因是什麼樣的？這個問題的必要產生條件是什麼？有意為之還是無心之作？
我們在開發中遇到過什麼問題麼？
當時還嘗試過什麼方案麼？
其他遊戲是怎麼做的？
到哪裡去：這個問題能夠帶來什麼樣的結果？此次測試需要產生什麼樣的結果可以輔助項目開發？
測試完你們更希望得到什麼結論？
下一步打算如何？
溝通的結果
確定「需求方最想了解的N個問題」，以此為方向，進行問題細化（見下一步驟「設計方案和測試步驟」）
測試前準備
在溝通確定測試內容之後，我們還有在執行測試前進行一些準備工作，來確保測試執行的可靠性，比如：
再次熟悉和試跑測試的遊戲內容，了解其中的詳細細節。檢查測試內容的穩定性和完成度，是否符合測試的條件。將可能存在的風險和漏洞上報，優化測試環境，並在測試中觀察這些問題的影響。
當然，在準備的同時，可能會有些需要繼續和需求方反覆溝通，這也是必不可少的。
2.設計方案和測試步驟
測試流程設計的原則
符合測試需求系統化情景化規範易用標準
我們開始設計測試方案了，還記得前面「需求方最想了解的N個問題」麼？
問題細化（重點！重點！啊）
核心還是圍繞需求問題，但一開始，不論是需求方還是UE人員，憑感覺提出的問題並不一定能夠準確定位到本質問題。為了能夠對問題進行到位的測試以及最終形成可以落地的方案，我們需要將問題進行細化。
細化問題的過程可以從發散思維到收縮思維，而且兩者可以反覆進行，直到你認為定位到了確切細緻的問題。
首先，發散思維，對問題所在的整體框架和上下流程進行整體的思考，從問題的表象到本質，儘可能的尋找相關的各項影響因素。
將問題放在框架內，可以輔助我們對與之相關的因素進行全面的分析。因此可以借鑑我們熟悉的分析模型，來幫助我們找到發散方向。
之後，收縮思維，將關聯性不強的內容逐步去掉，可以思考一下哪些因素對解決需求更有影響？是否存在受到不因人為影響出現的問題？測試性價比是否允許？
問題細化的目標是：我們可以將問題分解為能夠逐一驗證的子問題。然後將問題進行分類並列成表格。
設計方案
將前一步細化的問題列出來，並根據每個子問題，設計相應的測試方法。當然測試方法非常多樣，觀察、訪談、問卷、點擊熱點分析、心率記錄、腦電記錄、關鍵詞聯想等。我們這裡先不慢慢分析每種方法了，更何況研究方法的創新永無止境，需要多學習、多創新、多實踐、多總結。
撰寫方案
畢竟我們是在企業中工作的，執行前我們需要形成一個測試方案詳細的規劃測試的各個細節，來方便相關人員了解測試詳情（或者向老大申請資金）。整個方案包括以下幾個部分：
目的——流程——玩家——安排
測試目的：告訴相關人員此次測試的目的告訴領導：組織這次測試的意義（快表揚我！）告訴同事：這次測試的流程和分工（一起幹活比較快）告訴自己：再次梳理測試的需求和各個環節（自己可不能出錯）
測試流程
測試方案：前文所述，具體方法應該根據細化的問題的實際內容進行確定，不能簡單的做分問卷就交作業了。任務腳本：玩家用什麼順序來體驗遊戲？哪個環節需要引導？觀察記錄：需要提前準備好記錄工具，比如：測試設備、觀察記錄表單等。調查問卷：進行定量研究的準備，根據需求確定是否需要以及具體內容。訪談提綱：進行定性研究的準備，根據需求確定是否需要以及具體內容。
測試腳本
需要制定一個讓玩家可以順利體驗的流程，這個流程可以包括玩家實際操作、調查問卷、訪談、觀察等全部內容，因為有些調研目標不能通過單一方式得到結論。
這個流程的設計需要注意兩個原則：
1、系統性完整性
腳本內容需要系統的覆蓋所有需要關注的問題點。細化後的問題，需要能夠完整的體現在整個測試流程之中。
2、情景化自然化
為了保證測試結果的真實，需要儘可能按照玩家實際使用情景來設計測試流程，減少太多的人為幹預，讓玩家自然而然的完成測試內容，並表現出最真實的反應。
找個樣例，參考一下格式吧：
觀察記錄
我們需要做好觀察記錄單，來讓我們的測試工作更有標準且更有效率。每次測試可以根據實際調查的內容來設計觀察記錄單。但是好的記錄單能夠在任何時候都向人們提供著答案，比如：
查看任務進度時分析關注重點時記錄測試結果時
調查問卷
使用定量調研，需要保證測試樣本的基本數量。而往往有範圍的玩家測試，是樣本有限的情況，切不可直接導出結果，而僅僅可作為輔助參考內容。而這種情況，問卷設計也不應該以調查大量群體數據為主要目標，而是對測試樣本進行更為深入的分析和玩家行為的快速記錄。比如針對某個玩家記錄他在不同玩法的體驗反饋對比，玩家對某種操作的反應速度反應態度等。更可以作為後續深入訪談的切入話題。
訪談提綱
根據對玩家行為的觀察和記錄， 可以進行深入的訪談以了解更深入的內容。這裡許多訪談技巧和分析方法都來自於定性研究和相關內容，這裡也暫時不細談了
測試安排
當前面的步驟準備好時，我們可以做出較為詳細的測試安排，對於測試實際的客觀環境進行調度。
監測測試安排是否妥當的一個標準就是，其他UE人員能夠拿著這份安排順利執行測試呢？
3.玩家招募和執行測試
玩家招募是影響到測試質量的根本因素，因此必須用心。玩家招募的條件，取決於研究的需求，而招募質量決定了測試質量。
玩家構成和許多網際網路產品招募測試用戶就很像了，需要一部分正在使用或使用過產品的目標用戶，以及一部分符合開發者期望值的潛在目標用戶。
招募的數量，也是需要根據測試方案來確定（測試方式是根據測試需求確定的），玩家走訪、實驗室測試、街頭攔訪等方式需要的測試樣本量是不同的，還是根據實際情況來。
現場測試
一般來說，如果測試現場UE人員會分為兩組：引導者和觀察者。引導者負責進行必要的體驗引導、測試詢問、維護良好的測試環境、控制測試進程。而觀察者在一旁進行測試記錄，觀察玩家情緒、操作方式、記錄準備好的記錄工具上的關注點，以及未提前預測好的玩家表現出的其他反應。
4.反饋報告和後續跟進
敏捷反饋
在詳細的測試報告出來之前，快速的反饋測試結果，及時給出結論。對測試的情況和結果進行快速梳理，讓需求方第一時間了解大概的測試結果。
形式可以是多樣的，但核心是表達結論。
可以是腦圖形式，可以是表格形式，總之要快！
測試報告
測試報告是較為詳細和正式的測試結論匯總，可以將測試的詳細結論、結論分析、並輔以測試過程記錄（錄像錄音）、調查數據等形成較為完整的測試報告。
事後跟進
並不是給出了反饋報告我們的工作就結束了，我們在給出了改進意見之後，也要和需求方進行溝通和下一步迭代計劃的溝通。
並且在產品改進之後，更要主動參與測試，來驗證我們的改進意見。以及根據後續玩家的反饋進一步挖掘更深層需求，以及繼續關注還有什麼潛在問題。