需求文档prd

用户分类

用户故事

流程图

系统流程图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

细节逻辑的描述

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

字段维度