设计需求文档的作用 需求文档功效解读
做产品的这几年，总有人会问我:我想做一个软件。怎样才能画出原型？我刚转行做产品经理。怎样才能画出原型？随着新人对产品的经验越来越多，一遍遍纠正新人画原型的缺点，沉淀出一套
做产品的这几年，总有人会问我:
我想做一个软件。怎样才能画出原型？
我刚转行做产品经理。怎样才能画出原型？
随着新人对产品的经验越来越多，一遍遍纠正新人画原型的缺点，沉淀出一套通俗易懂的方法。
希望以后别人问我同样的问题，我可以用这篇文章来回答TA的相关问题。
首先，在你做之前在设计用户使用的app产品时，一般情况下，在正式绘制app的界面之前，要确认以下信息。这些信息和界面密切相关，不要偷懒。我建议新同学直接写下自己的答案并记录下来，在界面设计中再回来反复检查。
(1)用户来找你要设计的这个产品/功能是为了什么？你给用户提供什么价值？这个值真的是用户需要的吗？
(没有价值，价值不是用户需要的，或者需要这个的用户数量很少。建议降低优先级，多想想核心功能)
(2)你觉得你要设计的这个产品/功能和市面上的同类app有什么区别？你们有什么共同点？你认为你的需求设计应该在哪些方面与竞争产品不同？这种差异化是否与产品对用户的核心价值有关？
(如果差异化不成立，不建议浪费天马空的R&D成本。这种差异化的存在可能是:产品定位不同，产品目标群体不同等。
(3)确定你设计的产品/功能的目标用户。研究了解这群人的画像。
(功能的用户画像不一定是产品的用户画像。比如直播间的家庭用户群可能是公会用户，而不是app拥有者)
(4)确认你设计产品/功能用户的核心任务。张小龙说:一个产品只能有一个主线功能。
那么，用户判断这个产品/要设计的功能线程的任务是什么？
好了，我觉得上面说的很清楚了。你的产品设计/功能设计背景就是搞清楚。
这里建议新同学，比如产品实习生，主动和上级沟通了解这些逻辑，否则设计出来的原型图会被自己想象出来的背景画出来。
二。开始设计产品开始设计产品，错误的方式:
一上来就打开软件开始画。一边画，一边想这个页面需要什么功能和信息。
这会导致你的原型图出现偏差，与你想要设计这个产品/功能的目的不符，无法系统的展现出产品/功能的差异。
所以我建议对于复杂的产品/功能设计，前期多花点时间思考，把图纸留到最后。
接下来我会列出绘图前要写的内容，有些内容也会体现在标准需求文档中。(我会在文末给你列出需求文档的结构！)
1。用例图
用例图类似图中这种。（图片来源于网络）
用例图与图中的相似。(图片来自互联网)
用例图包括:角色，做什么/任务。
【价值】:帮你梳理你的设计需要涉及的角色(普通用户或运营人员或kol)。尤其是梳理后台设计需要操作的功能，这个贼好用。
2。流程图
流程图是C端设计中常用的。(图片来自网络)
我经常使用用户任务流程图。把产品/功能中用户主要任务的过程写清楚。
【价值】:会帮你梳理设计中需要的功能，需要判断的关键信息(比如是否登录，是否有×数据)，不同关键背景用户的任务流程差异。
当然，app设计也会用到“业务流程图”。业务流程图是为了让产品经理更清楚产品的底层流程以及与其他业务模块的交互。
例如:
内容发布的一个用户任务流程图如下:用户点击发布按钮，判断是否登录，编辑blabla，点击完成按钮。
内容发布的一个业务流程图是这样的:用户发布内容，内容进入第三方平台自动鉴定，鉴定后到运营后台，运营人员审核。
业务流程图如下:(图片来自网络)
在画原型图之前，用到用户任务流程图比较多。
在画原型图之前，有很多用户任务流程图。
在模块和业务设计之前，会用到很多业务流程图。
c端需求文档可以根据需求复杂程度和具体功能选择不同的流程图。
3。信息结构图
信息结构图用于说明:
产品页面上有任何特定的信息字段或者产品的某些内容。
我举个例子:
如果我需要设计一个电商产品的模块，我需要考虑产品的信息字段，比如产品封面、产品名称、产品评价等。我考虑到主页需要推荐产品，所以我会在产品的信息结构中添加“编辑推荐”字段。
但同时我需要输出C端产品详情页的信息结构，让别人帮我设计产品页面的原型。然后我就不写“编辑推荐”这个字段了，因为我不想让C端显示出来。
我还需要设计一个产品列表页面。列表页面中每个商品暴露的信息字段必须在商品的信息字段中，并且会小于C端商品详情页显示的信息。因为列表位置有限，我只能选取更多的核心字段来展示。
总结:页面的信息结构只整理出当前页面可以看到的信息。有些信息字段存在，但未显示在此页面上，或者正在使用，但用户看不到。
在产品从0-1的过程中，我们需要更多的设计模块和特定内容的信息字段。
成熟产品的功能/页面需求更多的是页面信息结构。比如微博的内容里有很多信息字段。如果让你设计一个在微博内容站外打开的H5页面，你会选择显示哪些信息？会添加哪些信息？
[页面信息结构的价值]
让你更加关注目标用户在特定场景下需要的信息。
如果你开始画图，一边画图一边想这个页面需要哪些信息，很容易被画面中的布局所干扰，而忽略了场景中用户最需要的信息字段。
所以页面信息结构的输出过程更像是让你整理内容的所有信息字段，结合用户特征和场景，筛选出你在这个页面上最需要的信息字段的过程。
新手一开始可能很难抽象地思考信息结构，但也可以边画边思考。不过我建议在画好之后，检查一下页面信息是否是用户需要的。
4。原型图纸
终于到原型图这一步。
最后，我们已经到了原型绘制的阶段。
我们梳理了上面的:产品/功能价值、目标用户画像、核心任务、竞争产品差异化、用户用例、用户任务流程图、页面信息结构。
基本可以确定:需要多少个页面，不同页面的功能点是什么，页面除了功能按钮还需要显示什么信息。
然后开始排版！
排版不是排列组合的问题。我们需要解决:
(1)用户的第一感觉和认知是什么，
(2)用户在阅读页面后，是否先获得了自己想了解的信息，是否足以吸引用户查看？还是帮助用户解决问题？
(3)核心任务的操作是否可以随时随地发现。是否符合用户交互习惯。
一般来说，我们会借鉴用户感知的类似产品界面设计，也会在我们想要体现的核心差异上有所创新。
这就需要大家多分析竞品，多练习了~
附录:需求文档格式让我列出标准需求文档的格式。基本的C端功能设计需求和新产品模块设计都适用。
其他技术需求和B端需求可以自行确定。
(1)分工
确认自己需求所需要的人员资源，后期团队确认后添加到具体的名字中，方便团队成员咨询和责任到人。
常用的角色有:产品负责人(也就是我自己)、技术负责人、客户端、前端、服务器、AI、设计、测试、运营。
(2)需求背景
解释清楚这个需求是怎么产生的。把自己的思维逻辑写清楚就行了。比如哪些用户的需求没有得到满足。
如果有量化数据，也建议补充一下，更有说服力。
(3)需求的目的
自己需求的主观目的，比如要提高什么，改变什么，解决什么。
(4)需求目标
最终考虑是否达成目标的量化数据，也可以作为自身需求的北极星目标。
(5)核心逻辑
向团队解释为什么制定这个需求计划可以达到需求目的。
在这里，我想解释一下我自己的计划的思维逻辑，以及在达到同一目的的各种方法中，为什么采用这种方法。
(6)用户任务流程
不可以，看上面的具体说明。
(7)需求详情
要求的细节包括:
需求-哪个功能点和哪个页面
需求原型图
需求描述——结合原型图明确你的具体需求，包括哪些信息字段，字段在哪里生成，字段格式以及字段的特殊描述；功能，特殊情况描述，特殊提示。
(8)操作要求
配套操作中需要做什么。
好的产品经理看大局，生完孩子什么都不管。那么你的功能可能永远用不完。
(9)埋点
埋点要求给DA或者，不同的队伍要求不一样。
嵌入的目的是:后期监控关注功能的用户情况，便于不断迭代和发现问题。
(10)需求变更记录
我用了几次，主要是记录自己的修改记录。方便其他成员查看。但是简单的函数我几乎没用过。毕竟我感觉还是口头沟通后直接修改需求细节比较好。
