手遊UIUX設計經驗分享①流程篇
嗨，大家好我是小黑 ☕️
我將分享我在某日本遊戲公司的工作經驗。這篇先以「手遊的UI UX製作的流程」來稍微做說明。製作新的遊戲的流程會跟遊戲更新的流程不太一樣。這篇是說明為了更新遊戲內容的UI UX工作流程。
以我擔任的案子為例，更新遊戲內容的UI UX工作流程大致如下。
①定義課題與目的
②企劃書的製作
③討論企劃內容讓企劃書更完備
④主要畫面及流程圖的草圖製作
⑤與企劃和開發組討論草圖
⑥正式製作
⑦組裝的確認
⑧由QA組進行功能上的確認
⑨正式上線
接下來說明各個流程的詳細。
①定義課題與目的
首先 案子的管理者會根據KPI等數據以及公司的事業規劃去訂一些需要增加或修改的功能還有擬出概要。(我們做的這個手遊算一個案子。這案子的producer,project manager,director是管理者)
所謂的課題與目的舉例來說：假設管理者根據事業規劃必須要讓我們遊戲的DAU(daily active users)和獲益增加，所以他們決定導入一個新機能「排位賽」。
這意味著目的是讓DAU和獲益增加，課題是要讓排位賽好玩。往後的製作將繞著這兩點打轉。
為了達到DAU與獲益的增加，管理者會先提出他們期望的表現方式。例如他們想要固定期間就更新一次，每次更新的內容稍為不同像是有單人模式以及多人模式等，好讓玩家一個拉一個進來玩，並且達到特定排名的時候可以拿到不錯的專用道具，這個專用道具會對排位賽更加有利等等。
當他們大略構想了這個排位賽之後，接下來就是要由企劃設計以及開發組來完成這個使命。
我擔任的案子設計師並不會參與這個階段的初期討論和決定。但往後詳細內容的討論中，如果對課題與目標或是表現方式有疑慮，會報告給管理者然後一起討論這目的或課題是不是足夠精確。②企劃書的製作
概要會先傳到遊戲企劃的手上，由他們去寫出功能的詳細企劃書(中文好像叫做規格表？日文叫做仕様書)。這一步他們需要跟案件的管理者頻繁溝通，來勾勒出詳細的企劃內容。
繼續以排位賽的例子來說，企劃會思考更新的頻率要每週還是每兩週，兩者對於獲益方面有什麼不同，進而會去聯想每次的更新內容例如要有boss還是就PvP，玩家拉別的玩家進來要用什麼機制比較有效果的達到DAU的增加。
這個階段的企劃也會 稍微勾勒出簡略的遊戲畫面，但沒有很詳細的考慮ＵＩ ＵＸ。
大概就像是，他們覺得在既有的畫面的右下角應該可以塞下一個去排位賽的按鈕，但是不是一定要塞在那裡，有沒有別的方式這部分就有很大的轉圜空間讓UI UX的設計師去思考。他們想表達的只是我們需要一個去排位賽的按鈕，所以隨便弄了個畫面好讓這個需求不會被遺忘。
③討論企劃內容讓企劃書更完備
這是實際開始動手做之前最費力也最耗時間，最重要的階段。
如果這一步沒有走得膽戰心驚，以後一定會修到眼冒金星 😇企劃寫好企劃書之後內容會傳到設計組以及開發組的組長手裡(就是跟我同等職位的人這邊)。各個設計組及開發組長會根據企劃內容去分析、討論說這能不能達到案件想解決的課題或目標。
如果不行，企劃會當場遭受各組組長鞭打。
喔不是 😆
我們會「冷靜的」在討論的場合提出意見去把整份企劃書導向更能夠讓玩家(以及公司上層)滿足的方向。
像是：這部分的內容是因為什麼原因而不能解決問題。這新功能真的好玩嗎？如果換成這個方式在使用者體驗上會更好（更好玩或更方便）。
這階段 UI UX設計師或設計管理者會根據企劃書內容跟企劃討論UX，並且一併考慮往後的更新內容，以達到比較容易玩的動線，還有對玩家相對較有魅力的介面表達方式。
設計組與開發組也會討論開發面要怎麼做出這個UI UX，可行性如何，有什麼限制需要注意，要花多少時間等等。企劃也會跟開發組討論一些內部數據怎麼定義和設定。
往後的更新內容有很大機率會影響到初期的UI UX，所以我們會追問像是
- 企劃書中寫了有單人模式跟雙人模式，兩者都是每兩週一次更新的頻率嗎？還是有時候更新只有單人模式？以便判斷什麼時候需要幾個入口。
- 每次排位賽有沒有角色屬性或裝備上的限制？這些限制有幾種不同的內容？假設最多五種，那有沒有辦法放到畫面裡，並且往後是否會增加遊戲規則？
假設畫面中已經沒有位子再放更多的內容，這階段就必須先協調好往後的更新內容。
以日文來說就是「釘をさす」，在企劃的腳上打釘子（誤）。
在這階段告知企劃這部分以後不能隨意更改或增加，如果需要改變就必須給設計師以及開發組相對的時間去重做這部分，而且需要的時間可能不是一天兩天。- 每次的更新需要圖像嗎？有boss的話可以根據boss來做圖像，可是兩週更新一次要做圖像的頻率相對較高，所需要的成本也大，有沒有需要投入這麼多人力成本在圖像上？
等等的問題。
設計組與開發組在這階段提出的問題與解決方式會由企劃再度傳遞到案子的管理者手上。讓管理者知道哪些地方與當初的計畫有變化，免得連工程師作業都結束之後才發現其實這不是管理者要的東西而導致重做。
④主要畫面及流程圖的草圖製作
整份企劃書內容大概定好了之後，UI UX設計師會用sketch或photoshop等軟體去做出粗略的各個主要畫面以及畫面流程圖。
這一個步驟重點在 網羅各個畫面裡面需要顯示出來的情報（例如：等級、玩家名、屬性等等）以便讓工程師不用等畫面完全做完就可以著手。
我們也會由畫面流程圖去想像玩家是否好操作。
設計師著手做wireframe的時候不一定會照著企劃書裡的內容做。像是他們在企劃書上隨便塞在遊戲畫面右下角的入口，我們只會抓他們想表達的訊息去用我們認為好的UI UX做詮釋。所以更多時候在想辦法做出更好操作、更容易懂、更有魅力的畫面和流程。
⑤與企劃和開發組討論草圖
設計師做好草圖後會與企劃和開發組討論，看這樣的畫面流程和介面有沒有達到解決課題或達到案件需要達到的目標。
各個主要畫面的詳細內容和情報也會在這個階段討論要不要增加或刪減。還有實際開發的時候工程師會遇到怎樣的困難，以及介面需不需要換個方式來表達等等。如果UI UX設計師的構想裡畫面中有需要加入音效或特效，也會在這個階段和特效組和音效組的設計師討論。
這個階段如果在設計師開發組以及企劃之間沒有辦法達到共識，
UI UX設計師會回到④的草圖流程去想辦法解決企劃和開發組的疑慮，
再回到⑤的流程討論草圖。
主要畫面的草圖和流程全部達到共識之後才會開始正式製作。⑥正式製作
正式製作的階段，設計師會負責把遊戲功能的整串流程和介面做完，開發組會一邊拿著草圖先做內部處理的部份。
設計師做完整串流程和介面以後，會交給企劃檢查，之後再往上交給案件管理者檢查（project manager,director）以確認有達到案子想做的內容及目標。畫面與流程都沒問題之後才會把正式版的wireframe等交給開發組工程師去組裝。
⑦組裝的確認
開發組組裝完後會由設計師確認工程師們組裝的介面和動作是否與wireframe和流程圖相同。
這一步流程每個公司每個組會不太一樣。
我們會由開發組的工程師組完介面之後，由設計師確認每個要素的大小，位置等等是否與wireframe相同，但有些組會直接由設計師進行介面組裝。
有一點像是假設是網頁製作會直接由設計師寫html/CSS還是交由工程師寫的概念。我擔任的組是後者。
目前遊戲開發多用Unity開發，所以設計師確認要素的時候也是用Unity檢查。設計師確認的內容以設計為主，機能方面像是有沒有bug並沒有確認太多，如果我們有要求組裝特效等也會確認特效的表現有沒有問題。
題外話
由設計師進行介面組裝會需要相當多的工程方面知識，也需要更多時間和工程師協調怎麼樣避開同時碰同一個畫面。介面的組裝不只是外表，也需要工程師把程式碼寫進去才有辦法好好運作。如果設計師在調整介面的時候，不小心把工程師為了寫程式碼而隨意放的一個素材調成隱形（類似photoshop的layer的眼睛符號關掉），都會導致bug的產生，進而工程師會需要更多時間去收拾設計師搞出來的殘局。而能夠精準抓住這些眉角的UI UX設計師並不多，也需要相當配合的工程師們一起合作，種種原因導致我擔任的案子沒有由設計師來進行介面的組裝。
⑧設計師確認完畢後由QA組進行功能上的確認
基本的功能和特殊情況的流程都會由設計師寫在流程圖裡，QA組就負責看一切有沒有照設計師擬定的計畫被組裝好以及有沒有bug。
特殊情況的流程像是跟隊友一起打boss但是自己斷線了，之後重啟app會直接回到打boss的畫面，或是打boss之前的準備裝備的畫面。斷線之後隊友把boss打爆的情況，重啟app 會不會出現一個視窗跟玩家說剛剛的boss戰成功或失敗了等等。
有時候QA組會發現一些特殊流程被遺漏而沒有被定義，這時候他們會把問題提交到設計組與開發組手上，由設計組與開發組去定義特殊情況的流程跟介面應該要是如何。
⑨一切通過QA組的測試之後就是申請然後正式上線囉！ 🎉
最後一個步驟應該不太需要做說明了。以上就是整個製作流程的介紹。
正式上線之後有很大的機率會根據玩家的意見來做調整，所以是一種永遠不會有做完的一天，每天都在修改以前做的東西的感覺。
以上不知道會不會太難閱讀或難懂呢？如果有其他想知道的內容也歡迎給我任何feedback。謝謝！
