需求文档prd

业务类名词

交互设计类的名词

名词解释

用户分类

用户故事

用户流程图

系统流程图

流程图

用户类功能

非用户类功能

解决方案

首先从产品方案的角度。一方面可以帮助产品经理进行功能的梳理，确保功能不遗漏。

从研发的角度，研发人员可以通过功能结构图一目了然的知道这个需求到底包含哪些功能。中间的从属关系逻辑关系是怎样的？结构是怎样的？它会有一个非常大的全局视角。在设计技术方案和开发过程中，也可以参考这个功能总览，避免遗漏功能，那怎么画呢？

作用

1来自上一步的用户流程图。按照图中的用户路径，把所有需要和产品交互，需要产品提供能力支持的部分抽象出来。就可以梳理出所有要包含的功能点啦，比如在上面滴滴打车的例子，我们从用户故事的流程图里就可以梳理出关键的功能。包含消息对话，入口对话，消息界面，文字消息和语音消息发送这几个功能。

2来自业务的流程图。同样的道理，在这部分，我们可以从业务流程图梳理出。到底需要哪些系统？哪些产品需要支持的能力？模块儿在这部分可能不仅仅是包含的功能啊。也涉及到你要去对接的其他系统，这些要支持的能力也可以放到功能的架构图里，因为也是要在产品需求中体现的内容。

3在主流程之外可能还会涉及到一些其他的支持功能。这类功能可能不再是用户使用功能的主要路径里，但也是非常非常重要的支撑功能，是必不可少的。常见的支持类功能，比如说通知类的push站内信的提示。用户在购买商品发送短信的提示或者需求涉及的合规调整产品，增加了商业化广告，因为隐私的合规要求还需要在我的设置里增加个性化的广告开关。这些支持类的功能要放到功能结构图里面，避免遗漏

绘制方法（三个维度考虑）

案例

功能结构图

功能名称

功能描述

优先级

功能列表

第一步，明确这个页面的设计目标，也就是这个页面的用户是谁，他们的任务是什么页面，要解决他的什么问题。

第二步，定义信息。根据用户的目标和任务定义出这个页面要达成你的设计目标，它需要包含哪些关键信息？比如在案例中，盒马的首页就需要包含的信息包括这些。首先，针对来购物的用户，有明确购物目标的用户，我们提供搜索和分类的功能，让他们可以主动的找到想要的商品。对没有明确目标来逛一逛的用户，通过个性化推荐促销活动宣传来帮助他们找到自己可能感兴趣的商品。那另外一部分针对在盒马门店购买。来支付的用户，我们需要提供一个快捷的支付入口。让用户可以在首页打开支付的界面，快速完成支付。

第三步，信息模块儿进行分类。对不同的信息模块分类和组织，把同一类的信息放在一起，或者看是否需要整合。

第四步，对信息模块进行分类之后，要明确这个页面的设计思路。有些时候，一个页面核心的目的只有一个。比如说支付页面，它的目的就是让你快速完成支付决策，并且进行支付的操作，有些页面它的目标有多个，比如说在首页，我们刚才提到了它针对了不同的用户，有不同的需求。所以不同的页面，它的设计思路一定要个性化的去看。

第五步，确定最终的展现形式就是你的交互细节，在确定展现形式的时候，你可能中间还需要再做一些事儿，比如说刚才我们只是进行了模块的分类。但中间还有一些具体的信息，比如说商品的价格要不要展示商品的优惠，要不要展示商品的副标题，要不要展示这些部分，你要再梳理一下，补充完整。

5步设计思路

第一，让用户少思考。复杂酷炫的交互形式不一定是好的设计，我们看到很多酷炫的设计，其实在中后期的使用中，它给人会有很强的审美疲劳。大众用户更多的还是需要快速便捷完成自己的任务，交互设计形式也要遵循这个原则，让用户少思考。凭直觉就可以完成操作。

第二个是要保持交互的一致性，目的是让用户降低学习成本，对产品的操作更有确定性。要确保产品中的交互原则，尽量保持一致，比如说页面切换的左滑操作，再比如说所有的操作后的提示是不是清晰一致的？再回到河马的案例啊，我们在前面已经确定了搜索分类，其实是优先级最高的，所以我们在页面的最重要的头部区域使用搜索栏固定的入口，满足搜索需求， 不需要特别大。

交互设计原则

交互状态

用户杀进程在使使用过程中，如果用户强制关闭了程序。再进来的时候展示什么状态？数据是否都保存了？

还有加载失败，因为网络或者其他原因，用户进到页面后信息没有加载出来，怎么去处理？需要反复加载几次，是否展示空页面，这些要考虑吧

异常的状态

表单的状态

文件的上传标准

单选，复选

细节逻辑的描述

这部分字段来源于业务场景的梳理。根据具体的业务场景和功能的需要来确定都有哪些字段，比如说啊，现在电商产品的用户订单后台里面有哪些字段呢？你从业务流程上分析运营或者客服人员需要查看用户的某个订单，就要包含订单里有什么商品以及对应的数量。现在的订单状态，物流信息等等，那在这个业务流程中体现在用户订单后台这个页面的设计中，就要包含这些字段，订单号，下单时间，买家名称，商品名称，商品数量，订单状态，物流信息，这七个字段。

第一类是业务性字段

主要是对系统来说比较重要的字段，比如说用户ID创建时间，创建人修改时间。对上面的案例来说，应该有一个ID作为数据表的主键，在数据落库后生成创建的时间，订单状态更新后。更新修改时间，你看还是非常细致的，对不对啊？

第二个系统性字段

这类字段用于记录管理人员对这个业务后台执行相关操作的。操作信息一般包含操作时间，操作人备注等等

第三个叫管理性字段

数据和字段的说明，梳理和定义

比如说字段值是否包含枚举，如果有的话，分别对应着哪些枚举值？这啥意思？我相信大多数有技术背景的产品经理应该能够理解。对不对？你这个字段值到底包含了几个？对不对呃？如果有的话。是哪些举个例子？比如说比如说有个字段叫这个省市省市这个字段里面包含了所有省市的值对吧？在里面其实就有个枚举，如果类型是时日期时间就要确定是按天的还是到时到分到秒？如果是数值，就需要定义小数点后位，数前位数等等，以及字段值是否可以为空。

字段值类型

来源是系统输入还是自动生成，还是系统间的交互是是不是传过来的？对不对呃，第三个是字段值的值的长度，字段值最长的长度，你要定义成是多少？

字段值的来源

就是在什么时间插入这个数据如流，创建时间应该在这条数据落过的时候写入那状态，应该在上游系统下发某个消息时。进行更改等等

数据的插入时间

字段维度

B端特殊性要求

细节自查表格

需求原型模板

需求原型

子主题

项目排期表

产品文档