任务分解 - UCD大社区

如何写一个优秀的Use Case(1)

Kimi Huang — 2009-02-26 15:00:01

做一个互联网产品设计者，编写Use Case是日常工作的一个重要内容，也是重要的技巧。
回想起来自己当年从市场部转入到产品部，编写UC也是从0开始，最初就是拿着别人写的东西，然后按照自己的思路去设计新产品。刚好今天因为工作的关系，又再跟同事说如何写好UC，顺便这里总结一下。
先发一个UC的常用模板：
————————–
用例名称
最新更新日期：

负责人：

用例描述：

用户界面设计：

用例场景：

用户：
前置条件：
主流程：
后置条件：
扩展流程：
输入项详列：
输出项详列：

关联ＵＣ

补充规约：
遗留问题和可能的解决方案：

————————–

作为产品设计师，开始做一个新产品设计，一开始的时候，通常是在脑子里面的一堆想法，idea或者是跟需求方讨论出来的一些业务规则等等，最终要变成可以实施的项目，需要产品设计师去梳理，规范化需求，并最终形成需求文档，UC是其中最典型的文档产出物了。

我的建议是：

原则上流程图，特别是业务流程图是最先开始要拿出来的，在流程图中要确保各个业务流程是完整的，而且是效率最高的。这个需要比较多时间的讨论和细化。
将业务流程拆分成为一些典型的用户交互模块。比如：用户管理模款、帐户管理模块等
将每一个模块划分成为典型的用例组合，比如：用户注册、用户信息修改等等。

所以在具体开始写UC的时候，我的建议是：

不要一个UC写完整了再写一个，建议是先通盘写出所有UC的名称（其实名称一定程度上已经定义好了UC的主要工作目标了，比如：用户注册、注册用户信息修改、帐户信息检索等）。等于是写文章的一个提纲，主要的章节都有了。然后再看一遍，对照自己脑子里面的业务流程，看看是否有遗漏的。
写完成UC的描述，我的常用格式是：通过本UC….，比如“通过本UC，用户可以完成支付宝用户的注册。” UC 描述基本上已经明确定义了该UC的范围，大小。在往下写之前，对该UC应该完成的主要功能，以及会遇到的所有分支、输入输出应该有明确的定义。UC的撰写过程只是将上述的内容进行细化和规范化，变成其他人可以阅读使用的东西。特别提醒一点：UC是给别人看的，而不是你自己看的。
下面说说正式写UC正文的时候，我个人觉得特别要注意的地方：
1. 正确的定义UC的用户和前置条件，将会有效的改善UC的流程复杂性。比如：淘宝要做一个专门为淘宝卖家准备的产品。淘宝卖家第一次进入该产品，需要确认一个服务条款。怎么定义用户和前置条件？常见的会有：
  1. 用户已经登录
  2. 用户为淘宝卖家
  3. 用户尚未确认最新版本的服务条款
2. 根据上面的业务是为淘宝卖家做准备而言，上面的用户定义貌似没有问题，但是在实际产品设计中中会遇到一个问题：怎么判断用户是淘宝卖家？用什么条件？看，麻烦来了，所以，我的建议是，把上面的第二条去掉。会有问题吗？当然具体还是要看业务，我只是举例子，说：用户的定义将很大程度上影响流程的复杂性。
主流程一定是你希望的流程，你认为用户最顺利操作你的产品的流程，那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂，里面加入无数的判断，就是因为这一点上没有明确。我自己的感觉是，往往一个UC，主流程可能很短，而分支流程会比主流程多，而且复杂。

Kimi注：未完，待续

相关话题：任务分解源地址：http://www.kimihome.net/blog/?p=701

老郭采购记

白鸦 — 2008-07-26 22:12:10

（这是模拟某个用户使用某个电子商务网站的情景。）

老郭原名郭仲详，今年42岁。大专学历，大学期间曾是学校足球队主力，但以多年不踢。
现为山东二建集团某分公司的采购部主任，从事建筑行业多年，对市场行情较为熟悉，处事精明、为人事故。
老婆为某大学副教授，有一独子上初中三年级，很顽皮经常逃课。当初为了帮助儿子的学习老郭给家里买了一台电脑，还接入了ADSL宽带，谁知道现在儿子现在经常玩网络游戏不顾学习。
老郭兄弟二人，父母均为退休工人，家庭殷实。父母与弟弟、弟媳住在一起，弟弟在某互联网公司任网站构架师，34岁。
加上秘书和一个文员，老郭的办公室是三人公用。办公室有两台公司给配备的电脑，宽带接入。
老郭对计算机和网络都不是很熟练，有时会上网看看国际新闻和足球新闻。偶尔会用电脑打一些简单的文件，打字也很生疏。
老郭没有接触过电子商务，没有任何网上购物的经历。

老郭的主要工作是负责分公司所有建筑建材的采购，平时采购交易都很麻烦，经常出差在外。
老郭经常听弟弟说现在的电子商务已经很成熟了，通过网上交易可很大程度的提到效率，很多大集团公司的采购都是在网上进行的。
最近儿子快要中考，需要在家帮助辅导功课没有太多时间总是出差。老郭决定学学怎么通过网络做采购，他想改进自己的工作状况，也想减少出差时间在家照看儿子。

情景一：
某天，老郭请弟弟下班后过来家里教教自己如何使用网络采购建筑材料。
小郭(老郭弟弟)下班后来到哥哥家里，蹭了顿不错的晚饭后开始教老郭如何上网采购建筑材料。。。

小郭直接打开了xxx.com，并让哥哥一定要记住这个网址。
老郭说”我最近要采购一批’复合管’你就帮我找找这个吧’”，”没问题”小郭爽快答应。

进入网站后小郭很快发现了顶部的”我要买”导航信息,
在”我要买”的”供应信息分类”里，找到了”建筑、建材”，点击链接进入，
在”建筑、建材”的页面里，小郭很快发现了”管件、管材”，点击链接进入，
在”管件、管材”的页面里，小郭看到了哥哥需要的”复合管”分类，点击链接进入，
进入”复合管”的供应信息页面，小郭让老郭看看有没有需要的信息，
老郭惊喜的发现信息列表的第二条，”"贝根牌”内筋嵌入式衬塑钢管”正式自己过几天要去采购的材料，连牌子和公司都一样… 小郭点击链接进入该信息的详细页面，看到了它的供应商介绍、联系方式、产品说明、详细参数、已经该公司销售的其他材料。

小郭让老郭看了一下商品的图片和介绍，又看了一下这家供应商的”信誉指数”和供应商对应的”论坛”。发现所有信息都非常满意。
老郭让小郭看一下价格，效果点击”查看报价”，提示”需要注册才能查看”。

小郭帮老郭注册(在此只模拟采购任务，注册是另外一个任务)了一个帐号，注册后发现返回了”我的管理页面”。
于是小郭点开了IE浏览器的”返回”项，选择了注册之前的那个名为”"贝根牌”XX网站内筋嵌入式衬塑钢管”的页面。
再次点击”查看报价”，
老郭发现这个价格和自己拿到的价格一样，

老郭让弟弟再去看看还有没有其他同样销售这个产品的厂家，
小郭点击了顶部面包屑导航(”首页 > 信息库 > 建筑、建材 > 管道系统、管件管材 > 管材 > 复合管”)的”复合管”，
在”复合管”的供应信息页面，老郭继续发现了几家同样的供应商，逐个进入对比产品和价格，

一个小时候老郭对比了近20家供应商的产品信息，决定发现了三家的材料都不错，而且价格似乎都比现在和自己接触的那几要好，

这时已经将近晚上11点，小郭帮老郭把这个最满意的供应信息都加入了”商品收藏”，以备老郭明天上班分别和联系再详细了解一下。

情景二：
第二天老郭来到公司，死活想不起来这个昨天弟弟告诉记得的那个网站地址是什么，于是打电话给小郭，
效果告诉了老郭网站地址，并让他再次记下来了用户名和密码，同时吩咐老郭”进去后先在首页的右边登录，登录之后进入”我的管理”可以在那里看到”我的商品收藏”，就能找到昨天咱们发现的那几个供应商了”

老郭按照弟弟的吩咐找到了昨天晚上找到的三个供应商，通过电话和他们做了详细的了解，最后和其中的某个达成意向，下了订单…

情景三：
这天老郭需要再次采购一批”玻璃胶”，可以往并没有结果过这样的供应商，
如是老郭想起了上次采购’复合管’的那个网站，…

情景四：
…67cba246

通过以上这些情景故事，你是否发现了很多设计中的问题？以及流程的问题？是否发现了一些我们还没有满足的用户需求？
比如，老郭在要看”报价”的时候网站提示要注册，注册后却又不能返回要看报价的那个页面，只能通过系统的”返回”..
再比如，效果在查找这个分类的时候走了5级才找到具体的类别，
等等….

相关话题：任务分解情景设计源地址：http://ucdchina.com/blog/?p=118

一个调查系统的任务分解实例

JunChen — 2008-07-26 22:10:25

前些时候做了一个调查系统的小项目，正好可以拿出来和大家分享。为了本文行文方便，略去了一些较复杂的功能需求。

概述

话说某资讯站点编辑常有开展在线调查问卷的需求，而当时用的是开源的 PhpQuestionnaire，他常向我抱怨，说是太复杂了，又难用。好多功能用不到，核心功能又因为有那么多干扰，用起来非常难受。我能体会，所以我拍拍他肩膀道：来，我给你优化一下…

我简单收集和分析了下需求，他作为资讯站点编辑，所要的无非就是创建调查、查看统计（两个目标），调查问卷的问题可分为：单选、多选、开放式三种。调查创建完后，可以使用 JS 在其他页面引用，所以前台界面本文暂不探讨。

当然除了这位编辑，他会将调查系统的使用传授给他的手下，和一些新来的小编。这下我基本把使用者（后台）锁定在两个角色上：王少斌（熟练的编辑）和小杰（新手）。

设计

一开始，需求分析的时候，我先定义和解释了一些名词：调查、问题、问题类型（单选、多选、开放式）、问题选项、关闭（即撤下统计并从当前进行中除去）。这对后期开发、使用是有巨大帮助的。

然后我便设计了一些基本情景（涵盖典型使用情况）：

小杰登录进管理后台，尝试着添加少斌安排下来的新调查“你为什么而工作？”，填写完调查信息和问题（边填写边设计问题和选项）后，浏览了一遍确认无误后保存，并将该项调查的 JS 代码拷贝（然后添加到特定页面）；
少斌登录进管理后台，看看现在进行中的有哪些调查，各有多少人参与了，有一些放了超过一个月参与人数超过一定数量的就把它关闭，然后再看看自己关心“你为什么而工作？”这个调查的统计情况；
少斌发现“你为什么而工作？”这个调查少了一个问题，幸好调查才进行了半天，于是吩咐小杰把问题加上，并提醒加在第三个问题后面；
小杰有点郁闷，不早说…于是便进入后台编辑了调查的问题，新添加了一个单选问题：“你觉得自己的薪水怎么样？”，选项是：“过低”、“一般”、“挺高”、“相当高”四个，并调整一下顺序。

根据以上情景，可以归纳总结出任务（每个任务都有针对特定角色）。然后我列出了以下任务表：

编号	任务	角色
01	创建新的调查	小杰
02	为调查添加问题和选项	小杰
03	通览新创建的调查，并获得 JS 代码	小杰
04	编辑调查	小杰
05	编辑特定调查的问题（增、删、改、排序）	小杰
06	浏览进行中的调查，筛选并关闭一些调查，	少斌
07	查看某个调查的统计情况	少斌
08	浏览已经关闭的调查，重新打开一个调查	少斌

那么，这些任务列出来后怎么办呢？针对每一项任务设计流程。我这里举01、02、03号任务说明，如下图：

待所有任务流程设计完毕后，即可制作可交互的原型了。

相关话题：任务分解源地址：http://ucdchina.com/blog/?p=119

纸面分解任务的一个wap实例

奇遇 — 2008-07-26 22:08:40

本文仅提供纸面分解任务的步骤、做法及纸面表现参考。至于怎么思考等其他的疑问，请参考本次话题的其它文章。

首先，做纸面任务前应该准备：白纸、铅笔（或钢笔、圆珠笔，铅笔更容易修改）、橡皮。

然后，根据需求或场景分解出主要的任务流，此次分解为整体概念，可用纸张绘出屏幕流。

假设如下需求（仅为了说明而假设）：
用户sam在网上有一个网盘，网盘里已经存放有图片，sam用手机以WAP页面的形式登录互联网，并访问我在互联网上存储的图片。sam把喜欢的图片直接下载到手机并设置成屏保；sam和朋友moss都在互联网拥有同样的网盘，并且已加为好友，于是sam直接把一张很可爱的图片共享给moss；由于此图太可爱了，sam还想让luse看，可luse没有网盘，sam只好直接发送到 luse的email里。（wap支持关键字检索。由于手机浏览器不支持富页面，仅支持超链接和基本表单的交互形式，所以交互风格尽量简洁。）

根据需求在纸面上绘出屏幕流如下：

再然后，对屏幕流进一步做详细分解，分解出表现任务流的每一个屏幕的详细构成，并绘出纸面图。如下图所示：

最后，根据整体的屏幕流把每个具体屏幕串起来，就形成了任务分解的结果——最初的产品原型。这里不再提供纸面原型参考，看到此想必大家也知道这个方法大致是怎么回事了，大家也经常用吧？感觉效率挺高。

优点：可以快速的表现出想法、修改方便、成本低。
我们在思考时，这种方法可以跟得上思路，迅速把想法表现出来；任务分解的结果不一定一次就能排版，在与同事的沟通过程中，会做有些调整，这时候就可以根据沟通结构迅速的使用橡皮和铅笔修改，立即可以讨论确认新的想法；成本就不用说了，几张白纸，废弃了就扔了！没有什么太可惜的；时间方面，由于表现想法迅速，不会在画图上浪费太多额外的时间，可见效果不错。这里仅提供此常用方法，仅供参考。当然，大家在工作中选择自己喜欢的方式。

鉴于纸面分解任务的特点，提几个应该注意的建议：
1.保证看的清楚，字体和图可画的比实际稍大些。原因很简单，手指头一般比鼠标指针大，让图更适合于用手指头指指点点。
2.保证屏幕流可以完整表现任务流，多模拟几遍任务场景，尽量避免遗漏。
3.在画具体的表现界面时，把操作场景的各种反馈形式做好备注，以便在演示或讨论时可以很形象的表现。
4.引入角色，多倾听、观察角色的感受，保证分解结果的可用性。

相关话题：任务分解源地址：http://ucdchina.com/blog/?p=112

比“以‘PRD’为唯一依据”更高效的产品设计方法

白鸦 — 2008-07-26 21:45:39

在上期关于信息架构的文章里我匆匆留下”一个网站不超过30个界面”的观点，有不少人表示疑问和不解。

其实这里是我未表述清楚，结合Angela在上期介绍的这个迭代过程：”任务分解(粗略) > 信息架构(主要) > 任务分解(详细) > 信息架构(详细)”。
应该不难明白：事实上我所说的”30个界面”是指”信息架构(主要) “这个阶段时的界面，而非真正最终归纳到一起的网站界面数。因为，我们最好用最少的界面综合总结整个网站的界面(信息)架构。
再咬文嚼字一点来说，我更加愿意把”信息架构(详细)”这个过程称之为”交互原型设计”。(Angela大概也是为了更好的说明这个过程，所以才这么称呼的)

可以简单的认为把”信息架构(详细)”里所有的界面原型完整的总结并链接起来其实是我们在”交互设计”阶段最重要的工作 — 任务分解。

1、任务分解的基本原则和方式

我常给项目组人说：任务分解应该是一个从整体到细节的过程。每个网站就是一个大任务，通常每个网站栏目又是一个分任务，所谓任务分解就是大任务分成小任务，再把小任务分成小小任务，然后小小任务分下去就具体到了每个页面的每个元素和每个过程可能出现的每一个小提示等。
它其实是一个剥树皮的过程，最好的方法是一层层的往下剥，而不是一股脑在某一块死剥到底然后再一股脑的在另一块剥到底..
拿最简单的”注册”任务来说，我们先设计：”填写注册信息 > 发送验证 > 验证注册 > 注册成功”；然后再去设计”填写注册信息时格式错误怎么办？发送验证的时候发送成功的提示是否需要？”等问题；最后会具体到每个页面的每个按钮、每个文字…

也就是说我们最好先做的是把整个过程走一遍然后再一层层的完善细节，而非每遇见一个地方就停下来完全把细节搞透，然后往下走。
和画画一样，我们会先画好构图和透视，然后一层层的往细致里面刻画，而不是先只刻画好鼻子，然后再去刻画嘴巴..

2、如何统计要做那些任务的分解

来源一：功能的信息架构
来源二：具体分析每个角色在使用该产品过程中最常用的功能需求
来源三：商业需要给流程提出来的额外任务

统计有多少可以想到的任务很简单，一般都能迅速统计出N多的任务；综合对比所有统计出来的任务，做一些筛选和提炼，是需要很多经验积累的。
所有的任务只需要覆盖所有的功能点和用户操作点即可。如果你做了两个极相似的任务，如果你的任务A和任务B其中有三四个点是一样的，那其实是在浪费时间和精力。

3、我的实践方法

通常情况下我们任务分解的产出物最好是可以演示操作过程的中保真交互原型；这样的原型起码可以简单的模拟单向的人与机器交互。（所谓的”单向的人与机器交互”指，用户点了”下一步”会出现什么，点了”完成”又出现什么。不包括”用户A发了一个信息，用户B看到後返回一个信息”..）

具体到以往项目中，任务分解产出物我会有三个：每个任务的详细分解流程图、每个流程图的说明文档（基本类似某些公司的PRD，但要比PRD简单很多。一个PRD往往需要30页左右，这里只需要不超过3页）、带链接的动态HTML中保真原型(包括ajax效果)。
工程师拿到这三个产出物以后就可以很好的开展工作了，强于某些只看文档的做法…

每个任务的详细分解流程图（附一个某网站邮件邀请的小流程）

作用：让工程师和产品设计都能很好的具像的详细清楚理解产品的交互流程及逻辑；产品交互设计的每个点都能在此很完整的体现和阐述。

每个流程图的说明文档：
作用是补充说明某些细节的逻辑以及算法，主要为工程师的开发需求说明。
比如，同时上传N个照片，那么他们的排序是什么样的、照片的ID需要如何生成、照片的名字是否需要有中文和长度的限制等等；

带链接的动态HTML中保真原型：（黑白的带链接的网页即可，在此就不拿具体的样例了）
他的作用：可以很好的完整模拟除了和数据库交互之外的几乎所有用户操作过程，让包括工程师和老板在内的所有团队成员可以很巨像的理解产品的每一个具体交互过程，在原型的用户测试中也可以很好的让用户体会到更加真实的产品使用效果。
有人会问：成本是不是太高了？，答：成本很不高！因为前面实际上在信息架构里面已经做了这些页面，在做流程图的过程中也陆续完成并添加了信息架构里面未包含的细致页面，其实这个工作只是把这些界面加上链接而已。

另外，一般在做软件设计的时候我会用PPT来代替HTML页面。PPT一样可以很好的实现简单的人与机器互动演示。而且软件的原型就直接在PPT里面画好，拷贝到PS里面做流程图即可。

还是那句话：设计师有其他角色不具备的能力 — 模拟未来。
交互设计就是讲故事（链接一、链接二），用故事来模拟未来，每个任务的分解就是一段故事。故事的情节设计越符合真正用户的使用情景，设计就越合理。
我常说：任务分解中的情景设计其实是借在用文学创造的方法，更加形象的完成产品设计的目的。但，却又并非是在搞文学创作。

最后，当你阅读完了任务分解的做法，至于本文的标题，我想，没必要再具体做论证了…