标签:
随着互联网节奏越来越快,传统的需求文档已经比较难适应市场的脚步,特别对于要求敏捷的团队来说,冗余而细致入微的需求文档已经成为包袱(这么长个文档领导也不会看呀)。目前大多数团队更喜爱直接使用原型来代替需求文档,然而所谓的原型可不只是画画线框图哟。
首页,原型的使用者包括产品、UI、研发、测试等(商务呀,上级呀)。这么多人参考原型来工作,压力不小哦,一旦表达不清,出现歧义,研发的结果的就会教会我们什么叫“偏差”,不仅可能会背离产品方向,还会影响节奏和效率。所以该有的还是还有,高保真低保真什么的事情况而定。
原型不可能一步到位,相信大家深有体会,所以每次更改后再给项目成员时,别人不知道你改了哪些地方,这是件很头疼的事。这种情况下,更新日志就显得尤为重要了,大家一看日志就知道你改了哪些,直接锁定目标,效率大大的提升。
更新日志 示例
同上,只不过是每个迭代版本的更新说明。
版本说明 示例
产品都包含了哪些内容,层次结构怎么样,它们是如何组织起来的。有了信息结构,项目成员可以直观快速的知会这些信息,特别是刚接触时。
信息结构 示例
包含业务流程、任务流程。业务流程是业务逻辑,包括前后台逻辑、数据走向等,而任务流程则是用户的操作、页面反馈等更具象化。
流程图 示例
有些还包含页面流程,基于任务流程,描述用户怎么从一个页面跳到另一个页面的逻辑,这样就能清晰的理解页面之间的联系。
页面流程图 示例(来自网络)
让你的线框“动”起来。有些朋友喜欢用动态效果来代替说明,对于演示来说是必须的,但对于传递信息来说,则有诸多不便。且不说做动效需要的时间成本,浏览原型的人需要一个个操作才能看到全部效果,说不定还有疏忽遗漏的地方。图文并茂的交互说明能让项目成员快速清晰的扫描全部信息,某些不太好描述的动效,则可以采用交互说明+动效的方式表达。
交互说明 示例
另外,全局的交互说明记得要提炼出来(代码重用性^_^),如统一的页面切换方式、统一的手势、弹层模态等。
全局交互说明 示例
标签:
原文地址:http://www.cnblogs.com/data2value/p/5282096.html