今天完成的事情：

完成了后台模块的原型图和验收标准

明天计划的事情：

任务六无问题的情况下开始做任务七
遇到的问题：

今天不知道怎么在Axure中添加表格，百度找到了结果
收获：

一、为什么要用思维导图？

思维导图的最大的两个好处就是方便记忆和理清思路，同时思维导图特殊的记录方式也便于捕捉跳跃思考。

二、如何看思维导图？

1、看中心主题，即思维导图位于中间的部分。
2、看主干
3、看支杆，不懂可以继续向下找线索

三、如何写出详细且易于阅读的PRD？

       PRD对于产品人员而言，就像开发文档对于开发人员、测试用例之于测试人员。但PRD又有些不一样，产品的PRD需要给业务人员、内部产品人员、开发人员、测试人员阅读。所以PRD不仅要详细，同时还要对开发、测试等非产品岗的人员友好，让他们便于阅读。

      产品人员在写PRD时，要记住两个要点：

1. 1、尽可能写详细 ；
2. 2、易于开发、测试人员阅读

1. 阅读测试用例

新手产品可以向测试要一份测试用例，仔细研读。看看测试用例中的分析。这样在写PRD的时候，也能够大概清楚测试会关注哪些细节。你写的PRD也就越对测试的胃口。到时候测试找你确认的问题越少。

如果拿到了测试用例，可以先关注一下“测试前提”，这可以和批注中的前置条件进行对应。而“验证场景”是测试对页面的样式、内容的展示、功能的检查、校验。而“预期”则是批注里产品想要实现的效果，这部分也是产品应该在批注里详细描述的内容。

2. 写批注的时候，考虑到各种情况

写PRD的时候，如果对上下游业务不是特别熟悉，很容易会遗漏细节。所以在写PRD时，要沉下心来，多问问自己：如果出现XX情况那怎么办呢？

例如我们现在每天都要用的扫码支付的功能，可能现在看来就是掏出手机，对着二维码扫个码。但是需要考虑很多特殊情况。例如：如果用户手机没有网络或者网络不好的情况下，怎么显示；二维码不是收款码扫码后怎么显示；如果支付宝扫了微信的收款码应该怎么显示；用户默认的支付账户是哪个；如果用户默认账户里的余额不足怎么提示……

一些功能可能看起来简单，但其实里面会有复杂逻辑，所以产品在确定了主要方案后，需要多思考一些特殊情况，然后在PRD里进行备注。这样不至于测试来问你的时候，你措手不及，发现自己的方案有很多漏洞。

3. 思考内容“从哪儿来，到哪儿去”

这种情况大多出现在B端产品的移动端设计中，需要考虑两端信息的对应性。在设计移动端时，一些展示的内容，很有可能是从系统中调用过来的。所以在写批注是，要备注清楚这个字段是调用的当前系统的哪个模块的哪个字段。

而在移动端提交的内容，则要考虑这个东西到哪里去。也要备注清楚这个内容填完后生成的记录会展示在当前系统的哪个模块哪张报表。

四、PRD要易于阅读

1. 流程图和用例

在PRD中提供流程图和用例，能够帮助开发、测试人员尽快地熟悉业务流程、用户角色和核心功能。

process on上的用例图案例除了流程图和用例，如果时间允许，还需要提供功能列表。这样的话，在熟悉大致业务和核心功能基础上，开发和测试还能进一步了解详细功能。

2. 言简意赅、语言规范

在写PRD的批注时，尽量语言规范，避免口语化。简洁明了的描述能够给读者一个好的阅读体验。尤其是项目页面较多的时候，复杂的页面，再加上口语化、冗余的文字描述，开发、测试人员阅读起来会比较费劲。

在PRD里，可以用多种形式来进行表达。例如：遇到一些比较复杂的功能，涉及到状态变化，描述起来文字较多，难以理解。这个时候就很适合用一张把表格来展示状态的变化。

3. 页面展示具有强关联性

由于页面之间可能会存在交互的联系，所以页面摆放时，最好是根据顺序进行摆放。这样的话，开发和测试也能更好地理解页面与页面之间的关系。同时，批注也最好也页面紧挨在一起。这样的话，在看的时候，能够同时看到原型和备注。

所以从PRD展示角度来看，墨刀会是比较友好的工具。使用墨刀的话，原型和批注可以展示在同一个页面。而使用Axure，如果画的是大幅的网页页面，在预览状态的时，无法同时看到原型和批注。这样的话，阅读体验就不是很好。很容易发生开发嫌麻烦只看原型、或者甚至找不到批注的的情况。

总结

如果没有经历过几次项目，一开始写出来的PRD，会比较简单。开发、测试会轮番地来向你确认问题。在这个过程，会懊悔自己有很多细节在一开始没有想清楚。当然会有优秀的人能够一开始就思考得特别详细。那我们这些不够优秀的人，要在一次一次的项目中总结问题，不断改进。同时要和团队的开发、测试不断磨合，综合考虑他们的想法。

最好的PRD永远会是下一份PRD。当然不想写出完美的PRD的产品不是好产品。

 提取码: ysk8