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

　　随着互联网节奏越来越快，传统的需求文档已经比较难适应市场的脚步，特别对于要求敏捷的团队来说，冗余而细致入微的需求文档已经成为包袱（这么长个文档领导也不会看呀）。目前大多数团队更喜爱直接使用原型来代替需求文档，然而所谓的原型可不只是画画线框图哟。
　　首页，原型的使用者包括产品、UI、研发、测试等（商务呀，上级呀）。这么多人参考原型来工作，压力不小哦，一旦表达不清，出现歧义，研发的结果的就会教会我们什么叫“偏差”，不仅可能会背离产品方向，还会影响节奏和效率。所以该有的还是还有，高保真低保真什么的事情况而定。
　　变更日志
　　原型不可能一步到位，相信大家深有体会，所以每次更改后再给项目成员时，别人不知道你改了哪些地方，这是件很头疼的事。这种情况下，更新日志就显得尤为重要了，大家一看日志就知道你改了哪些，直接锁定目标，效率大大的提升。
　　更新日志示例
　　版本说明
　　同上，只不过是每个迭代版本的更新说明。
　　版本说明示例
　　信息结构
　　产品都包含了哪些内容，层次结构怎么样，它们是如何组织起来的。有了信息结构，项目成员可以直观快速的知会这些信息，特别是刚接触时。
　　信息结构示例
　　流程图
　　包含业务流程、任务流程。业务流程是业务逻辑，包括前后台逻辑、数据走向等，而任务流程则是用户的操作、页面反馈等更具象化。
　　流程图示例
　　有些还包含页面流程，基于任务流程，描述用户怎么从一个页面跳到另一个页面的逻辑，这样就能清晰的理解页面之间的联系。
　　页面流程图示例（来自网络）
　　交互说明
　　让你的线框“动”起来。有些朋友喜欢用动态效果来代替说明，对于演示来说是必须的，但对于传递信息来说，则有诸多不便。且不说做动效需要的时间成本，浏览原型的人需要一个个操作才能看到全部效果，说不定还有疏忽遗漏的地方。图文并茂的交互说明能让项目成员快速清晰的扫描全部信息，某些不太好描述的动效，则可以采用交互说明动效的方式表达。
　　交互说明示例
　　另外，全局的交互说明记得要提炼出来（代码重用性），如统一的页面切换方式、统一的手势、弹层模态等。
　　全局交互说明示例
　　其中“交互说明”部分是最直观和细节的，也是研发会仔细琢磨的部分（也是大部分会跳过前面步骤直接进行画图（交互）的部分），所有需要我们考虑清楚，表达清楚。因为按钮不止一个状态、文本域是有限制的、用户操作不是完全可控的
　　状态
　　默认状态：主要是默认（初始化）显示的数据、文字、选项等。任何一个页面、表单、按钮、文本域等都会有默认状态，这是需要我们注明的，否则研发人员难以准确单纯的从原型上判断出元素背后的逻辑。
　　常见状态：页面上一个模块，它可能会有多种状态，比如APP客户端个人中心一般会有未登录状态、已登录状态，这些是需要我们展示清楚的，如果我们少写了状态，研发人员就会纳闷xxx（登录）之后（前）是什么样的呢？
　　异常状态：非正常情况下的样式、文案、说明等，比如搜索无结果、加载失败、网络（定位）未开启等等。异常状态一般较容易被遗漏，最终导致产品体验较差。毕竟用户不是都在办公室里把所有开关（权限）都打开才使用我们产品的。
　　限制
　　范围：数据的取值范围。比如轮播图的个数、滑块的范围刻度、文本域的长度等等
　　极限值：数据的显示限制。比如最多应该显示多少字数，超出时如何显示、每次请求数据的条数，不足时怎么办超出时怎么办等等
　　操作
　　常见操作：正常操作时得到的反馈状态。比如一个按钮经过不同操作会出现不同状态，鼠标进入、按下、点击后。
　　特殊操作：一些极端情况下的操作，出现概率较小，还是要想好应对措施。比如我们在买保险时会有常用被保险人，选中某个其详细信息会出现在申请表单中，如果在这时候修改了被选中人的信息，修改后的人，算被选中人还是新的被保险人呢？提交表单后是覆盖愿被选中人信息还是新增一个被保险人呢？
　　面对可能出现复杂的情况，要和研发人员一起探讨解决办法，并把交互说明写清楚。有时候研发人员想到的办法可能更简单实用。
　　误操作：用户操作错误的情况。这种情况采取的措施一般是提前预防错误、适当提示用户、系统自动纠错。比如库存接近0时，选择数量时就会提醒用户库存5件，如果用户输入超出5，则自动更正为5。
　　手势操作：使用移动端产品时的操作方式。比如滑动、放大、摇晃等。
　　反馈
　　提示：用户操作后，系统反馈给用户的提示。
　　跳转：点击某个链接按钮后，页面跳转到的地方。网页也表明是原页面刷新还是新标签页打开，移动端要表明转场方式（默认为全局）。
　　动画：用户操作后，系统通过动画的方式反馈给用户。动画给人的感觉比较友好，趣味性较强，避免过于夸张。比如Clear用炫酷的手势和动画赢得了用户的青睐。
　　除静态页面外，还需要考虑各种动态情况；除正常情况外，还需要考虑特殊和错误情况。