前面做了一个基于案例定制的在线客服咨询的项目，总结出产品项目设计中的关键点，希望能够在后续的产品设计中多思考，在先前的经验上更加高效地打造出一款产品。

　　一、场景的分析

　　1、重要性：

　　用户的场景化思维，不是一种方法，更多的是一种思维。假想自己是产品的某一用户，在具体的场景中，带着具体的目的，来使用产品，你希望看到、用到一个什么样的产品。你希望流程是怎么样的，才能达到自己的目的。

　　所以场景化思维，决定了你这个产品能不能用，好不好用。

　　2、分析过程：以定制案列在线客服咨询为例：

　　(1)首先，要根据用户场景，整理出符合用户心智模型的信息架构。

　　对于咨询用户来说，他需要在能够找到“我要定制咨询”的入口，并且这个入口的设置符合他的心智模型。比如说自己心中有一个具体的案列，他只需要在一个核心的入口咨询即可。如果是看到了具体的案列想要定制，则这时在具体案列旁边也需要一个咨询入口。

　　对于客服来说，能够接收到用户的消息，并且这个入口也应在合理的结构之下。

　　(2)要对功能所处的应用场景进行详细分析，了解场景的限制条件。

　　以下列举两个场景的思考：

　　场景一：连接

　　1)登录用户—-在线客服

　　这是最核心的场景，登录的用户和在线客服进行聊天。这时需要注意的就是客服的分配规则，客服都在线应该如何根据用户的情况，或是根据客服的情况去分配?具体的分配规则根据业务情况设计。

　　2)登录用户—-离线客服。

　　如果由于公司资源和业务量的需求，客服并非24小时在线。非工作时间时，用户能不能和离线客服进行聊天?我们这里采用的是留言的形式，在客服上线后进行处理。同时需要及时给用户反馈，告知现在是非工作时间，不能收到及时的答复，但是可以留言。

　　3)匿名用户—-在线客服/离线客服。

　　匿名用户跟登录用户最大的不同就是匿名用户的uid是临时的，有时效性的。所以跟登录用户的不同就在于匿名用户有一定的期限限制。为了使客服能够及时的回复，我们这里还启用了微信通知来通知客服。

　　场景二：对话：

　　1)刚开始聊天时，用户看到一个好的案列，随手就会问客服这个怎么做或是可不可以定制?因为咨询入口就在这个案例的旁边，所以用户不可能会把这个案例的名称给客服发一次，为了沟通的顺畅，客服需要知道这个用户指代的是哪个案例。所以在聊天的过程中，就需要把案例名称自动一起发给客服。

　　2)聊天的过程，用户可能由于其他原因关闭了聊天窗口，那么这个时候应该给客服以提示，用户暂时已经离线，告知客服不会收到用户的及时反馈。同时，如果客服已经给用户发了消息，那么也是需要在用户端做相应的提示的。

　　所以对于场景的分析一定要尽可能细，每种场景下的情况都需要一一列举，哪些是核心，哪些可以舍弃?只有了解大局，研发才能确定整体的架构设计。否则在做的过程中发现一个场景漏掉了，后续就会加需求，这个需求很可能就会影响整个技术框架的设计，导致项目延迟上线。

　　(3)对各种场景下的功能需求和问题，提出合适的解决方案

　　基于前面的场景分析，提出对应的方案也就比较容易了。在提出方案的过程中，还需要产品经理要有同理心，站在用户的角度去考虑，在这个场景下用户会遇到什么样的问题?要如何避免用户犯错?用户犯错了之后应该如何补救?用户希望收到怎么样的反馈?

　　同时这些解决方案需要和技术一起协商，有时候技术实现不了的，可以换一种形式去实现。

　　3、如何训练自己的场景思维?

　　1、要有同理心，先看别人怎么做，然后自己跟着做，模仿的过程就是体验的过程，体验场景中的喜怒哀乐，用体验到的情绪指导自己的行动。

　　2、多接触用户，多与其交流，多听听他们的吐槽和反馈，多去体验。

　　3、训练自己的想象力，把看到的场景自主构建、补全细节在脑海中展示出来。想象力越好，构建的细节越丰富、真实，就越能从中感受到用户的情绪。

　　二、PRD相关文档：

　　经过前面的需求的分析，完整的输出流程图是对前面场景的概括。技术将会按照这个逻辑去进行开发。流程图画好后，需要连同产品原型进行需求评审。

　　产品原型决定了你的产品长什么样，而prd文档决定了你的产品规则逻辑。产品的流程图，一定要画。

　　产品流程图，一般用visio画：

　　产品原型：

　　一些小tips：

　　PRD文档每个公司的要求不同，有些采用word的形式，有些直接采用在原型旁边标注的形式。适合自己项目组，方便组员沟通的就是好的文档。

　　无论是何种形式，PRD文档的书写要细心，产品规则要说清楚，同时交互形式也要写清楚。尽量要多考虑产品的边界值，以输入框为例：

　　输什么样的值对应返回什么样的结果?返回结果的规则是怎么样的?当没有结果可返回的时候怎么处理?

　　输入框的输入字符格式限制，输入框的长度限制以及错误提示。

　　三、写在最后：