本文概述
前言
我必须坦诚——我不是产品经理或负责产品设计的，我只是一个苦命的程序员。所以我为什么要关心产品设计呢？需求和开发文档有什么用？老实说，我觉得这东西没什么用——在从前，写了不少代码后，才发现这么简单的东西是非常有用的。而且我以前也学过原型设计和UI设计，也是不知道为何用这些浪费时间的东西，但是最近也慢慢开始理解了。
假如现在要开发一个项目，“想要开发X”这仅仅还是一个IDEA——首先，你可以马上创建项目进行开发，没有对这个IDEA有任何描述，只是可能在脑子里想了想，或者听过被人说过一点点，可能你会做一些文字记录吧！
这样是没问题的，没人阻挡你写代码——但是从何写起？直接创建类实现还是使用TDD？界面如何实现？桌面端、Web端移动端？没事，没人阻挡你写代码，也没人说你没学过编程或UI设计，没人说你算法写得不好，没人说你不帅……
——但是这样做的后果90%左右都是悲剧收场，一种可能是你写不下去了，为什么？（这我就遇过），因为中途可能失去了方向，我会做，但是我要做什么呢？另一种可能是完成项目了，但是非常差（我也经常有）——比较多，项目还是可以用的，但是做得看着非常勉强，不标准。
后来我有开始使用文字先记录要实现的需求，写代码的时候就根据这些需求逐一实现，奇怪！这非常奇怪！这在告诉你，你的任务就这些，做完项目就算完成了。再后来我学会开启项目前先详细设计一下，包括界面布局、代码实现方式。
到目前，我决定使用一般流行的方式——相对标准的需求文档，依据需求文档来开发，依据一个详细的需求文档，就是开发的全部任务了，想那么多没用。
本文讨论需求或开发文档带有我作为程序员的角度，一来也是为了令自己能更好独立开发，二来也想分享一下我的想法给大家，有不标准的地方莫见怪。
产品设计的第一个问题
需求文档还是开发文档？需求文档还是原型图？需求文档还是手绘图或交互原型图？……你是否有听过类似的争论？总有人开始指责别人不知道何为产品设计，指责别人不知道什么是需求文档，另外还有关于交互、体验和原型设计争论。
我认为，这没什么好争论的，若是岗位不清晰，那只是：小公司没钱，产品经理可能什么都做（甚至编码），大公司有钱，可能岗位区分更清晰。但并不是说大公司就是标准，而是只让几个人仅仅做体验或原型那样更专注，效果可能更好，但是成本大呢！
维特根斯坦说：能用就够了！你可以详细分类，但是总是在概念上争执不下并不能解决实际问题呢！实际上这些争论的概念都是在产品设计的范畴内。
这个问题也只是顺带提一下，概念很难做本质上的区分的（哲学的说，你无法得到任何概念本质上的定义），达到我们交流的目的，达到实用的目的就够了。
产品需求文档要多详细？
你是否问过这个问题？需求文档及其每部分要描述到多详细？记住：无论是交互动态式、静态式、文字、图片、语音、视频描述，都不会有一个最本质的描述，一个好的描述就是它刚刚好能提供下一步的实现。
什么意思呢？例如你在做产品概念化分析的时候，描述刚好能提供给下一步定义需求文档即可；而界面交互原型图，其描述刚好能提供给程序员实现即可，也就是说，这个描述不是那么泛的，开发人员刚好能理解并且能实现即可。
但是你看概念化分析、简要需求文档和原型图描述其详细程度是不一样的，都是相对而言，我们不需要每一步都要绝对详细，但是也不能随便描述。
下面介绍产品设计文档的全部内容，你可以把它当做一个模板看待，但是我建议是你理解了，而不必总是记住模板。
IDEA：产品概念化
产品从哪里来的？无中生有还是像有的天才那样突然想到的？第一个IDEA从哪里来？什么灵感？要灵感吗？你是否有和别人讨论过开发什么？“如果你能开发一个X，可以Y的就好了”，比如我一个同学就和我说过：“可以开发一个可以识别花的软件吗？”。
本人学过一些哲学，必须说，首先有产品的第一个IDEA——这个还真有点偏向自由意志。因为这个IDEA是从何而来的——这是无法形式化的，无法形成一个有效模式，使得你按照这个模式就有新的IDEA了。你得佩服有的人真的是天才，突然有个绝妙的IDEA、并付诸实现的人真的是极少极少。
哲学里经验论有一个著名的英国哲学家：休谟（Hume），看过他是如何解释想象力的：你可能经常玩微信，即使你不会开发软件，你也能描述得出微信软件的颜色、形状、布局、运行流程等等（经验印象，impressions），但是你第一个颜色的经验多数都不是来自微信，而是你出生的时候看到的。你或许可以详细描述红色，可以区分得了粉红和深红（impressions）。所以不要担心，你即使不玩微信抖音，也并不会真的比别人落后，你只是不习惯而已。
但是休谟的经验论并不能解释第一个IDEA首先从哪里来的，他的意思是说：你目前实现得到的实物（软件或硬件），都是来自于你的经验（这些impressions的组合）。例如你能想象狮身人面像、能想象一个脚是两个车轮的人，有人可能说我并没有看过狮子怎么办？好吧，但是你有毛发、柔软、眼睛、嘴巴、头……这些经验，所以就算你没看过你也是可以想象得了的。
综上所述，一个产品在最初的时候，它来自一个IDEA，而设计产品就是在概念化这个IDEA、并同时使用经验impressions详细描述这个概念，一个产品就是由所有这些impressions组成的，而它们是如何组合的是自由的。（所以，并没有一个东西叫做X产品，X只是所有这些经验impressions的集合，是不是很哲学？哈哈）
什么是IDEA？这个是非常随便、非常自由的，就像上面说的开发“能识别花”的软件就是一个IDEA，你可以随便想——但是这个也不能表明人有自由意志，因为我们能说出这样功能的软件，也是因为之前有过相同或类似的经验了，请不要忘记：没有人有绝对100%的新IDEA使得他绝对与众不同，如果你发现你的IDEA已经有人做过了也不要紧，尽管采用；如果你认为你的IDEA是绝对100%不同的，你可能不是脑子长草了。
什么是impression？比如红色、淡红就是，当然这个太仔细了（这可以在原型设计中体现出来）。再比如，我们要实现识别花的软件，你可以立即想到——如果是移动端的，你就知道要有界面了（你有过关于界面的经验）；另外识别花可以使用摄像头或上传本地图片（你有过这些使用图片的经验）；如果你是个资深码农，或许你会想到这个功能需要使用机器学习；既然可以识别花，为什么我不添加多几个功能呢？再令它可以识别小狗和蟑螂吧，识别蟑螂是不是很刺激！
另外还需要服务端吧……想想就头大，如果你认为自己很牛逼，想到就马上实现——那肯定很辛苦，因为你只是大概想了一下（我以前就经常这样的痛苦）。
举个综合的例子，入门开发比如我就有一个开发聊天软件的美梦，然后开始着手设计这个软件，例如聊天窗口你会如何设计呢？90%概率你都是采用左右的方式显示吧？（多数经验都是这种形式）展示好友列表你会如何设计？八成都是类似微信或QQ的方式，因为你的关于好友列表的印象多数都是来自QQ或微信的。
——所以，抄袭并不可耻！抄袭不可耻！所谓X不抄袭或不够创新，一个可能是：在软件里X的形式不常见、X形式常见但很少，而抄袭就是常见的成分太多了——但是都来自经验，哲学的来说，它们并没有什么区别，都没有100%创新。
但这不是不设计的理由，想到什么就设计得了，大家不要老追究或纠结那种100%的问题，试想下，大家学编程的算法若都来自《算法导论》，那么大家写算法的时候算不算抄袭了呢？大家都用JDK呢，是不是都是在抄袭？
另外，主要是要注意：就算你想借鉴别人的设计，你也不要完整copy别人的形式，做一个和别人一模一样的东西——这就说不过去了，我们应该盗取别人的IDEA，而不是别人的产品。
由上面的讨论，你可以看到：想象力决定了你的创新程度，想象力是用来将impressions组装成一个概念产品的。
为什么我会这么详细讨论产品概念化这部分呢？因为这部分太重要了，产品设计没有编码那么实际，如果本人不理解，产品设计看起来就是很虚幻的。这里找到了一个可catch IDEA的方式，概念化产品就是运用想象力用经验impressions组装它，产品需求文档就是在做件事。
产品概念化分析
有一个IDEA，有了一些关于这个IDEA的概念，总不能只是详细吧？——一定要记下来，你可以使用在笔记本上、使用一些自由的画图工具，想到什么就记录下来或画出来，任意你想表现的形式。
本人觉得这部分没有标准的形式，但是有几个可参考的：
- 因为一个IDEA可能只是一个功能，所以很有必要再增加几个功能，或其它额外的功能，让软件不那么单一。
- 尽量使用你的想象力把它描述出来，虽然还没到实现阶段，但是也要尽量具体，描述的太泛——你可能不知道自己在想什么。
- 尽量描述全面，软件可能包括命令行界面、GUI界面、运行环境、服务器、客服端。
本人习惯使用windows自带的画图工具描述，你也可以使用思维导图，或者一些更为自由的画图软件。描述大概全面了就可以导出PNG图片到Axure中（你也可以使用Axure，但是个人觉得不方便），因为我的建议是把整个概念化和原型设计等等一些东西全部放到Axure中，这样就不用那么多工具切换来切换去了。
概念化产品描述不需要详细到实现上，最好是有经验的设计师吧：你能想到这个描述它在前端或后端是可以实现的，就够了。
产品简介
这部分主要是描述该产品的主要功能、市场价值、简要用法、主要特色等等，非重要信息，简要说明即可，主要是让看文档的人知道这个项目是做什么的。
需求文档版本
版本说明是描述文档每个时期的改动情况，但是你如何区分每个版本的区别呢？有人说我用红色字体标记清楚，拜托！别天真了！项目文档随着更新内容会越来越乱，或增加或删除，给你100种颜色的字体好不好，就算你标记了，你也区分不了，请不要使用说明字体标记的方法了！
如果你真的需要版本管理，请使用Git，GIT！或SVN也行，这才是正道！而且我推荐使用Git，也很有必要使用。
简要需求文档
由上面概念化产品的分析，我们可以得到一个草图（就是什么内容都可能有的图），这个草图包含了我们实现这个产品需要的主要东西，现在我们需要整理这个草图，尝试使用文字把这个软件的大体需求详细描述下来。
所以，你看产品概念化后输出一个草图，而输入这个草图，我们可以整理出更为精致详细的需求描述，输出则是一份简要的需求文档。
这里可以使用excel或使用Axure的表格简要把主要需求列出来，要注意这里还不是详细的需求，如果你使用Axure做了原型图，那么之后已经不需要再做详细的需求文档了。
表格至少包括两项：需求名称和需求描述，使用命令式的简洁描述即可，也不是营销，这是给开发人员和产品设计人员看的，所以不要写那么多余的描述。
要注意的是：有人设计人员可能没有这个部分的，这对于我来说很有必要，不管如何，整个产品文档的主要目的是详细描述产品的概念，以让它实现出来，你可以使用其它你喜欢的方式，能达到这个目的就可以了。
如果需求很多，尽量从简，因为这个只是大纲，详细的工作在交互原型图中做。
考虑需求时，可主要从设计角度和使用角度考虑。
产品结构图
为什么突然要做产品结构图了？我也不知道呢，我也是借鉴别人的。觉得也算有点必要，它的作用是能在逻辑上纵观整个项目，它是做原型设计和编码设计的前奏或准备。
如果不理清一下整体结构就开始设计，可能会有些乱，结构图的作用就提现出来了。结构图包括两部分：数据结构图和界面结构图。
程序的主要功能就是处理数据，不管是什么软件，不是处理数据的话，请问它还有存在的必要吗？只是可能数据不仅只是数字和字符串。
我们主要是参考概念化后的草图和简要需求文档，然后提取整个程序需要的所有数据，数据的表现推荐使用思维导图的形式，简洁清晰，做完导出到Axure即可。数据结构图除了提供给交互原型设计，主要提供给编码设计。
另一个是界面结构图，为什么是界面结构图呢？因为对于用户来说，这个软件的界面就是用户对它的全部印象了（包括命令行界面），界面是这个命令行的外界表征。这部分同样推荐使用思维导图制作。
记住：做每一步的描述，都要回头看看，有没有满足上一步或之前的需求。比如做数据结构图，对照简要需求文档，看看这些数据是否足够实现项目了；做页面结构图，看看这些页面是否符合所有这些需求了。
界面交互原型图
交互原型图是产品文档最主要的内容，通常交互原型图是对项目需要的每个界面逐个设计，其界面是完整的界面。除了设计实现的产品实际效果外，一般使用软件如Axure制作的的原型图还需要带有标签注解说明，标签的主要作用就是解释界面元素的作用和操作，充当详细的需求文档说明。
如果你不打算在这里添加标签注解，那么下一步你就要详细书写需求文档了，所以还是建议使用标签，Axure的Default元件库中有标记元素。你还可以利用Axure，给界面的每个需求详细用数字标记，这样开发人员看文档时一目了然。
产品用例图
有些产品设计是不做用例图的，有的则做，有人说对开发人员的帮助不大。我建议还是做一下主要的用例，制作用例图一般是使用excel或Axure中的表格，它和需求文档类似，或者使用图片的形式。
用例文档主要是从使用者的角度详细描述软件的使用情况，一般包括用例名称、执行步骤和预期结果。我建议是做软件整体最主要的用例就行了，写太详细的用例作用不大（除非提供给测试）。因为我觉得用例的最主要作用的供程序员开发或测试的，比如方便TDD开发，所以如果产品设计人员不懂编码，那么用例文档可能用处不大。
整体功能流程图
功能流程图也是一个逻辑图，它和结构图是类似的。功能流程图帮助我们理清该项目整体的所有执行路径。当然，可能你不需要做的详细到代码上去，只需在逻辑上是比较详细即可。
这个流程图可以让开发者找到回家的方向，以前有时我会感觉自己深陷在一个页面的一个功能上，久久不能自拔，看下流程图，看看你做到哪里了。而且流程图还给出这个程序的主要执行路径。
编码设计
这部分一般产品文档可能是没有的，编码设计可能交给架构设计师了。我个人则需要这部分，毕竟我是个程序员，编码设计主要就是根据数据结构图和交互原型设计接口了，设计接口主要参考TDD和数据结构与算法。
总结
本文讨论项目开发的产品设计和需求文档，主要是概念化产品这部分比较详细，其它没有示例，真是不好意思，我现在也是在做一个产品文档，具体内容就不方便展示了，但是可以展示页面结构，如下：
虽然其它部分没有提供截图，但是我觉得主要是明白概念化产品就可以了，我们就是在把这个产品的概念详细清晰的描述和展现出来，而其中的相关步骤只是把它细化了。
而且，我认为产品设计最重要就是概念化产品了，它不是虚幻的，并非胡思乱想，它是把一个简单的IDEA从想像到描述、到原型模拟，并最终实现的过程，概念化产品就是把我们的想象力变成现实。
OK，终于写完了，牙肉好痛，天哪！！！！！
