Dec 24 Mon 2012
*專案名稱馬賽克處理
之前老是覺得自己家遊戲的使用者操作\介面怎麼做都做不好，更奇怪的是好像沒人完全專注地在做這塊，提出相關問題時候都會被以「實作很困難」，「需要動到底層」，「時間來不及」等理由被否決掉。當然我不是程式人員，所以碰到這樣的回答實在莫可奈何，直到那個我在意很久的攝影機鏡頭在一次會議中提出後，不到半天就修好，讓我很認真地思考：
1.原本提的人人微言輕（me）
2.以前根本沒人在意這塊，直到CCB
3.以前根本沒人覺得那是問題（WTF）
4.修起來很麻煩的東西其實只是沒人想做
5.以為很麻煩的東西其實不麻煩，只是工作外的項目不想做
6.其他亂七八糟的理由
大概從F後期到T以及目前的P專案，我一直都有在接觸UI這一塊，記得T那段時間，曾有個朋友問我，T介面怎能做到這麼差，明明F時候做的還不錯呀，我很無奈地回答他：
「F的介面是美術做的，F陸版介面是程式做的，但是T介面是企劃做的...」
那位朋友當然以無言回我。
美術做的介面，不管好不好用，起碼很好看。
程式做的介面，不管好不好看，起碼還能用。
企劃做的介面，我只能說是慘不忍睹。不好看也不好用，更糟的是，就算你覺得他不好看又不好用，還一點辦法都沒有。
而且責權歸屬十分之混亂，舉例來說有一次，我在製作介面覺得某個地方不太好，找程式商量修改，程式要我找原設計的企劃，當我去找原設計者後，要馬是原企劃不要改，不然就是討論期間過久，結果程式先把系統寫完了只好硬著頭皮上。又有些時候，介面上的修改會動搖到整個系統，所以最後也置之不理，就這樣許許多多不方便的地方，就這樣被偷偷藏在各處，只能祈禱沒人發現那些問題。
再來說說美觀的部分，因為介面的構成是企劃主導的，美術只是從旁協助，提供各種元件圖案，在美術無法見到全貌的情況下（還要趕工），最後一些零零落落的元件湊到一起，自然也不會好看到哪去。
當然，把UI專責的企劃美術跟程式組成一個獨立部門，這是比較理想的方式，可以解決大多數的問題，但也會衍生更多問題，而且這篇並不是主要在說UI，而是範圍更大的「使用者體驗」。
前半部分我想說明的是「為什麼使用者體驗老是做不好」，我們遊戲裡面每一個環節都由不同的企劃去規劃，再由不同的程式將這些規劃實作出來。大多數的企劃沒有思考過所謂UI設計，大多數的程式只會照著文案把企劃的要求做出來。在核心處就已經如此混亂，就算有專責的UI部門，能夠解決這問題的能力也非常有限，除非UI人員有權限能介入系統設計，但就效率來看，這種可能性是非常低的。
直到看了這篇之後：
雖然他對使用者體驗的部分描述不多，但卻說了一句非常重要的話：
「在專案的設計初期，使用者描述越詳細越好，系統的規劃越精簡越好。因為使用者描述容易被遺漏，而系統設計會自然膨脹。」
甚麼叫做使用者描述呢，簡單說就是以「玩家」的角度來敘說「要怎樣的遊戲」，舉例來說：
1.我要角色可以翻滾
2.我要角色可以往前衝刺
3.我要遊戲場景有日夜變化
4.我要鎧甲可以變身
5.我要角色可以把敵人踢下斷崖
6.我要角色走進水中會出現水波紋
7.我要有流暢的跳躍動作
...ETC...盡可能越多越好
收集全部團隊成員的使用者描述後，從中去蕪存菁，選出出現率最高的，剔除完全不能用的，排出優先度順序，將他整理成工作項目清單，再由企劃寫成詳細文案交付實作。
又為什麼要由出現率來決定重要順序呢？
因為使用者體驗需要的是「最大多數」認同的，不應該由一兩個企劃來決定應該怎樣才對。
在大公司待得越久，越覺得英雄主義是不切實際的，個人能力再怎麼強，能有的影響都非常有限，只能認同全部人是一個團隊，並好好利用團隊的優勢來製作遊戲。
