文/小黑

今天主要講講遊戲交互設計師在項目中的主要職責。

先大概瞭解一下游戲項目流程中的角色關係和產出：

下面進入主題：

一、理論篇

遊戲交互設計師（UI）在項目中主要做什麼？

1.策劃需求審稿員

UI最開始會拿到遊戲策劃的需求文檔，需求文檔中主要會描述完整的功能需求。

很多小夥伴拿到文檔就開始做原型了。但是，等等，建議大家拿到需求文檔後，先好好“審稿”，主要查看3點：

第一，功能是否必要；

有一些策劃會抱著“功能做大做全總是沒錯的”的想法來寫需求，導致功能龐大繁雜，主次不清。這個時候，UI擔任了平衡輕重的角色——

• 從階段性開發、功能必要性的角度，和策劃討論刪減功能，或者延後開發；
• 從玩家需求的角度，挑出重要功能著重處理，刪減非必要需求。

所以看到功能繁雜、重點不清的時候，就要舉起你的奧卡姆剃刀來。

第二，功能設計是否合理；

策劃不可能總是不出錯，有時候他們忘了從玩家身份考慮，可能提出一些不合理的功能，就需要UI來把關。

這需要經驗積累，才能及時對不合理功能做出反應。

第三，根據需求，設計更好的方案；

UI的重要貢獻在於“為遊戲提供更好的體驗”，所以有時駁回策劃需求後，需要從玩家的角度出發，給策劃提供一個更合理的解決方案。

認真過審文檔，一方面在需求階段就優化項目，另一方面提高自己在項目中的話語權，而不僅是作為一個“策劃輔助”的身份。

2.原型、流程圖產出者

這應該是大家聽的最多的一個職能了。

我們用Axure來寫交互文檔，一般不做流程圖，都是通過圖文流進行表述（根據每個項目協作方式的不同，寫文檔的要求會不一樣）。

以主頁面或功能流程為一個講述點，會有當前頁面/流程的全局講述、頁面佈局說明、功能點說明（包含不同狀態）、跳轉說明，複雜些的邏輯也會寫邏輯圖。

這個是基本職能，很多文章也都有說明，就不講太細了，大家跟著項目的UI師傅學一學就清楚。

3.交互規範制定

很多小團隊不重視規範的制定（視覺規範、交互規範、開發規範），覺得寫規範很浪費時間，執行規範太過死板。

但上一個項目的後果告訴我，一個規範可能決定了項目的成敗——

我進入團隊的時候，項目已經進行了2年多，中間人員變動頻繁，功能更改也很多，因為缺乏規範文檔，導致了後來的成員難以維護以前的內容、新內容與舊內容衝突或者不一致、組件複用率低導致迭代困難。

雖然當時我根據項目存在的問題，編制了一份遊戲交互文檔，但是因為許多問題存在於底層代碼，要解決規範問題約等於推翻重做，基本不太可能了。於是默默留下文檔，離開了項目，來到了一個重視規範的團隊。

上一家公司的項目到現在已經有4年，投入成本幾千萬，但基本是廢了。

在網易的一位同事跟我說，網易做項目都會有一份成熟的規範文檔，項目中所有人共同維護和執行，保證人員更替、內容迭代、增加內容的情況下，項目都能有序進行。

因為制定交互規範非常重要，所以我決定單獨寫一篇文章來詳細說明。

4.對接視覺設計師

設計頁面“故事”

“一個好的遊戲界面設計，會讓玩家感受到‘故事’。”——這是視覺設計師告訴我的。

產品交互設計師可能比較少接觸到這個工作內容，但遊戲設計更像設計“一個世界”，界面就是構成這個“世界”的載體，所以遊戲頁面除了承載功能，還承載了組成世界的“故事”。這也是為什麼遊戲界面設計更注重“場景化”。

所以項目主界面設計的最開始，需要視覺設計師、交互設計師、策劃等，一起來構思怎麼講好這個遊戲的“故事”。

《陰陽師》的界面就很好地傳達了它想講的“故事”，讓玩家覺得進入了一個完整的“世界”中。

《陰陽師》主界面

《陰陽師》神龕

《陰陽師》百鬼夜行

轉化交互文檔為視覺需求文檔

視覺設計師一般工作量都很大，沒有時間細看交互設計文檔，所以需要交互設計師將交互文檔轉化為“GUI設計需求表”，將每一個需要視覺設計的內容整理成表格，註明大小規範、數量、需求等，供視覺設計師快速產出。

視覺創意方案

是的，交互設計師除了有嚴謹的邏輯，還需要有足夠的創意。

在我們的項目裡，很多小內容需要創意化設計時，都需要交互設計師先提出方案，再由視覺設計師進行細化。

所以隨時準備打開你的腦洞！

5.對接程序

功能邏輯對接

交互設計文檔會直接對接給下游的開發部門，需要交互設計師和開發部門講解功能的交互流程，詳細說明功能的每一個支線和所有存在的狀態。

交互設計師在審核和對接需求文檔時，已經對功能邏輯比較清晰，所以有一些前期開發要注意的問題，也需要及時知會開發部門。

在整理交互文檔的時候，發現需要配置為複用的控件，也需要及時整理進交互設計規範，告知視覺設計師和開發部門，能大大提升開發效率，降低後期迭代成本。

界面拼接

大家應該都發現了，開發部門拼界面基本很難講位置拼準確，所以在網易遊戲的項目裡，在開發工具裡（cocos、unity、U3D等）拼界面的事情是由交互設計師（有時是視覺設計師）做的。因此交互設計師也需要具備開發工具基本功能常識。

功能測試

開發完成後，需要交互設計師對功能進行測試和反饋，保證開發結果。

6.項目迭代

一個項目是需要進行反覆的迭代的。

在功能迭代層面上，除了策劃提出的新增需求，交互設計師需要不斷體驗遊戲，對其中不夠合理的內容提出迭代需求。

迭代的時候，並不是以“這裡不好看/不好用”的目的來迭代，這樣子容易造成視野陷入細節中出不來，甚至偏離了迭代目標。

好的迭代是提出“想達到什麼目的”，根據目標對一整個功能進行優化。

迭代方案出來後，再讓用戶體驗的同學幫忙對新方案進行測試和評估。

7.其他

交互設計和用戶體驗

有同學問到用戶研究的問題，在網易的項目裡，用戶研究和交互設計是分開的兩個職位。

交互設計師主要在項目中做上述事情，用戶研究員則負責將階段性開發出來的內容進行玩家調研，獲取項目迭代方向的反饋；以及遇到一些設計中有爭議的問題時，請用戶研究員確定更合理的方案。

UX部門工作安排

交互設計的組長還要負責安排UX部門工作進程，大概是因為交互在UX組裡屬於邏輯思維能力最好的，所以這種計劃性工作一般交給交互來處理吧。

結合上面的工作職責，幫大家梳理一下做一個遊戲交互設計師有什麼能力需求。

交互設計師能力需求

1.邏輯思維一定要好：因為交互設計師需要審核功能，特別在有些策劃自身能力不足時，交互就是策劃的守門員，需要經常和策劃討論（爭辯）內容的需求、合理性等；

2.多線程工作能力：因為交互設計師同時跟進的內容很多，思維需要能夠快速在各個內容間跳轉；

3.口才要好：UX部門的傳話員，項目中的溝通者，溝通是經常的，一定要善於表達自己的想法；

4.整體思維要好：交互需要跟不同策劃、程序、設計打交道，心裡要明晰這些東西哪裡有，樣式如何，功能點的重複性，在其他地方是否出現過等；在整理交互規範時也很重要，不要就會一團亂麻；

5.創意性：很多地方需要交互進行創意提案；

6.審美：拼高保真原型、拼cocos、unity，需要交互設計師有足夠的審美，最好是像素眼（不要就需要對著GUI的尺寸一一確認，費事又費時）；

7.用戶心理學：在和策劃遇到功能設計討論時，我們常常代表玩家一方，和策劃代表的項目放進行討論，最後平衡出一個結果，需要交互設計師去發現不符合玩家習慣的點，據理力爭（還有UE可以背書）；

8.敏銳的操作感受性：交互設計師需要反覆體驗遊戲（還有GAC職位是專門做這種事的），要有敏銳的操作感受性，不停思考發現遊戲中可以優化迭代的問題。

項目中的注意點

0.最重要的一點！儘量避免在未成熟考慮時有就做了決定，再去找理由驗證這個想法；

1.在拿到策劃需求時，認真過稿，以及在在交互環節多花時間確認，多找幾個交互過需求稿，降低到GUI環節的改稿成本；

2.前期多花點時間制定規範，跟程序和視覺確認什麼可以複用，用在哪裡，降低之後的開發成本；

3.做新功能時，交互確認什麼可以用在通用組件裡，提前和程序說明；

4.策劃修改或增加功能時，務必和交互先過，在交互規範框架下適配或按新需求的普遍性擴展交互規範；因為看似小的改動，其實可能牽涉很多內容，或者沒想清楚，導致反覆修改

5.什麼標準的內容為通用，什麼情況下可以特殊設計，應該前期制定標準，避免策劃將很多功能特殊化處理；

6.交互內部的內容溝通，儘量讓交互都知道整個遊戲的大致內容，避免在做相似功能的時候出現差異；

7.前期頁面就應該劃定好區域功能放置（右上角操作按鈕合集，左上角信息合集（不可操作）等）；

8.策劃變更需求時，整理變更原因，之後的需求儘量多考慮這些情況，避免多次變更需求；

二、實戰篇

為幫助大家更好理解，歸納了一些實戰例子。

1.策劃需求審稿員

1-1 審核功能必要性

【策劃需求】

比賽戰績的數據展示頁面，策劃要求擺放以下信息：

【策劃需求分析】

“7±2 法則”告訴我們，展示這麼多信息，不利於玩家閱讀和記憶，所以需要對信息進行必要性分析。

在分析過程中，一方面考慮策劃的訴求：

1.策劃希望傳遞給玩家的信息，和信息背後的價值；

通過對信息的歸類，可以發現策劃主要想傳遞3類信息：“排名信息”、“比賽信息”和“獲獎信息”——每類信息後都帶有設置它的目的。

“排名信息”：希望給玩家帶來名譽的自豪感，以爭取更高名次刺激玩家參賽；

“比賽信息”：比賽歷史數據積累，幫助玩家瞭解自己的比賽情況，增強玩家對比賽的粘性；

“獲獎信息”：告訴玩家在比賽中的累積獲益，提高玩家的比賽積極性。

【使用情景分析】

另一方面結合策劃訴求，考慮玩家的真實使用情景：

2.信息是否能傳達出策劃的訴求；

3.玩家本身關注的的核心信息是哪些。

以這兩個目的出發審視信息，對難以傳達出訴求的信息、重複信息、對玩家而言沒什麼的價值的信息進行了刪減，突出重要信息，重新規整了信息佈局：

1-2 審核功能合理性

【策劃需求】

策劃希望增加一個和“快速遊戲”類似的“快速比賽”的按鈕，點擊後玩家就能加入一場即將開始的比賽。

【使用情景分析】

在考慮功能合理性時，我們會把功能帶入到真實的使用場景去想象：

1.玩家使用功能前的需求；

[使用前——玩家無法預期比賽類型，存在報名費扣費顧慮]1.比賽場內包含了所有賽事類型、子游戲類型、不同獎勵比賽類型：4x4x5，近百種類型的隨機，讓快速比賽結果完全不可預期2.玩家不知道系統快速匹配比賽的邏輯，對有足夠遊戲幣的玩家而言，他們會擔心繫統是否會自動扣費報名比賽，這種疑慮也讓他們不會點擊

2.使用過程中的具體行為和感受；

[使用中——不合適匹配概率高，不合適匹配導致的成本高]1.因為匹配結果的不可預期，很容易隨機到玩家不擅長／不熟悉的比賽類型2.合作性比賽，若玩家因不熟悉玩法託管／退賽，導致合作玩家的體驗大打折扣3.比賽時間長場次多，一次進入也將花費更多時間成本

3.使用功能後的體驗。

[使用後——滿足不了玩家需求，甚至有負面體驗，導致玩家流失]1.玩家點擊“快速比賽”說明有比賽意願，他們本來會花點時間去看看比賽列表，找到合適自己的賽事，認真參與；快速比賽的不好體驗，可能導致玩家流失

1-3 分析策劃需求，設計更好的方案；

【策劃需求分析】

駁回了上面策劃提出的“快速比賽”功能後，要去分析策劃提出這個需求的原因是什麼：

1.便捷引導：玩家進入比賽模式後，不知道點什麼；

2.新玩家留存：新玩家需要篩選不同比賽，增加了門檻；

3.快速體驗：快速比賽會分配免費、時間近的比賽，可以快速開始比賽體驗。

【方案設計】

針對策劃的訴求點，分析不同玩家的心態，來進行新方案設計：

1.便捷引導：玩家進入比賽模式後，不知道點什麼；

2.新玩家留存：新玩家需要篩選不同比賽，增加了門檻；

1.明確免費賽和需報名費賽的視覺差異，方便玩家快速選擇；2.增加不同遊戲類型的篩選功能，幫助玩家快速定位遊戲。

3.快速體驗：快速比賽會分配免費、時間近的比賽，可以快速開始比賽體驗。

1.將即將開賽的比賽置頂；2.通過玩家平時玩的遊戲/比賽類型，智能推薦相應的比賽。

2.對接視覺設計師

2-1 設計“故事”

【需求】

設計比賽開賽等待計時器

【分析】

交互設計師產生的創意，最大一個特點是可以結合玩家心理進行設計。

賽前等待是一段比較乾枯無聊的時間，所以我從玩家“無聊”的心情入手，將他們的心情擬人化為熊貓，通過熊貓和時鐘的互動，幫玩家傳遞出他們的情緒：

【需求】

設計進入比賽時的加載動畫

【分析】

相比於開賽等待的時間，進入遊戲的時間是令玩家充滿期待的，而且我們這個遊戲希望傳遞出的是“可以和好友一起玩”的感覺。

所以在設計加載動畫時，讓其他3只熊貓處於等待玩家一起遊戲的狀態，既契合了遊戲的理念，又讓玩家覺得“有人在等自己”的親切。

2-2 視覺創意方案

【策劃需求】

重新設計設置頁面 switch 按鈕，使之生動有趣。

【創意方案】

我考慮創意方案一般會從幾個點進行發散：

1.和遊戲核心元素相關；

2.和遊戲內形象相關；

3.和遊戲視覺元素相關。

能想出什麼來就基本靠腦洞了。

3.項目迭代

一個項目需要反覆進行迭代。

迭代的時候，並不是以“這裡不好看/不好用”的目的來迭代，這樣子容易造成視野陷入細節中出不來，甚至偏離目標。

好的迭代是提出“想達到什麼目的”，根據目標對功能整體進行優化。

3-1 操作界面迭代

【發現需求】

在使用的時候最明顯的感覺是“不順手”、“找不到按鈕”，這說明現在的按鈕佈局存在問題。

為了確認是否是個普遍問題，還需要問問其他人是否遇到一樣的問題，再跟用戶研究員進行討論，瞭解玩家的使用情況——從用戶研究員的調查中發現，部分玩家玩這個遊戲的時候，經常採用“一手拿煙，一手操作”的姿勢——說明需要考慮適配單手操作的情況。

瞭解了上面的信息之後，決定對這個操作界面進行迭代。

【提出迭代目標】

針對遇到的問題，提出了這些迭代目標。

1.高頻按鈕易感知和操作；

2.低頻按鈕不易忽略；

3.按鈕的出現更貼合玩家當下需求；

4.嘗試適配單手操作需求；

5.加強輪到自己時的提醒；

【分析】

1.首先根據迭代目標的內容，提取出按鈕的幾個性質：按鈕出現的時間、操作頻率、能否支持單手操作。

從這幾個方面對按鈕進行了整理：

2.再對界面的操作熱區和視覺熱區進行標註，方便定位界面上最重要的區域來佈局按鈕：

操作熱區

右下角，拇指直徑的扇形區域

左下角，拇指直徑的扇形區域

視覺熱區

自己控制的角色與所在的場景區域為視覺熱區

【迭代方案提出】

最後定下迭代方向：

1.按鈕分佈於兩側（操作熱區+視覺熱區）；

2.按使用頻率和分類排布按鈕；

按這些迭代方向，給出了單手和雙手操作兩套迭代方案：

[單手操作界面]

[右手為主，左手輔助界面]

【方案權衡】

迭代方案出來後，再讓用戶體驗的同學幫忙對新方案進行測試和評估。

因考慮到大部分玩家不會在橫屏時單手持機，所有按鈕都放一邊存在比較高的誤觸風險，而誤觸的代價也比較高；

以及因為遊戲已經上線，這一次迭代儘量不要跟之前的佈局有太大差異，而導致玩家出現不適應情況。

最後選擇了較為保守的雙手操作佈局。