長篇闡述:業內資深人士探討用戶體驗(UX)的定義和作用

原文作者:Sebastian Long  譯者:Megan Shieh

幾乎所有的領軍遊戲開發商都提倡以玩家爲中心的開發過程和文化。開發團隊通常致力於‘玩家反饋’這件事,包括社區管理、數據分析、用戶體驗(UX)設計以及用戶調查。

幾十年來,UX人員不斷地通過心理學和人類分析學來幫助開發團隊改善開發過程,同時提高玩家的遊戲體驗。用戶體驗是提高電子遊戲價值的關鍵因素,然而專業的UX知識似乎只存在於大型的工作室和發行商中,其他中小型的開發社區卻無法深入地瞭解到“用戶體驗”這一關鍵元素。

什麼是用戶體驗?

用戶體驗(UX)是一門特殊的設計學科,以玩家的心理、行爲、思維過程和遊戲技能爲中心,確保你設計的遊戲體驗能夠真正反映到玩家的腦海裏。應用對玩家行爲和思維過程的掌握,並將其與數據收集、設計過程、對真實玩家進行的多種測試相結合。

開發團隊中的每個人都是設計師。每個看似很小的選擇都會影響到玩家的遊戲體驗,無論做這個選擇的人是誰。程序員選擇網格UI佈局而不是列表佈局;法務部門要求玩家必須看完最終用戶許可協議(EULA)才能註冊遊戲;配音人員決定哪些詞語需要重音強調,等等。遊戲開發的過程中,需要抉擇的事情實在是太多了。每一個微小的決定都有可能對玩家的整體體驗產生微小或巨大的消極影響,但我們可以想辦法避免這種情況的發生。

在作出最終決策之前,將這些設計擺放在真實玩家的面前,瞭解玩家的真實想法並觀察他們的行爲。有了這些知識,開發團隊可以集體改變他們的想法、迭代他們的設計、證明每次變更的合理性,並確保他們所做的每個最終決策都是正確的。

UX的職責是:關注設計決策對玩家產生的實際影響,並協助開發團隊做出明智的最終決策。因此僱用專員去負責UX實際上是一項投資,讓他們成爲團隊中的“玩家的聲音”,這麼做可以指導團隊的注意力、評估設計決策、改善團隊的判斷力,同時促進交流。

UX人員協助開發團隊設計,然後將這些設計對真實用戶進行測試,多次重複這兩個步驟,直到大家都滿意爲止。這一過程減少了產品設計所固有的主要風險——比如“太過複雜”、遊戲內容太難理解。如果玩家“看不懂”遊戲內容,那你可能就需要一遍又一遍地返工。
總而言之,UX可以推動遊戲質量。

Nintendo-Mobile(from trustedreviews.com)

Nintendo-Mobile(from trustedreviews.com)

爲什麼用戶體驗如此重要?

面對自己精心製作的物件或非常熟悉的事物時,人們通常無法保持客觀的心態。我們時常會忘記“遊戲的設計”與“玩家的真實喜好”之間可能存在差異。這類認知錯誤時常會對遊戲帶來消極的影響,畢竟我們認爲好玩的東西,玩家不一定感興趣。

“玩家的實際反應和開發者預測的反應是否相符?”這是一個非常重要的問題。如果開發者不知道答案的話,可能會在本來就已經極具挑戰性的開發過程中造成不必要的混亂:

玩家會理解遊戲規則嗎?他們“看得懂”嗎?我們是否需要再添加幾個特性?目前現有的特性夠用嗎?遊戲效果會符合我們的預期嗎?遊戲體驗夠不夠好?可以發行了嗎?我們需要重點迭代哪些部分?

沒有積極地去尋找這些問題的答案,或者在沒有任何根據的情況下去猜測這些問題的答案,可能會導致遊戲成品與預期不符(玩家覺得這款遊戲不好玩),結果開發團隊投入的時間、精力以及金錢都打水漂了,粉絲也都跑掉了,收益什麼的就更別指望了。

爲什麼玩家會不喜歡我們的遊戲?

在遊戲製作的過程中,爲了改善設計以及遊戲與玩家的交流形式,開發團隊需要不斷猜測玩家的思維方式、感知方式、學習方式還有他們可能作出的反應:“我認爲當玩家看到敵人衝過來的時候,會往反方向跑。”這些猜測時常會出錯,玩家的實際想法和行動可能會和你的想象大相徑庭,這些差異出自於人的本質。

作爲創造者,你有時無法意識到差異:

這已經是老生常談了,開發人員靠自己的遊戲“太近”,以至於無法客觀地以玩家的感知方式和視角去看待這款遊戲。這種扭曲的感知方式可能會導致不必要的迭代,或者從頭到尾都意識不到開發者和玩家在遊戲體驗之間存在的差異。

針對“新手玩家”來設置操作提示和新手教程其實很不容易,因爲你已經是這個遊戲的“專業玩家”了。玩家可能會“看不懂”你的新手教程,裏面呈現的內容對於他們而言可能會太過複雜。

爲普通人(兒童,萌新或休閒玩家)設計遊戲時,錯誤的假設會對你的設計理念產生消極的影響,你最終設計出來的遊戲可能誰都不適合玩。

如果我們試圖測試或觀察玩家與遊戲的互動,就很難評估玩家玩遊戲時的情緒。不管是玩家剛上手時的即刻情緒,還是他們已經玩了幾天、幾周、幾個月之後的情緒,都很難評估。儘管這類數據是迭代的關鍵,但團隊到手的數據往往都帶有偏差,而且不易分析,如果處理不好的話,很可能會打擊開發團隊的士氣。

由於玩家不善於內省和解釋自己的情感,所以他們不會理解開發者從遊戲體驗角度做出的設計,而過於注重玩家的細節反應可能會稀釋或誤導項目的意圖。創建焦點小組或者直接詢問人們“這個好不好玩?你會花錢買它嗎?”,這種做法幫不了你。

這種障礙可能存在於企業文化或開發過程中:

無論從什麼時候開始對真實玩家進行測試都感覺“有點太早”。這種拖延常常導致團隊將必要的反饋收集過程推遲到來不及的時候。結果這一步驟就會變得太複雜、太昂貴或者太難應對。

一旦單個特性和多個組件開始融合在一起,開發者就很難領會到遊戲構建的大局。如果無法總覽大局,要放棄任何特性或者想法就變得非常困難,而團隊就會因此面臨“偏航”的風險。

有的時候,工作室很難在“開發團隊覺得好的特性”和“大部分玩家在意的東西”之間找到平衡。如果開發團隊缺乏自信,那麼玩家的聲音就會蓋過開發團隊的想法。

上述難題無論大小,對全球的遊戲開發者來說都是一種障礙。它們可能會導致意外的“認知摩擦(cognitive friction)”,比如UI(用戶界面)、控制操作和遊戲規則理解,等等。最終成品的玩法可能會不適用於之前擬定的目標受衆。這些因素對遊戲趣味、遊戲評價以及最終商業成果都有着很大的影響。

儘管這些難題的存在不可忽視,但解決這些問題的責任和對“玩家科學”知識的掌握卻並不屬於傳統遊戲開發的範疇。開發團隊時常會考慮這些問題,但往往沒有權利去採取必要的行動。

此外,這些難題的出現會對開發團隊日常的士氣和公司文化產生影響——它們會加劇人們對個人創造性產出的焦慮,引起團隊成員間的衝突和權力鬥爭,如果不知道“什麼是對的”,爭論的主題就會變成“誰是對的”。

我們該如何克服這些難題?

爲了減輕上述風險,每個開發團隊中都需要有這麼一個人:

能夠客觀、公證地對待每個創意點子。

能夠完全理解不同玩家感知、思考和學習的方式。

知道如何與真實玩家交互,從而收集特定的、可信的反饋。

可以一對一地,也可以整體地評估玩家對遊戲機制的體驗。

可以從一開始就擔起UX設計的重任。

以上就是用戶體驗專員的職責。

用戶體驗的建立是爲了能夠讓開發人員瞭解如何針對忙碌的普羅大衆設計遊戲,它是遊戲開發範疇之外的衍生學科。UX的存在已有幾十年之久,可以運用到各種各樣的產品設計中,比如噴氣式戰鬥機座艙、軟件、醫療儀器、各種APP以及實體產品。所有的設計師都和遊戲開發者一樣,需要面對上述難題。然而實際上,遊戲開發者卻是最晚啓用用戶體驗的。但我們正在迎頭趕上:在過去的5年裏,幾乎所有主要的遊戲發行商和開發商都在內部建立了UX團隊,聘用那些能夠利用玩家科學來實現開發者的創造性願景的人。

hungry-shark(from gamasutra)

hungry-shark(from gamasutra)

UX團隊中通常包含以下4種角色:

用戶體驗設計師:負責視覺設計,運用玩家心理學來完善遊戲的設計

用戶調查員:負責面向真實玩家的遊戲測試和調研

數據科學家:通過博弈分析以及對洞察力的評估來捕捉玩家的行爲

UX領頭人:用戶體驗研究和工作室文化中的指揮級人物。

上述專業人員的結合能夠幫助開發團隊形成一個證據驅動的、結構化的開發過程。

用戶體驗的具體作用是什麼?

UX既是一個知識體系也是一系列正規的流程。每個團隊的使用方法各有不同,取決於工作室的核心能力、遊戲風格、開發階段、面臨的主要問題,等等。我們將依次介紹每個開發階段的UX任務,以及它們是如何克服上述難題的。同樣的UX流程適用於任何遊戲類型,規模或業務模式(甚至包括現場遊戲)。

概念&構想 設計&前期製作 生產

用戶體驗反饋會在開發的過程中發生變化。在擬定項目概念的時候,我們的想法是非結構化的,狂野的,令人興奮的。爲了幫助激發和集中團隊的創意,UX團隊會進行構想和概念調研:“我們的受衆是誰?我們想做一款什麼樣的遊戲?”然後找出最傑出的同類遊戲:“爲了確保出色的遊戲體驗,我們的競爭者們都整合了哪些小細節?”

開發團隊可以從目標受衆的遊戲習慣和特點中學習,因此UX團隊會通過採訪進行“探索性研究”,從而發現玩家對概念藝術和原型的期望。考察競爭對手的遊戲體驗,從中尋找弱點和機會;採訪該類遊戲的粉絲,從中瞭解他們熱愛這類遊戲的原因,以及他們認爲這類遊戲需要改進的地方,等等。作爲協作研討會議的一部分,這些數據通常會以陳述、書面報告的形式提供給開發團隊。

緊接着,遊戲的設計支柱圍繞着特定的想法和原型逐漸具體化,這時,UX團隊需要越來越集中的反饋和對項目細節的貢獻:通過反覆迭代的方式來驗證設計決策的好壞,然後採用測試和研究手段對它們進行評估。專注於前期的迭代和項目原型避免了後期可能出現的多次返工。
UX設計師能夠幫助開發團隊做出明智的設計決策:UI(列表還是網格?)、交互設計(按鈕還是手勢?)、反饋設計、操作提示、圖標設計、心理模型、顏色、語言、術語,等等。

如果沒有UX的幫助,上述的所有設計決策都只能根據開發者的憑空想象:“我認爲玩家會使用這種強化工具,而且他們會理解它的作用”。但開發人員不像玩家,他們往往“太接近”一個項目,無法做出有效的假設。因此,這個“虛構玩家”反映出來的會是開發人員自己的知識、經驗以及對世界的看法,從而導致存在紕漏的設計決策。

通過提出問題以及十分全面的分析,UX設計師意圖在遊戲設計師做決策的時候就一擊即中,而不是等到事後再進行分析。UX設計師可以斷言,基於他們對人類視覺感知的瞭解,“玩家可能很難看到反饋,因爲它與淺色背景的對比度不夠”。 因此,他們可能會基於對人類注意力的理解將視覺上的複雜性標記出來;等等。

玩家反饋與用戶體驗有什麼關係?

遊戲是複雜的,而一些缺陷會偷偷溜進代碼中。開發團隊可能會因爲距離項目太近而看不到它們,所以我們需要利用真實玩家的視角來找到它們。

每週,用戶調查員都會拿着最新的特性,通過專門設計的實驗將其對真實玩家進行測試。他們會列舉出一些關鍵的目標問題:“教程的教學效用如何?玩家能可靠地識別敵人的弱點嗎?”,並設計出測試玩家答案的方法,然後將他們的見解反饋給開發團隊。每次遊戲測試都使用不同的測試玩家,這樣你的數據就永遠不會被玩家的假定知識所影響,同時也能不斷重新審視遊戲機制的易學性。

有了數據科學家的參與,開發團隊就可以更好地理解玩家的行爲,甚至可以對開發進程的“大局總覽”進行跟蹤。對於在線或者體驗版的遊戲,受過培訓的社區管理人員也可以利用現有的粉絲基礎來了解他們的遊戲體驗和意見建議。

通過將潛在的用戶體驗問題分解爲多個層次,我們可以開始對它們進行逐個探究。

測試的頻率和焦點在很大程度上取決於具體項目的自身情況,但每隔幾周的情況並不少見。測試在開發初期就開始了,首先實施小型的研究項目,通過原型和紙上設計來檢查可用性、易用性和易學性。接着進行更大、更長時間的測試,覆蓋面包括玩家的情緒、主觀印象以及難度的平衡;每個測試的目的都是讓遊戲更接近完美。

但是情感呢?我們也能測量嗎?

將項目中的較小部分整合到一起之後,開發團隊就會轉向更大的問題:我們的遊戲好玩嗎?

用戶體驗的科學基礎(認知心理學和實驗心理學)確實提供了一些手段來探究玩家的動機、情感和滿足感。然而這種無形的數據跟白紙黑字的東西比起來更難獲取和分析,對實驗控制也有着更高的要求——精心編寫的問題、更多的測試人員、標準化的方法、隨着時間的推移採取多種措施。

在趣味性的探究方面,UX團隊會反覆多次地測試幾十甚至幾百位真實玩家的通關體驗,每次測試均提供精心收集的主觀反饋和分析數據,從而更具體地理解這些玩家的整體遊戲體驗。通過正確的操作,一款遊戲的體驗可以隨着時間的推移實現基準測試、自我審查和比較,從而形成先前提到的“大局總覽”。

許多沒有采用UX的團隊到了這個階段纔會開始收集玩家反饋,但到了這時,他們已經錯過了能夠省錢、省時間、避免後期多次返工的大好機會。如果沒有在過去的幾個月或幾年裏彌補可用性和易學性方面的缺陷,那麼團隊在處理突然出現的一系列根本性缺陷的時候,可能會感覺非常吃力。

這些測試報告需要接受仔細的分析。因爲玩家不善於用語言來解釋自己的情緒和行爲,所以他們時常會將可用性和理解性上的挫折感與樂趣混爲一談。因爲玩家無法理解遊戲體驗的設計意圖,所以他們呈現出的細微反應可能會對開發團隊產生誤導。而所有的UX學科(設計,研究,數據科學)都依賴於它的學術背景,所以可以確保數據被妥善地收集和分析,並以偏差較小的形式呈現給開發團隊。

玩家與開發人員不同,他們可能缺乏我們認爲理所當然的語言、內省和經驗,因此開發團隊不應該僅僅依靠玩家的細節反應來指導設計。

觀察和測量情感的技術、先進的數據可視化技術、生物識別技術以及眼球追蹤技術,這些活躍的研究領域在本文中沒有進行具體的分析,因爲文章已經很長了…實在放不下。

信息迭代文化

UX設計師、用戶調查員和數據科學家與生產循環中的開發團隊一起合作,每個人都有自己獨特的聲音,他們相互協調以完善設計意圖的實施。他們會使用定量和定性的方法來防止和診斷缺陷,彙集細節和大數據。

注意,這裏並沒有強調玩家的意願。因爲UX不會爲了焦點小組的意見而去改變一款遊戲,也不會違背創意團隊的意願。成功的標誌不一定是玩家的肯定:“我喜歡這個”或“我會花錢買這個”,而是開發團隊爲自己設定的指標:“玩家是否能夠表現出對遊戲的理解,並按照我們的意願行事?”“以通關時間和死亡人數衡量出的遊戲難度,是否符合你的意願”

玩家的行動往往比他們的語言更加響亮。每項測試的設計都是爲了評估玩家在實境中的行爲並獲取結構化的分析數據,而非他們親口表達出來的意見。

如果我們不考慮用戶體驗反饋會怎麼樣?

如果不積極地引導工作室走向這種知識尋求和反饋收集的文化,開發團隊就沒有權力自己去探尋這類數據。如果沒有一位可以讓這些事情發生的領導,那麼開發團隊就會避開這些問題,接着做其他的事情。其實這是可以理解的:需要返工的想法,或是發現自己精心製作的寶貝其實達不到要求,都不是什麼值得開心的事情。

但盲目前進是錯誤的。如果不解決以玩家爲中心的難題,他們就是在玷污工作成果。幸運的話,你會需要重做一些工作;情況較差的話,有的工作室甚至會直接破產,或者遊戲發行後得到不冷不熱的反響。最好在早期的時候就進行UX投資,把每個細節都做好來;重做幾天的工作總比重做幾個月、幾年的工作要好得多。

那些認爲遊戲“還沒準備好”或者“還處於不斷變化中”的開發團隊正面臨着一些不確定性,而UX的設計就是專門用來克服這些不確定性的。

那些涵蓋“糟糕的用戶體驗”的遊戲都是你從未聽說過的,因爲這些遊戲從未登上過熱搜。失敗的遊戲和工作室不會將差評、裁員或破產歸咎於“糟糕的用戶體驗”,開發者們有自己的一套形容詞:難以接近、雜亂無章、笨重、過於簡單、不平衡、膚淺、抄襲、榨取金錢、貪婪、欺騙性、毫無創意……其實就是換個方式說“糟糕的用戶體驗”。

本文開頭列出的挑戰並不總是表現爲單一的用戶體驗問題,但你會發現任何一款遊戲在應用商店裏的差評都是有關用戶體驗的:操作困難,難以理解、不體貼的設計,等等。這些議題對玩家而言非常重要,因此它們對你來說也很重要。

我們應該讓誰負責“UX”?

簡單的回答是:每個人。項目中的每位貢獻者都會在玩家的體驗上留下一些印記,無論是在聲音上、視覺上、玩法上還是其他方面。所有的開發人員都是造物者,他們所做的每個決定都要爲玩家的體驗負責。

用戶體驗的某些部分可以在不僱用UX專員的情況下啓用,例如遊戲測試、調查和分析數據收集。但是,在調研、心理學和交互設計方面的專業知識是無可替代的。玩家數據在改變項目進程方面具有強大的威力,因此你需要確保自己投資的是有是可靠技能的UX人員,避免非專業的數據收集、帶有偏差的分析結果以及不科學的研究。

部分UX可能已經存在於你的開發流程中了:玩家測試、分析數據、現有的玩家調研、正式的競爭對手分析,等等。

開發人員總是覺得現在“測試”爲時尚早,但是等你認爲應該開始測試的時候就爲時已晚了。

好的設計從第一天開始,不要“等到明天再審查”,因爲“合適的時候”永遠不會到來。投資在用戶體驗上的時間和精力可以爲開發後期省掉許多麻煩。拖延只會降低UX的潛在價值。我們無法收回已經投入到遊戲開發裏的時間。

試着分析一下工作室曾經收到的新聞評價和應用商店評價;他們的批評是否來源於對遊戲的不理解,或者是教程的影響?評論是否顯示玩家遇到了意外的使用困難,或與反饋,平衡或導航相關的問題?各種分析數據是否低於我們預測的指標?如果是的話,你就有證據證明在下一個項目中投資UX肯定會得到回報。

時間是最大的挑戰,早期階段的節奏可以大大提升開發後期的速度。對於那些從未接觸過UX領域的團隊而言,要他們每個月撥出預算和時間來進行測試和研究可能會感覺有點牽強。但你要知道,這些角色確實存在,並且在所有創造性領域中繼續蓬勃發展,在產品生產的整個生命週期中,用戶體驗人員的付出並沒有比別人少,爲了提高產品質量他們投入了大量的時間和精力。

以玩家爲中心的流程不僅僅是僱傭新人和撥出預算這麼簡單;公司文化可能也需要改變。如果工作室不願意將公司引向這種有同理心的設計流程,並授權這些員工進行改變,那麼僅僅僱傭UX專員是不夠的。

我們可以從已經採用了玩家科學的工作室那裏學習到許多東西。EA的Veronica Zammitto於2017年在GDC(遊戲開發者大會)分享了他多年來的經驗;Ubisoft、Riot和Epic也都分享了他們在UX方面的經驗。CeliaHodent近期出版的新書闡述了UX和神經科學在遊戲開發中的適用性。你可以找到大量關於用戶體驗的具體方案、流程和案例研究信息,尤其是通過IGDA GURSIG社區(遊戲邦注:全球最大的非盈利遊戲開發者協會)和用戶體驗峯會。讓我們一起學習和分享,爲我們的玩家提供更好的體驗。

摘要

遊戲用戶體驗是一門科學和設計學科,可以幫助我們克服製作遊戲時遇到的困難,實現開發者的體驗設計意圖。採用正式的流程和工作角色,利用大量爲人類設計的學術知識來發現遊戲設計中的缺陷,以及遊戲與玩家溝通的方式。

缺少了用戶體驗,遊戲就會缺乏客觀性。這些因素最終會影響到遊戲的感知質量、反響和樂趣。

有了這四個關鍵角色(設計、調研、數據科學和領導力),開發者就能圍繞着開發核心(設計、實現、測量和評估)形成一種更有同理心和自信的工作室文化,從而帶來更好的遊戲、更快樂的員工和更高效的工作室。

將這些實踐應用於遊戲開發可以構建一款成功的遊戲,更快、更省錢並且更接近設計團隊的創意願景。

本文由遊戲邦編譯,轉載請註明來源,或諮詢微信zhengjintiao

Nearly every major game development studio is pivoting toward a more player-centric development process and culture. New internal teams and staff embodying the ‘voice of the player’ are commonplace, including Community Management, Analytics, UX Design and Games User Research.

For decades, ‘UX’ (or ‘user experience’) staff have been helping gamedev teams improve their development processes and craft better gameplay experiences for their players by leveraging psychology and human sciences. UX has proven to be an instrumental voice in crafting seminal video games – The Last of Us, Portal, Destiny, Monument Valley, Clash Royale, to name but a few – yet much of this games UX knowledge is siloed inside larger studios and publishers, and inaccessible to the wider gamedev community.

UX’s diversity of phrases, processes and perspectives can be confusing – What does it do? Who is it for? So, for developers unfamiliar with UX or wanting an easy overview: What is Games UX? What does it do for you and your team? How can I know if my game needs UX attention? What is the difference between UX and UI?

About the Author
Sebastian Long is a Games UX Researcher at multi-award-winning UX research and analytics consultancy Player Research. Seb has led UX research projects for ~200 games, including best-loved franchises like FIFA, Little Big Planet, Harry Potter, LEGO, Sonic, Talking Tom and many more titles, from indie through to AAA.

What is UX?

User Experience (UX) is a particular discipline of design, centred around the psychology of the end-user – or in gamedev’s case, the player – and their behaviours, thinking processes and capabilities. UX is part of a large toolkit used to ensure the experience that you’ve designed is truly reflected in the mind of your player. It applies a true knowledge of players’ behaviours and thinking processes, and couples it with data-collection, an iterative design process, and many types of testing with real players.

UX is where the science of the player meets the art of game design.

Everyone on your gamedev team is a designer, not just those with ‘design’ in their job title. Seemingly small choices made by every one of the team will impact how the game experience manifests in players. A programmer choosing a UI grid layout over a list, or a legal department demanding that players absolutely must scroll to the bottom of the EULA to proceed, or a voiceover artist choosing which words to emphasise in a spoken tutorial prompt. Each small choice could have minimal or monstrous implications on the players’ holistic experience. But we can be detached from the true impact of our choices; there are just so many to make.

Resultantly, every gamedev discipline could benefit from being shown the actuality of their choices on how players truly think and behave. With this knowledge teams can collectively change their minds, iterate their designs, justify changes, and gain confidence that their final choice is the right one.

This is the remit of UX: focusing on the true impact of design choices on players – and helping teams collaborate to make those choices. Hiring staff to “do UX” and become a player-centric voice in the studio is therefore an investment in directing the team’s attention, reality-checking design choices, informing the team’s judgement, and facilitating communication.

UX provides constant guidance, going back-and-forth between aiding design and then testing it on real players. As a whole, this process reduces key risks inherent to making things for people to use, such as ‘complexity-creep’, games being difficult-to-understand, or having to re-do work over and over if players “don’t get it”.

UX helps make better games.

Why is UX needed? Can’t we just be more thorough?

It is extremely difficult to remain objective about things we’ve crafted ourselves, or things we’re extremely familiar with. We can easily become oblivious to causes of disparities between the design of our game and real player’s’ actual experience of our game. This can damage our games; the fun that weknow exists might not be resolved in our players.

How does UX help the team?

The problem of not knowing if players are experiencing the game as intended can result in  unnecessary confusion during the already challenging process of development:

Will players understand the game rules? Will they ‘get it’?
Do we need more features? Are the ones we have enough?
Is the friction in the game where we intend it to be, and balanced?
Is the game experience correct-enough for us to release yet?
Which parts of the game needs our focus during iteration?

Leaving these questions unanswered or – worse –  guessing incorrectly, leads to games being undesirably different from their intended experience – players don’t ‘find the fun’ – leading to lost development time, lost revenue and lost fans.

Why might players not ‘find the fun’ in our game?

In crafting a game you’re having to constantly guess how players might think, perceive, learn and react, in order to inform the design of the game and how it communicates itself to players: “I think a player would see that ‘enemy nearby’ feedback and head in the opposite direction”. There are many innocent reasons for these guesses to be wrong, and for the players’ thoughts and actions to undesirably differ to your intent.

These disparities are fundamentally human in nature, not technical; they’re about predicting thoughts, behaviours and perceptions of other people. Being incorrect isn’t a symptom of naivety or inexperience, but is inherent to designing artefacts for other people to use.

Below are some of the most impactful player-centric challenges teams face during development; perhaps you’ll recognise your own gamedev experience in some of them:

There are barriers to seeing disparities as creators:

Teams inevitably become ‘too close’ to their project; they cannot play nor perceive the game as a real player would. This skewed perspective can lead to needless iteration, or simply never recognising where experiential disparities exist.

Designing instructions, prompts and ‘onboarding’ non-expert players to your mechanics is difficult because you’re an expert in the game. There is a risk that players ‘don’t get it’, or tutorials becoming heavy-handed.

Designing games suitable for players who aren’t like you (such as children, novice or casual players) risks incorrect assumptions about that audience unduly influencing your design discussions. There is a risk you’re making a game for no one.

…and barriers to recognising these disparities in others…

If we try to playtest or observe real players interact with our games, it is very difficult to assess a player’s emotion as they play. This is both in assessing their moment-to-moment feelings, and in considering their engagement over days, weeks, months. Such data is vital to iteration, but is hard-to-obtain without bias, is difficult to analyse, and can be demoralising to the team if it isn’t handled well.

Because players are unskilled at rationalising and explaining their emotions, and they won’t appreciate the experiential intent for the game, their verbatim reactions risk diluting or misguiding the project’s intent. Focus groups, or asking people “is this fun, would you buy this?” is not the answer.

…and barriers can exist in company culture or processes …

It never feels like the right time to ‘check’ the player experience: “it is too early to playtest right now!”. This reluctance often results in teams putting off essential feedback-gathering processes until far too late in development. This risks late-flowering flaws being too complex, too expensive, or too far-reaching to address.

It is hard to appreciate the bigger picture of a game build once the individual features and components start to come together. Justifying saying NO to features or ideas is incredibly difficult without this big picture view, risking feature-creep.

Studios can find it hard to balance attention between what the development team consider interesting to make versus what matters most to players, if they lack a confident, player-centric voice in studio leadership.

These challenges are a hurdles for game developers all over the world, large and small. Each challenge can result in games having ‘cognitive friction’ in unintended places, such as UI, controls and communicating game rules. They can result in games being mechanically unsuited to the audience they were intended for. These factors are hugely influential on fun, on game reviews, and ultimately on commercial success.

But despite the significance of these challenges, the responsibility and ‘player science’ know-how needed to address them falls outside the remit of all traditional game development roles. Teams often think about these problems, but often aren’t empowered to take necessary action to overcome them.

Furthermore, the looming presence of these difficult-to-answer questions can have an impact on day-to-day team morale and company culture. They contribute to anxiety about one’s individual creative outputs. They cause conflict and power struggles as the team’s interpretations differ and clash; without knowing what is right, conflict can devolve into who is right.

How can we overcome these issues?

To mitigate these risks we need a someone in the team that:

…can maintain creative impartiality and objectivity

…truly understands how different player audiences perceive, think, and learn

…knows means of engaging real players to gather specific, trustworthy feedback

…can assess player’s experience with game mechanics both piece-by-piece, and as a holistic whole

…can take responsibility for the player-centric process right from the beginning of development

These are the responsibilities of ‘user experience’ professionals – or ‘UX’ for short.

UX, as a wider discipline outside of gamedev, has been built upon decades of actionable knowledge on designing for busy, everyday people. User Experience professionals embody ‘user-centricity’ across all sorts of design domains, from jetfighter cockpit design, to admin software, to the design of medical instruments, to apps, phones and physical products. Designers of all kinds of everyday things have the same human-centric challenges listed above in common with gamedev, yet gamedev is among the slowest adopters of UX thinking and processes in response to them. But we are catching up; in the last 5 years UX groups have been built inside nearly every major game publisher and developer globally, hiring individuals who’re passionate about helping gamedev teams realise their creative vision using player science.

Responsibilities are typically broken into 4 key job roles:

User Experience Designer, tasked with visual design, applying player psychology knowhow to support game design

Games User Researcher, charged with running playtests and research sessions with real players

Data Scientist, who captures player behaviour through game analytics and evaluates for insight

UX Leadership, a Director-level voice for player-centrism in process and studio culture

Together, these four professional roles empower studios to follow an evidence-driven and structured development process, leveraging ‘player sciences’.

What does UX do, exactly?

UX is both a body of knowledge and a series of formal processes. Each team uses these differently, depending on the core competencies of the studio, the game genre, the development stage, the challenges that define the project, and so on. We’ll go through each development phase in turn to outline the UX tasks, and how they overcome the risks above. No matter what genre, scale or business model – even on live games – the same UX processes apply.

UX feedback changes over the course of development. Each item above is a formalised UX approach, with specific objectives, tasks, sample sizes and deliverables. Each is designed to overcome common design missteps made during that phase.

At a game project’s conception, ideas are unstructured, wild, and exciting. To help inspire and focus creative teams, UX conducts ideation and concept research: “Who is our player? What do we want to make?” and identify the best-in-class experiences: “What little details do competitors integrate to ensure great experiences?”.

Game design teams can learn from their audiences’ play habits and traits, so UX teams conduct ‘exploratory research’ through interviews to discover players’ expectations of concept art and prototypes; examine competitor titles for experiential weaknesses and opportunities; interview genre-fans to understand their fascinations and frustrations, and so on. These data are typically provided to teams in the form of presentations, written reports, and as part of collaborative workshops.

In this way, teams can be helped to discover their game in themselves and in their players.

OK, we have an idea!

As a game design pillars crystallize around specific ideas and prototypes, teams need increasingly focused feedback and contributions to the specifics of the project: iteratively informing design choices and then assessing them using playtests and research methods. A focus on up-front iteration and informing prototypes avoids having to double-back later in development.

UX Designers help teams make informed choices about UI – List or grid? – interaction design – Button or gesture? – feedback design, prompting, icon design, mental models, colour language, terminology…

Without UX, each of these choices is made by developers imagining how players feel or interact with that thing: “I think a player would use this power-up and then they’d understand what it does”. But developers aren’t like players, and they’re often ‘too close’ to a project to make valid assumptions. Consequently, this imaginary player will too closely reflect the developer’s own knowledge, experience and perspective on the world, leading to flawed decision-making.

our player-base is diverse, dynamic, and dissimilar to you.

UX tries to make choices right-the-first-time by raising questions and contextualising their impact as the choice is being made, not in hindsight. A User Experience Designer could assert that “Players might have difficulty seeing that feedback because it will have insufficient contrast against the light-coloured backgrounds” based on their knowledge of human visual perception. So too they might flag creeping visual complexity based on an understanding of human attention; and so on. A UX Designer’s output might be documentation like wireframes or mockups, but also full-fidelity art, reports, or simply in collaborating with existing UI Design and Game Design peers.

Where does player feedback fit in?

Games are complex, and some flaws will slip through into code. The team will likely be too close to the project to see them, so instead we’ll need to leverage real players’ perspective.

Week by week, Games User Researchers take a recent build, reflecting the most up-to-date design choices, and test it using specifically-designed experiments with real players. They’ll take research questions: “Can we prove this tutorial is effective at teaching? Do players reliably recognise the enemy weakspot?” and devise means of testing players for answers, followed by presenting their insights back to the team. Using different players for every single playtest means never being caught out by assumed knowledge in players, and constantly revisiting the learnability of your game mechanics. UX Research is traditionally delivered as a written report or presentation, or using internal issue-tracking tools like JIRA.

With a Data Scientist involved, player behaviour can be visualised and better understood, even allowing metrics to be tracked over time for a ‘bigger picture’ of development progress. For live games or titles in early access, Community Managers with research training can also leverage access to their fanbases for insight into their experiences and frustrations.

By trying to break potential UX issues into layers we can start to explore them in isolation.

The frequency and focus of playtests depends greatly on the challenges of the particular project, but every-few-weeks is not uncommon. Playtests start early in development, with small studies using prototypes and on-paper designs to check usability, accessibility and learnability. Later they’ll move to larger and longer playtests covering the player’s emotions, subjective impressions, and difficulty balancing; each aims to bring the game closer to excellence.

But what about emotions? Can we measure those too?

Once smaller pieces of the project come together, teams move onto the bigger questions: is our game fun?

UX’s foundations in the sciences – Cognitive and Experimental Psychology – do provide some means to explore player’s motivation, emotion and satisfaction, however, such ethereal data is harder to obtain and analyse than the black-and-white, observable outcomes of good usability and learnability. There is greater need for experimental control, carefully written questions, more playtesters, standardised methods, and taking measures over time.

Asking loaded, leading or mal-timed questions can lead to ‘bad data’

UX teams exploring fun rely on iterative full-game playthroughs with tens or hundreds of real players, each providing carefully-gathered subjective feedback and analytics data, toward a more concrete understanding of their holistic experience. Conducted correctly, a game’s experience can be benchmarked, checked and compared against itself over time, forming the ‘bigger picture’ that teams need to make big decisions.

Many studios without a UX voice wait until this point to begin getting player feedback, in doing so they have bypassed the majority of opportunities to save time and money avoiding the redesigns they’ll discover are necessary at this stage. Without having eked out the usability and learnability flaws in the preceding months and years, teams can struggle to handle a sudden barrage of fundamental flaws.

These full-game playthroughs need careful analysis. Because players lack the introspection and language to explain their emotions and explain their actions, it is common for usability and understandability frustrations conflate their feedback on fun. Because players cannot appreciate the experiential intent of the game, their verbatim reactions can be misleading. All the UX disciplines – Design, Research, Data Science – lean heavily on academic backgrounds to ensure data is soundly collected, analysed and presented to mitigate bias.

Players can lack the language, introspection and experience we take for granted in ourselves; teams shouldn’t rely only on players’ verbatim responses to inform design
Techniques for observing and measuring emotion, advanced data visualisation, biometrics and eyetracking are areas of active research – some of many developments in player science that this article doesn’t have room to cover.

A Culture of Informed Iteration

Together, UX Designers, Games User Researchers and Data Scientists work with teams round-and-round the production loop. Each has a particular voice, harmonising to refine implementation of the design intent; they’ll prevent and diagnose flaws, using quantitative and qualitative approaches, bringing together fine detail and big data. Each of their perspectives is required; omitting any one may lead to an uninformed conclusion.

Note the lack of emphasis on player’s opinion. UX doesn’t bend a game to the whims of a focus group, nor against the will of the creative team. Success isn’t necessarily marked by players saying “I like this”  or “I’d buy this”, but pragmatically by metrics set by the team themselves: “Are players able to demonstrate understanding of the game, and behaving as we intend them to?” “Does the difficulty, measured by completion time and deaths, align with our intent?”.

Players’ actions often speak louder than words. Any Developer that has attended a proper playtest will share stories of playtesters frustrating for minutes over some small flaw, only to suggest “yeah, it was fine”. Every task and process is designed to value contextualised behaviour and structured interview data over players raw opinion.

What happens if we don’t bother with UX feedback?

Without actively steering a studio toward this kind of knowledge-seeking and feedback-gathering culture, teams aren’t empowered to seek it themselves. Without a leadership voice calling for these check-ins, they’re eschewed in favour of just getting on with it. This is understandable: the prospect of re-doing hard work, or teams learning that their best work isn’t being experienced-as-intended, isn’t pleasant.

But blindly moving forward is false progress. By not addressing the player-centric challenges, they’re tainting the work being produced. At best this means re-doing hard work, at worst teams iterate themselves into bankruptcy, or release to lukewarm reception. Better to invest in getting it right early; better to redo days of work than months or years of work.

Teams feeling they’re “not ready yet” or “in too much flux” are suffering the very uncertainty that UX processes are designed to overcome.

Finding examples to highlight how the development challenges listed above lead to failure isn’t difficult. Games with ‘poor UX’ are every game you’ve never heard of, every game that never passed into the zeitgeist. Failed games and failed development studios don’t blame ‘poor UX’ for bad reviews, layoffs or bankruptcy; gamedev has its own well-developed lexicon for poor experiences: inaccessible, cluttered, clunky, too easy, unbalanced, shallow, clone, money-grubbing, greedy, deceptive, unoriginal…  All are interpretations of unrealised intent – of poor UX. I’m sure you’ve played your own fair share of ‘bad games’, perhaps even sensing that they’re a diamond in the rough. “If only they’d changed X”. It can seem so obvious in hindsight.

Successful products have releases with now-infamous usability or learnability issues in one form or another too: the widely-bemoaned Pip-Boy and settlement UI in Fallout 4, and the UI overhauls undergone by Gran Turismo 5 were both the result of failure to address ease-of-use issues. Luckily neither were core to gameplay. Pokemon Go suffered severe learnability issues at launch, leading to a raft of ‘how to play’ articles, but ultimately delivered experientially, through novelty and brand. No Man’s Sky failed to capture the experience players anticipated, despite generally good usability and learnability. Sometimes marketing dollars or branding can overcome UX frustrations, but not always, as Mario Run’s “disappointing” commercial performance attests.

The challenges listed the start of this article don’t always manifest as a single UX issue clanger, but find any poor game review on Metacritic or app stores and there will be criticisms that fall under UX’s remit: difficulty-in-use, low understandability or inconsiderate design. These topics do matter to players, and so they should matter to you.

Whom should we make responsible for ‘good UX’?

The short answer is: everyone. Every individual contributor to a project leaves some mark on the experience of the player, be that aurally, visually, mechanically or otherwise. All Developers are creators, and all are responsible for the impact of their work on the players’ experience.

Some parts of UX can be adopted without hiring UX staff, such as running playtests, surveys and collecting analytics data. But there is no substitute for expertise in research, psychology and interaction design, bringing those decades of human/machine study. Player data is hugely powerful in altering the course of a project, so ensuring you’re investing in capable staff avoids inexpertly-gathered data, biased analysis, unscientific research. Each can do more harm than good.

Understanding your studio-specific challenges and competencies is a great place to begin. Some UX might already be part of your processes: playtesting, analytics, maybe some existing-player surveys or formalised competitor analysis. How could they have been employed earlier, and more predictively? Is the staffer getting the academic and moral support they need? Gamedev post-mortem articles very often cite regret for not beginning with player-centric tasks earlier and more actively.

Perhaps rally the team and discuss your experiential risks in the project; does the team recognise any of the challenges listed above impacting their work? How does the team currently combat each of the challenges listed at the start of this article?

it never feels like the right time to ‘test’ the game, until it is too late…

The principle that “good design starts from day one” always hold true. Don’t fall into the trap of ‘checking it tomorrow’, because it never feels like the right time. Investing in UX ‘pays out’ in time saved or reallocated later in the project. Delays only serve to devalue UX’s potential contribution. One cannot reclaim development time already spent.

Try parsing your studio’s previous journalistic reviews and storefront comments; could their criticisms be rooted in not understanding the game, or the impact of tutorials? Do comments reveal players having unintended ease-of-use frustrations, or issues with feedback, balance or navigation? Do analytics reveal metrics below our projections for retention or other player behaviour? If so, you’ve evidence for the return-on-investment for investment in player science on your next project.

Time is the biggest challenge, pacing earlier stages of development to greatly speed up the later stages. Setting aside monthly budget and time for playtesting and research is a challenge for teams who’ve never experienced player-centric development. Know that these roles specifically exist and continues to thrive in all creative domains because their processes pay out in quality and time over the lifetime of production.

Player-centric processes are more than hiring new people and setting aside budget; the company culture may need to change also. Hiring UX staff isn’t enough if the studio is unwilling to steer the company toward this empathetic design process, and empower those staff to instigate change.

There is much to learn from studios who’ve already embedded player science professionals. EA’s Veronica Zammitto shared years of experience at GDC in 2017; Ubisoft, Riot and Epic have all shared their experiences in transitioning to a player-centric culture and process. Celia Hodent’s just-published book considers the applicability of UX and neuroscience to game development. There is a wealth of information about specific UX methods, processes and case studies available, particularly via the IGDA GURSIG community, and the UX Summit. Let’s learn and share together, toward better experiences for our players.

In Summary

Games User Experience is a discipline of science and design for overcoming the difficulties in making games that deliver on their experiential intent. It uses formalised processes and job roles to discover flaws in a game’s design and its means of communicating itself to the player. UX leverages a body of academic knowledge on designing for humans than spans decades of study, across many domains.

Without UX approaches, games fall victim to difficulties that are inherent to creativity, including a lack of objectivity, and challenges in teaching and accommodating players that are dissimilar to ourselves. These factors ultimately affect the perceived quality of the game, critical reception and enjoyment.

When game teams embrace the 4 key roles (Design, Research, Data Science and Leadership), a more empathetic and confident studio culture can form around the core development loop (design, implement, measure, assess), which leads to better games, happier staff and a more productive studio.

Applying these practices to game development delivers successful games, faster, cheaper and closer to the design team’s creative vision. The combined power and efficacy of these player sciences will ensure their continued path to toward becoming a core game development discipline. (Source:gamasutra.com