一份靠譜的設計文檔能讓游戲開發少走彎路

凡事預則立不預則廢，在做任何事之前，先進行思考和規劃，拿出一份靠譜計劃方案可以讓接下來的工作變得順利且有銷量。對于游戲開發來說，一份靠譜的設計文檔就能讓游戲開發少走彎路，讓游戲開發變得更有效率，更能接近設計目標。

無論是個人項目還是團隊項目，都遵循了共同的開發流程，即設計-實現-測試-交付。各種成功或失敗實踐的經歷告訴我們，在項目開發的早期階段，一份靠譜的設計是多么重要，可以讓團隊達成共識，目標明確，少走彎路，避免各種挖坑填坑的無效浪費。

項目開發中的各種槽點

設計文檔的作用

可以幫助設計師始終聚焦在產品的核心價值上。

可以幫助設計師更好地組織和推銷自己的想法。

可以幫助設計師完善開發計劃和風險管理。

設計文檔幫助設計師始終關注產品的核心價值

產品是能滿足購買者需求的有形或無形的物品、服務、概念等。在做設計時，設計師需要關注用戶的核心需求，市場競爭策略，以及技術實現路徑。設計文檔就是圍繞用戶需求及問題域提出的解決方案、設計意圖和實現路徑的早期直觀體現。圍繞用戶需求和產品競爭策略來開展設計，設計的價值最終要體現在產品的價值上。(用戶不買單，老板哪來錢給你發工資?設計不結合賣點，產品敗了，設計師哪來的甩鍋底氣?閉門造車、自娛自樂的可以拉出去了。)

不要悶頭做設計

把握用戶需求不僅是滿足需求，更牛的可以創造需求。用戶的類型和喜好是多元的(看官請自行搜索《用戶類型與游戲設計定向之間的相互影響分析》)，人在不同階段的需求也是不同的(參考馬斯洛需求層次理論)。事實上很多用戶自己都不清楚自己的需求，通常是看順眼了就買單(和逛超市很像)，從游戲設計和游戲營運角度深度挖掘用戶需求是一門很深的學問，不再做探討(這個領域騰訊是挖坑專家，不得不服，褒義)。

競爭策略是怎么搞定對手占據市場。玩家的時間和金錢是有限的，而游戲產品可以是無限的。每年新出幾千款游戲，能被玩家知道的、能賣座的就那么幾款。競爭策略可以是多樣的，比如跟風：走別人的路讓別人無路可走(騰訊是這個領域專家，不得不服，褒義，騰訊游戲的成功就是比別人做得再好一點點+強大的營銷渠道+龐大的用戶基數。)，其他策略有產品差異化、細分領域、采用新技術(VR，AR)等。概括起來就是做到人無我有，人有我優，人優我變，牢牢把握市場。

公司戰略就是根據我有啥(資源、技術、合作伙伴等)、我能做啥(成功項目案例)，我的危機是啥(競爭弱勢，市場變化等)，提出我要做啥(更高目標，如賺錢、強化品牌、積累用戶、業務轉型等)。概括起來就是揚長避短，擴大優勢。

設計文檔幫助設計師更好地組織和推銷自己的想法

好的文檔應具有可讀性，魚的記憶只有7秒，我的記憶在一篇如同天書的設計文檔面前只有0秒。在團隊項目中常常聽到有的設計師對開發人員說：你怎么不看文檔?里面都寫的清清楚楚，怎么不照著開發?沒人愿意花幾個小時看上幾百頁的厚重文檔(這種文檔設計師留著自己看吧)。

為了讀者著想，設計文檔也要注意排版和包裝，當成平面廣告來做也不過分(自己把控時間)。推銷類的文檔力求抓住眼球，留下深刻印象;技術類的文檔力求簡潔明了，邏輯清晰。

一些技巧：

根據文檔的閱讀對象(客戶、自己、團隊、特定職能)，看人說話，可以用腦圖，原畫參考圖，流程圖，列表啥的代替長篇文字。

采用條理清晰的寫作格式，如三段論，總分總，中心+論據等。

選擇合適的工具(PPT，word，PS，Visio，Excel等)，不同的軟件有不同的優勢。

設計文檔中著重傳達設計意圖和預估風險(面向團隊)，鏈接分類的更加詳細的開發單元的設計文檔(面向實際開發人員)。

曾經做的某開放世界游戲的襲擊運輸車隊的關卡設計文檔

設計文檔幫助設計師完善開發計劃和風險管理

線性的瀑布模式在產品設計開發中已經是一種很落后的開發模式了，首先外部環境(用戶需求，市場變化等)是不斷變化的，信息時代下新技術、新產品層出不窮，用戶需求也呈多樣化且易受到引導;其次，設計師對外部市場環境和產品規劃的認知，同時開發團隊的技術實現能力也需要一些學習和積累的過程。變化和不確定的因素就決定了產品開發不可能等設計面面俱到后再進入實際開發，因為這一步是遙遙無期的。設計師需要根據產品的愿景來設定開發單元的價值優先級，根據任務的輕重緩急來安排工作計劃，常用的有滾動計劃法和迭代增量開發模式(RUP，敏捷等)。

迭代增量的開發模式

在很多游戲產品開發項目中，設計師同時兼顧了協同開發團隊實現(類似于裝修設計師+現場施工經理的結合)，掌握一些基本的項目管理技巧(至少是風險管理、成本管理)可以大大提升設計實現的效率和效果。現實中多的是腦洞大開如空中閣樓的無視技術限制的設計，也有做產品做到公司破產的案例(替老板心痛一秒，不能再多!)。有的設計師滿是天馬行空的點子，卻不做系統性的文檔，在實際開發中想一出是一出，各種臨時決定的需求變更，等開發到過半測試驗收的時候才發現各種功能不協調、漏洞百出，唯有返工重新設計，導致了巨大開發進度危機。這類風險完全可以在前期設計時采用腦圖，方案分析，紙面模擬等方式排除。

寫在最后

設計方案的風險分析在大型開發項目中是必需的，設計師可以不懂技術，但必須標明方案中牽扯到的開發單元，以便于團隊有效把控技術風險和進度風險，同時能有多套應對實現變更的備用方案。

設計師也需要站在對立面來審視設計文檔，同時勇于接受他人反饋和挑戰，找到文檔的不足并不斷完善(圖文表達、玩法設計、實現風險評估)，文檔階段的破壞性風暴是試錯成本最小的(紙面游戲，玩法推理等)，不要等到開發階段投入了大量的時間和資源后才發現設計中的大量缺陷和不對路。

在開發進程中保持文檔的更新，最好能形成系列的工作日志(如用戶反饋，設計變更的原因，選擇方案理由，方案實施效果等)，作為知識積累(個人總結或傳給后來人)。

在大型項目中，很多設計由多人協同開發，模塊化設計集成，迭代增量的設計模式將是主流。開放設計是大趨勢啊，游戲從傳統的線性戰役模式轉到了當下的開放世界沙盒模式，項目管理也從線性的瀑布模式進化到了迭代增量開發模式，作為游戲開發項目的設計師，不與時俱進就要被淘汰了哇。(confluence這類知識分享聚合軟件是構架開放工作環境的不錯選擇。)