让开发少走弯路，从一份靠谱的设计文档开始！

无论是个人项目还是团队项目，都遵循了共同的开发流程，即设计-实现-测试-交付。各种成功或失败实践的经历告诉我们，在项目开发的早期阶段，一份靠谱的设计是多么重要，可以让团队达成共识，目标明确，少走弯路，避免各种挖坑填坑的无效浪费。

项目开发中的各种槽点

设计文档的作用

可以帮助设计师始终聚焦在产品的核心价值上。

可以帮助设计师更好地组织和推销自己的想法。

可以帮助设计师完善开发计划和风险管理。

设计文档帮助设计师始终关注产品的核心价值

产品是能满足购买者需求的有形或无形的物品、服务、概念等。在做设计时，设计师需要关注用户的核心需求，市场竞争策略，以及技术实现路径。设计文档就是围绕用户需求及问题域提出的解决方案、设计意图和实现路径的早期直观体现。围绕用户需求和产品竞争策略来开展设计，设计的价值最终要体现在产品的价值上。（用户不买单，老板哪来钱给你发工资？设计不结合卖点，产品败了，设计师哪来的甩锅底气？闭门造车、自娱自乐的可以拉出去了。）

不要闷头做设计

把握用户需求不仅是满足需求，更牛的可以创造需求。用户的类型和喜好是多元的（看官请自行搜索《用户类型与游戏设计定向之间的相互影响分析》），人在不同阶段的需求也是不同的（参考马斯洛需求层次理论）。事实上很多用户自己都不清楚自己的需求，通常是看顺眼了就买单（和逛超市很像），从游戏设计和游戏营运角度深度挖掘用户需求是一门很深的学问，不再做探讨（这个领域腾讯是挖坑专家，不得不服，褒义）。

竞争策略是怎么搞定对手占据市场。玩家的时间和金钱是有限的，而游戏产品可以是无限的。每年新出几千款游戏，能被玩家知道的、能卖座的就那么几款。竞争策略可以是多样的，比如跟风：走别人的路让别人无路可走（腾讯是这个领域专家，不得不服，褒义，腾讯游戏的成功就是比别人做得再好一点点+强大的营销渠道+庞大的用户基数。），其他策略有产品差异化、细分领域、采用新技术（VR，AR）等。概括起来就是做到人无我有，人有我优，人优我变，牢牢把握市场。

公司战略就是根据我有啥（资源、技术、合作伙伴等）、我能做啥（成功项目案例），我的危机是啥（竞争弱势，市场变化等），提出我要做啥（更高目标，如赚钱、强化品牌、积累用户、业务转型等）。概括起来就是扬长避短，扩大优势。

设计文档帮助设计师更好地组织和推销自己的想法

好的文档应具有可读性，鱼的记忆只有7秒，我的记忆在一篇如同天书的设计文档面前只有0秒。在团队项目中常常听到有的设计师对开发人员说：你怎么不看文档？里面都写的清清楚楚，怎么不照着开发？没人愿意花几个小时看上几百页的厚重文档（这种文档设计师留着自己看吧）。

为了读者着想，设计文档也要注意排版和包装，当成平面广告来做也不过分（自己把控时间）。推销类的文档力求抓住眼球，留下深刻印象；技术类的文档力求简洁明了，逻辑清晰。

一些技巧：

根据文档的阅读对象（客户、自己、团队、特定职能），看人说话，可以用脑图，原画参考图，流程图，列表啥的代替长篇文字。

采用条理清晰的写作格式，如三段论，总分总，中心+论据等。

选择合适的工具（PPT，word，PS，Visio，Excel等），不同的软件有不同的优势。

设计文档中着重传达设计意图和预估风险（面向团队），链接分类的更加详细的开发单元的设计文档（面向实际开发人员）。

曾经做的某开放世界游戏的袭击运输车队的关卡设计文档

设计文档帮助设计师完善开发计划和风险管理

线性的瀑布模式在产品设计开发中已经是一种很落后的开发模式了，首先外部环境（用户需求，市场变化等）是不断变化的，信息时代下新技术、新产品层出不穷，用户需求也呈多样化且易受到引导；其次，设计师对外部市场环境和产品规划的认知，同时开发团队的技术实现能力也需要一些学习和积累的过程。变化和不确定的因素就决定了产品开发不可能等设计面面俱到后再进入实际开发，因为这一步是遥遥无期的。设计师需要根据产品的愿景来设定开发单元的价值优先级，根据任务的轻重缓急来安排工作计划，常用的有滚动计划法和迭代增量开发模式（RUP，敏捷等）。

迭代增量的开发模式

在很多游戏产品开发项目中，设计师同时兼顾了协同开发团队实现（类似于装修设计师+现场施工经理的结合），掌握一些基本的项目管理技巧（至少是风险管理、成本管理）可以大大提升设计实现的效率和效果。现实中多的是脑洞大开如空中阁楼的无视技术限制的设计，也有做产品做到公司破产的案例（替老板心痛一秒，不能再多！）。有的设计师满是天马行空的点子，却不做系统性的文档，在实际开发中想一出是一出，各种临时决定的需求变更，等开发到过半测试验收的时候才发现各种功能不协调、漏洞百出，唯有返工重新设计，导致了巨大开发进度危机。这类风险完全可以在前期设计时采用脑图，方案分析，纸面模拟等方式排除。

写在最后

设计方案的风险分析在大型开发项目中是必需的，设计师可以不懂技术，但必须标明方案中牵扯到的开发单元，以便于团队有效把控技术风险和进度风险，同时能有多套应对实现变更的备用方案。

设计师也需要站在对立面来审视设计文档，同时勇于接受他人反馈和挑战，找到文档的不足并不断完善（图文表达、玩法设计、实现风险评估），文档阶段的破坏性风暴是试错成本最小的（纸面游戏，玩法推理等），不要等到开发阶段投入了大量的时间和资源后才发现设计中的大量缺陷和不对路。

在开发进程中保持文档的更新，最好能形成系列的工作日志（如用户反馈，设计变更的原因，选择方案理由，方案实施效果等），作为知识积累（个人总结或传给后来人）。

在大型项目中，很多设计由多人协同开发，模块化设计集成，迭代增量的设计模式将是主流。开放设计是大趋势啊，游戏从传统的线性战役模式转到了当下的开放世界沙盒模式，项目管理也从线性的瀑布模式进化到了迭代增量开发模式，作为游戏开发项目的设计师，不与时俱进就要被淘汰了哇。（confluence这类知识分享聚合软件是构架开放工作环境的不错选择。）