画画的时候，会先想，我要画一棵树，然后在图纸上打底稿，用铅笔勾画树干、树枝，等到树的形状都勾勒出来了之后，再在上面涂上颜色，用不同的颜色绘制树干，树枝，树叶和花朵。
而产品设计的过程，正如画画的过程，现有一个产品目标，再由目标确定大致的功能内容范围，进行产品的信息框架的构建，核心使用流程的搭建。在这些工作的基础之上开始绘制有形的，用户可使用的交互界面。再最后进行界面的美化，最终完成了产品的整体设计过程。
但是有一个问题一直困扰了我很久:
在产品设计的过程中，如何综合使用需求规格说明，以及产品原型？
我所在的公司基本都是面向政务的B端项目型公司。
在我转行做产品人员的第一家公司，领导教会我们的是，在产品目标、用户目标的识别之后，通过用户角色，用户故事来构建应用场景，然后在此基础之上，进行信息框架设计、业务流程设计，再进行详细的产品原型界面设计。这个过程跳过了需求规格说明书的编写过程。真正需要需求说明书的时候，往往是在验收的时候，为了应付验收而编写的“应付式”文档。
在我去的另一家公司，则这个公司的有个做了十几年的开发经理，在和他合作的过程中，他要求我们无论如何都要写需求说明书，在里面写明业务目标，并画好系统的核心业务流程，定义好各类表单，表格的格式。而至于原型，则可有可无，他更愿意通过需求说明书来指导开发来完成任务。
都是为了让开发，客户，公司其他部门的成员能了解到需求是怎样的，以及需求如何落地，转化为产品，提供给到用户进行使用。但是不同的公司配合的模式千差万别，很多情况下，都是由公司生产部门团队里面有话语权的人来掌控这个产品设计的流程。
不知道会不会有人和我有一样的烦恼，怎样的产品设计的过程，才是一个高效，高质量的过程。
我自己也尝试过在产品的设计过程中同时运用需求说明书与产品设计，补足各自的缺点。
需求说明书优势：
1. 更丰富的文本说明，能阐释清系统的背景和目标
2. 线性地描述，可以更好地表达业务流程，模块、功能之间的关联关系
需求说明书的劣势：
1. 不能直观地体现用户使用系统的交互过程
2. 用户可读性差，一般人都很难有耐心把一份需求说明书完整仔细地看完
产品原型的优势：
1. 图形化界面，受众视觉感知性更强，能使受众更快地理解“产品是什么，做什么”
2.直观地体现用户使用系统的交互过程
产品原型的劣势：
1. 在表达模块，功能之间的关系，以及表达系统业务流程方面，显然不够流畅
2. 一般很少在产品原型上花大量的精力描述背景和目标。
但是同步的操作真的很让人头疼。两份文档在对于产品的定义的内容，有很大一部分，特别是功能点，功能规则的描述，总是有大量的重复，这就造成了，本来想要配合两者的优势来提高产品设计的质量，却导致：
1. 一旦发生业务规则，交互规则变化，两边的文档都需要更新
2. 开发人员不知道以哪一份文档为主，或者总是有一份文档是没有实际效用的。
所以，是不是两者没有必要在一个项目中同时使用，应该有所区分，在不同的场景下使用不同的方式呢。
有说敏捷迭代的软件开发模式就用原型；而瀑布流模式就用需求说明书。而也有说法是C端产品偏好用原型，B端产品偏好用需求说明书。
这个问题其实一直都有困扰着我，直到今年，遇到了以传统软件工程的设计思想指导做系统需求分析的赵哥，交流了几次他对需求定义的理解，需求捕获的理解，以及需求说明书里面的建模过程的理解等，才受到了启发，找到了两个文档之间的分工和合力。
产品角度的分工：
需求分析的过程产生了需求说明书
用户体验设计过程产生了产品原型及视觉界面
技术角度的分工：
需求说明书是系统架构设计，类对象设计，数据库表设计的前置条件。
原型设计是功能模块开发，前端页面开发的前置条件
