用原型代替PRD时，原型应该包含哪些内容

随着互联网节奏越来越快，传统的需求文档已经比较难适应市场的脚步，特别对于要求敏捷的团队来说，冗余而细致入微的需求文档已经成为包袱(这么长个文档领导也不会看呀)。目前大多数团队更喜爱直接使用原型来代替需求文档，然而所谓的原型可不只是画画线框图哟。

首页，原型的使用者包括产品、UI、研发、测试等(商务呀，上级呀)。这么多人参考原型来工作，压力不小哦，一旦表达不清，出现歧义，研发的结果的就会教会我们什么叫“偏差”，不仅可能会背离产品方向，还会影响节奏和效率。所以该有的还是还有，高保真低保真什么的事情况而定。

变更日志

原型不可能一步到位，相信大家深有体会，所以每次更改后再给项目成员时，别人不知道你改了哪些地方，这是件很头疼的事。这种情况下，更新日志就显得尤为重要了，大家一看日志就知道你改了哪些，直接锁定目标，效率大大的提升。

更新日志 示例

版本说明

同上，只不过是每个迭代版本的更新说明。

版本说明 示例

信息结构

产品都包含了哪些内容，层次结构怎么样，它们是如何组织起来的。有了信息结构，项目成员可以直观快速的知会这些信息，特别是刚接触时。

信息结构 示例

流程图

包含业务流程、任务流程。业务流程是业务逻辑，包括前后台逻辑、数据走向等，而任务流程则是用户的操作、页面反馈等更具象化。

流程图 示例

有些还包含页面流程，基于任务流程，描述用户怎么从一个页面跳到另一个页面的逻辑，这样就能清晰的理解页面之间的联系。

页面流程图 示例（来自网络）

交互说明

让你的线框“动”起来。有些朋友喜欢用动态效果来代替说明，对于演示来说是必须的，但对于传递信息来说，则有诸多不便。且不说做动效需要的时间成本，浏览原型的人需要一个个操作才能看到全部效果，说不定还有疏忽遗漏的地方。图文并茂的交互说明能让项目成员快速清晰的扫描全部信息，某些不太好描述的动效，则可以采用交互说明＋动效的方式表达。

交互说明 示例

另外，全局的交互说明记得要提炼出来(代码重用性^_^)，如统一的页面切换方式、统一的手势、弹层模态等。

全局交互说明 示例