之前老是覺得自己家遊戲的使用者操作\介面怎麼做都做不好,更奇怪的是好像沒人完全專注地在做這塊,提出相關問題時候都會被以「實作很困難」,「需要動到底層」,「時間來不及」等理由被否決掉。當然我不是程式人員,所以碰到這樣的回答實在莫可奈何,直到那個我在意很久的攝影機鏡頭在一次會議中提出後,不到半天就修好以後,讓我很認真地思考:

 

 1.原本提的人人微言輕(me)

 2.以前根本沒人在意這塊,直到CCB

 3.以前根本沒人覺得那是問題(WTF)

 4.修起來很麻煩的東西其實只是沒人想做

 5.以為很麻煩的東西其實不麻煩,只是工作外的項目不想做

 6.其他亂七八糟的理由

 

 大概從FDO後期到TDO以及目前的Pili OL,我一直都有在接觸UI這一塊,記得TDO那段時間,曾有個朋友問我,TDO介面怎能做到這麼差,明明FDO時候做的還不錯呀,我很無奈地回答他:

 「FDO的介面是美術做的,FDO陸版介面是程式做的,但是TDO介面是企劃做的...」

 那位朋友當然以無言回我。

 

 美術做的介面,不管好不好用,起碼很好看。

 程式做的介面,不管好不好看,起碼還能用。

 企劃做的介面,我只能說是慘不忍睹。不好看也不好用,更糟的是,就算你覺得他不好看又不好用,還一點辦法都沒有。

 

而且責權歸屬十分之混亂,舉例來說有一次,我在製作介面覺得某個地方不太好,找程式商量修改,程式要我找原設計的企劃,當我去找原設計者後,要馬是原企劃不要改,不然就是討論期間過久,結果程式先把系統寫完了只好硬著頭皮上。又有些時候,介面上的修改會動搖到整個系統,所以最後也置之不理,就這樣許許多多不方便的地方,就這樣被偷偷藏在各處,只能祈禱沒人發現那些問題。

 

再來說說美觀的部分,因為介面的構成是企劃主導的,美術只是從旁協助,提供各種元件圖案,在美術無法見到全貌的情況下(還要趕工),最後一些零零落落的元件湊到一起,自然也不會好看到哪去。

當然,把UI專責的企劃美術跟程式組成一個獨立部門,這是比較理想的方式,可以解決大多數的問題,但也會衍生更多問題,而且這篇並不是主要在說UI,而是範圍更大的「使用者體驗」。

 

前半部分我想說明的是「為什麼使用者體驗老是做不好」,我們遊戲裡面每一個環節都由不同的企劃去規劃,再由不同的程式將這些規劃實作出來。大多數的企劃沒有思考過所謂UI設計,大多數的程式只會照著文案把企劃的要求做出來。在核心處就已經如此混亂,就算有專責的UI部門,能夠解決這問題的能力也非常有限,除非UI人員有權限能介入系統設計,但就效率來看,這種可能性是非常低的。

 

直到看了這篇之後:

http://www.slideshare.net/ngocdaothanh/ss-9763695

 

雖然他對使用者體驗的部分描述不多,但卻說了一句非常重要的話:

在專案的設計初期,使用者描述越詳細越好,系統的規劃越精簡越好。因為使用者描述容易被遺漏,而系統設計會自然膨脹。」

 

甚麼叫做使用者描述呢,簡單說就是以「玩家」的角度來敘說「要怎樣的遊戲」,舉例來說:

 1.我要角色可以翻滾

 2.我要角色可以往前衝刺

 3.我要遊戲場景有日夜變化

 4.我要鎧甲可以變身

 5.我要角色可以把敵人踢下斷崖

 6.我要角色走進水中會出現水波紋

 7.我要有流暢的跳躍動作

 ...ETC...盡可能越多越好

 

收集全部團隊成員的使用者描述後,從中去蕪存菁,選出出現率最高的,剔除完全不能用的,排出優先度順序,將他整理成工作項目清單,再由企劃寫成詳細文案交付實作。

 

又為什麼要由出現率來決定重要順序呢?

因為使用者體驗需要的是「最大多數」認同的,不應該由一兩個企劃來決定應該怎樣才對。

 

 

在大公司待得越久,越覺得英雄主義是不切實際的,個人能力再怎麼強,能有的影響都非常有限,只能認同全部人是一個團隊,並好好利用團隊的優勢來製作遊戲。

文章標籤
創作者介紹

風停的時刻

wandererc 發表在 痞客邦 PIXNET 留言(0) 人氣()