用户在网站上的所有行为都可以描述为大大小小的任务流，任务流中的每个节点都有前后逻辑，那么起始节点之前的逻辑是什么？是这个任务流的根源，即可以理解为任务情景。

以目标为导向

在完成页面结构原型设计之后，需要考虑如何把这一个个页面串起来，也就是说，得在用户的角度，模拟使用这个产品，能够做什么？最有可能做什么？经常做什么？

从用户的最终目标反推，逐步细化分解，每个任务为独立的流，逻辑上为一个整体，理想情况是做到任务之间既相互独立，又能分层对应、交叉组合，最好还大小均匀。

比如UCDChina这个Blog，用户发表留言是一个目标，到达日志内容页是前提条件，找日志又可以分解出分别从分类、话题、搜索、存档四个入口进入的任务流，所以我们在任何页面都提供了它们。

以真实为基础

其实刚才在确定任务流的时候，忽略了一点，用户是在什么情景下走这些流程。

哪些用户会有这些情景？于是正好回到以前讨论过的角色设计，假设角色已经定了下来，根据某些特定属性，设计师可以模拟出很多情景，然后再在此情景中进行任务流细化。

比如我要在UCDChina的Blog上发布文章，一种情景是需要新撰写，点击右上角“管理”进入后台，点击“撰写”开始写文章，完成后发布；还有一种是编辑草稿，点击右上角“管理”进入后台，点击“管理”进入列表，再点击我的“某篇草稿”进入编辑状态，完成后发布。

几种流程图

用户 + 功能 = 交互
用户行为 + 功能结构 = 交互流程

个人认为，前两种分别是“用户研究”和“功能架构”的交付物，交互流程图是“交互设计”的交付物。而且，只有交互流程图才是真正对开发人员有帮助的逻辑原型，不举例，有机会再细讨论。

其他

实际项目中，研究竞争对手是必不可少的阶段，在已有流程分解考虑的基础上再次权衡，一方面找到优点，可以借鉴，另一方面找到缺点，争取超越。

另外，网站运营了一段时间，通过技术手段能搜集到用户的行为流，对比分析后，可以反过来验证之前的“情景设计”和“任务分解”，看是否合理和准确。并且，积累的数据将是以后产品改版的重要依据。