交付物 - UCD大社区

绘制交互流程图

晓生 — 2011-02-18 00:04:17

学习产品设计初期肯定会遇到两个问题：第一，如何考虑更全面；第二，如何绘制交互流程图。开始产品设计前先要考虑所有可能性，如何才能以线性流程图的方法组织所需的设计元素。小郑老师的《交互设计表格》中已经介绍了非常实用的表格穷举法，适合初学者使用。

流程图是产品经理和交互设计都必须掌握的技能，一张流程图可以省去需求文档和交互设计文档的很多文字描述，让技术人员一目了然地明白设计意图，便于组织程序的逻辑顺序。

绘制流程图准从简单的原则，流程图是设计师的产出物，体现设计意图，主要给技术人员和测试人员浏览，至于自己是如何思考不应体现在流程图中。别人也要早点回家被老婆，没有时间关心你如何的细心的考虑，也不关心用户会如何思考和操作的，请直接给他们展示设计的结果。

复杂和纠结留给自己，简单留给别人。对用户是这样，对工作同伴也是如此。

图例1：手机程序开机检查更新的流程图

流程图包括以下图形：

矩形表示交互环节
菱形表示问题判断
箭头表示工作流方向

也有用圆角矩形表示“开始”和“结束”，个人一般不要该图形，因为从上而下的线性流程图。最顶部的图形或者箭头开始的部分是流程图的“开始”，如图例中，开启程序触发了事件，程序开始检查更新；最底部的图形或者箭头终止的部分是流程图的“结束”，如重启程序和不再提示表示本次事件结束，无须以图形区分表示“开始”和“结束”。

流程图容易和操作步骤混淆，比如《交互设计表格》中的登录框操作步骤是：

点击登录，弹出登录框
点击用户名输入框，输入用户名
点击密码输入框，输入密码
点击登录

操作步骤是用户正常情况下完成某项操作所需的操作，而交互流程图（严格意义上叫程序流程图）表达是执行逻辑的路径，通俗地将是当用户点击某个按钮之后，程序执行命令的顺序。更复杂的系统流程图可用于产品架构。

当用户点击的登录框之后，文字描述程序执行的顺序：

检查用户名是否为空。如为空，提醒用户“请您输入用户名”。如果用户名设置要输入手机号码，还要检查手机号码是否是否以13/15/18开头的11位数字。
检查密码是否为空。如为空，提醒用户“请您输入密码”。
检查用户名是否是已用账户。程序提交数据与服务器数据进行比对。如果不是，提醒用户“用户名不正确”。疑问：用户名有误和不存在是如何判断的?
检查密码是否与账户匹配。如错误，提醒用户“密码输入不正确”。

现多数登录框将4和3合并，只提醒“用户名或密码不正确”，可能是告知用户过于准确的信息之后会增加盗号风险。

图例2,wap站验证用户手机号码

[图]初拟互联网产品过程控制流程图

craylin — 2010-12-26 23:40:50

初拟一份控制流程图，给自己之后可能介入项目过程时提供一份指导说明。当然这是这几天围观其他项目时的一些心得汇总，然后根据公司目前的部门和小组配置设计的。可能随着日后了解的深入，思路会有所改变，应该说是一定会改变的。

特此记录。

————————————————————————

流程图和线框图的关系

elya妞 — 2010-06-21 21:33:11

流程图(task flow)是指用图形语言的方式画出用户在使用这个产品的方法和达到具体功能的步骤。通常会把产品的使用流程作为某些任务去完成，用语言描述出想要达到的目的，每一个步骤用一个节点来表示，用线和箭头指示出每一步骤的方向和所要到达的下一个步骤。流程图意在帮助设计师很好的了解产品的功能结构和用户每一步的操作而达到白己的使用日的。

但是流程图也分为两大类：

一类是产品经理或者技术人员在开发过程中使用的逻辑流程图，如图1：

图1

另一类是产品设计或用户体验人员输出的页面流程图，如图2：

图2

页面流程图除了用Photoshop、 Illustrator等绘图工具实现的流程图之外，还可以是用flash、catalyst实现的带交互效果的流程，也可以是用axure、Balsamiq等原型工具实现的页面跳转逻辑流程。

线框图(wireframe)是在逻辑流程图的基础上，用线框的形式细化界面的主要功能和基本布局定位，包括导航、标题、图片，图标，文字内容，按纽，各种控制器和形式等，从而确定各个界面之间具体的交互关系。

可以按照实现形式分成如下几类：

最简单的方式就是用纸和笔简单绘制实现的纸质线框图，如图3

图3

这里提供几个可打印的互联网产品设计线框图模板：

图4

图5

图6

图7

图8

复杂一点的可以用Axure、Balsamiq等原型工具实现HTML线框图，可以参考《使用线框图来简化你的产品设计流程》一文，如图9：

图9

不要忘记用户界面设计版式－－用户界面设计版式对设计用户界面是很有帮助的。版式往往能解决常见问题，合理的版式可以方便用户熟悉界面，尽快阅读应用。因此，要在设计流程的初期阶段就考虑版式，最好在草图（UE）阶段就开始，如图10：

图10

一些基本的页面布局也需要熟悉，或者自己制定一套具有延展性的页面布局标准，如图11：

图11

最后总结一下，流程图分为逻辑流程图和页面流程图，线框图分为纸质线框图和HTML线框图，线框图加上了操作步骤、交互逻辑可以叫做流程线框图。这些在理清产品架构，梳理产品逻辑时至关重要。但是流程图和线框图都是为了辅助产品开发，而不能本末倒置，在流程和原型阶段花费太多的时间和精力，只要能便于沟通，尽量选择最简单最高效的方式。

相关话题：交付物源地址：http://elya.cc/product/600.html

用户体验的交付物

Douis — 2009-02-16 14:23:25

2009年1月27日

译者：UCD翻译小组，Douis
原文地址：http://semanticstudios.com/publications/semantics/000228.php

对用户体验从业者来说，一个令人振奋的时刻到来了。对我们价值认知的提升加上科技融合以及泛媒体趋势的发展，已经给我们的工作创造了一个改变的条件。

作为一名信息架构设计师，我非常喜欢新的挑战，即便它们把我赶出安乐窝。我曾设计过许多公共软件产品和大量的用户界面。我也曾勾画设想过未来的移动搜索。我还曾设计过跨渠道跨应用的用户体验。渐渐地，我发觉自己一直在努力帮助决策者们澄清概念。

因此，我正在重新思考自己的角色，重新定义我的交付物，并且逐渐接受多学科合作的许多全新形式。比如，我成功诱使了Jeffery Callender 成为《Search Patterns》一书的合作者，这本新书（进行中）将探讨如何为探索进行设计以及搜索的未来发展。

我们两人合作，希望能够通过丰富多彩的、引人入胜的故事、地图和插图把搜索赋予生机和活力。这就把我们带回到交付物的话题上来。

思考的工具

有两本书曾鼓舞着我换个角度去思考关于发现、沟通和设计。首先，《Made to Stick》这本书启示我去思考简洁性。它揭示了短句的强大力量，并展示了能改变想法并塑造记忆的神奇的个人故事。

经典语录是简洁的圣杯。使用短小、简单的句子是容易的，任何人都能做到。相反，使用深刻精炼的句子则很难，但却会持久流传。

要解决问题，要先把问题暴露出来。我们的目标是把真相告知人们，但是首先，人们必须意识到他们的确需要这些真相。
这种意识－这种同感来自具体事物而不是某种模式－把我们重新带回德兰修女的名言：”所见为虚则不为；所见为实则为之。”
故事的力量则是双重的：它提供了模拟（行为所需的知识）并提供了灵感（行为的动机）

第二本书《The Back of the Napkin》鼓励了我进行可视化思考。它说明了草图能够帮我们发现并推销创意：

可视化思考意思是利用我们天生的看的能力－既用眼镜去看，也要用思维去看－去发觉那些未必可见的创意，快速直观地完善那些创意，然后采用一种简单易得的方式跟他人分享。

这两本书虽贵为至宝，但它们的概念却意外地难以实施，使事情简化其实使很难的。但是，对我们的项目和著作来说，我们相信那是值得努力的。所以，基于Dan的二手交易原则：”如果可以一览无余，一切都会不同。”Jeff和我开始总结用户体验的相关交付物，并把它们排列出来，这样就可以查找、查看、设想并展示。

交付物

这个列表描述了二十个用户体验交付物，并链接到相关的资源和实例。显然，这些东西不是全部内容，我们还必须考虑到目标、方法和文档之间的关系。而且，对我们许多人而言，交付物是至高无上的的，值得特别注意。

故事。一个用户体验的好故事能够帮助人们发现问题（或机会），鼓励人们采取行动，即使我们离开了也能长久地驻留在用户的记忆中。

商业故事会
 领导力的密语作者Stephen Denning
一些文章作者Dave Snowden
经典语录。高级指导方针以及基于现有架构的体验战略可以把一切都囊括其中。

体验战略作者Jesse James Garrett
启动阶段的高级推销语
 英语经典语录(Wikiquote)
人物角色。用户类型（包括其目标和行为）的描述和介绍，提醒我们”你不是用户”，在设计和开发阶段充当宝贵的罗盘。

角色 (Dey Alexander)
角色并非一份文档作者 Jared Spool
角色 (Wikipedia)
场景。把角色定位在自然语境下，让我们思考系统如何适应真实人物的生活。

什么是场景
场景作者 Shawn Henry
用例与用户场景 (IxDA)
内容清单。对文档和对象进行检查和描述是有效构建和组织的先决条件。该交付物（通常是一份电子表格）是尽职尽责的一个表现。

制作一份内容清单作者 Jeff Veen
为何不可作者Leisa Reichelt
滚动的内容清单作者Lou Rosenfeld
分析。我们通过交互、搜索和导航的数据进行学习。我们通过揭示并图形展示最关键的里程碑、门户、路径和模块进行教授。

Web分析 (Wikipedia)
Web分析与IA 作者Hallie Wilfert
搜索日志分析 (Dey Alexander)
用户问卷。在各种受众的多个用户中询问同样的一些问题，能够保露出现存的缺陷以及共同的需要，并显示出对客户满意度的覆盖程度。

因时制宜作者Christian Rohrer
美国客户满意度索引
 Pew互联网和美国生活项目
概念地图。在概念范畴中，一个良好的地图能帮我们定位，并且通过设立地标、澄清关系、识别方向帮助决策。

餐巾的背面作者 Dan Roam
什么是你的心智模型？ (Indi Young)
Flickr用户模型作者 Bryce Glass
系统地图。系统内部对象及其关系的一个视觉呈现，可以帮助涉众和用户进行理解和查找。是由”现状”变为”未来”的变速器，可使结构性的重新设计具有一个蓝图。

地图－地域关系 (Wikipedia)
伦敦地下地图 (Ask Edward Tufte)
开发分类体系作者 Christian Ricci
任务流。用户如何在系统中移动？我们如何改进其流程？一个象征性的描述就可以照亮需求路线并显示出所选路径的优势。

用户流程 (Google Images)
改进用户任务流作者 Austin Govella
需求路径 (Wikipedia)
线框图。页面和屏幕的草图可以帮我们聚焦于结构、组织、导航和交互，然后才去投入时间关注颜色、字体和图片。

线框图在哪作者 Dan Brown
真实的线框图作者 Stephen Turbek
线框交换卡 (nForm)
故事板。一系列的带有文字描述的草图排列起来就可以讲述一个故事，并按时序画出一幅用户与系统交互的图景。

漫画作者 Rebekah Sedaca
理解漫画作者 Scott McCloud (视频)
泳道图 (nForm)
概念设计。界面设计与合成艺术能唤起一种情绪反映并听过展示一幅产品未来样子的高保真图片来捕获人们的注意力。

概念设计 (Flickr)
概念设计工具作者 Victor Lombardi
投资未来 (Stuart Candy)
原型。从软件和硬件产品的纸上原型到pre-alpha版本，可用的模型能驱动快速的迭代开发并通过展示产品未来的观感促进情感上的一致。

纸上原型作者Shawn Medero
XHTML原型开发作者 Anders Ramsay and Leah Buley
WineM (Technology Sketch)
叙事报告。写作是思考和组织的最好工具。而且要推翻一份展示细节和分析建议的文字报告是很难的。报告可以作为大部分交付物的容器。

风格的元素作者 Strunk & White
战略报告作者Morville & Rosenfeld
商业简报 (Adaptive Path)
演示。作为商业中的国际语，幻灯片（以及视频）最适于讲故事或描绘图画。不过它们也可能无聊的要死，除非你亲自出马、强调要点并慎用项目符号列表。演示也可以作为大多数其他交付物的容器。

PPT的认知风格作者 Edward Tufte
抵御PPT 作者 Don Norman
信息架构峰会报告（PPT）
计划。项目计划、路线图和日程表能通过清晰地划分角色和职责来知道设计和开发活动。

甘特图
 项目管理 (Wikipedia)
最后期限作者Tom DeMarco
需求规格说明。在从设计转到开发的过程中，通常的一个必要元素是描述系统的行为或功能的需求详单。

可用的软件需求规约作者 Brian Krause
无痛功能规约作者 Joel Spolsky
只是个神话？ by Dan Willis
样式指南。一份手册，定义了一组标准的用于改进清晰度和一致性的特性、设计和写作风格。

样式指南导航作者Chauncey Wilson
Web样式指南 (Pennsylvania大学)
Web样式指南作者 Patrick Lynch 和 Sarah Horton
设计模板。一份提供可重用的常见问题解决方案的模板库，能描述最佳实践，鼓励分享和重用，促进一致性。

关于模板作者 Jenifer Tidwell
雅虎设计模板库
 部署一个模板库

组织交付物

当然，编制一份列表仅仅是万里长征第一步。对每一个项目来说，我们都必须努力使之达到最优结合。既然我们的这些交付物没有一个分类系统，那么问下列一些问题可以帮助我们得到它们的大致分类：

听众你必须触及哪些人？
内容要传递什么信息？
语境对话发生在哪里？
过程何时发生？
问题为什么要沟通？

但是，问题不会就此结束。你认为应当更简单还是复杂？追求数量还是质量？我们可以无休止地去组织并描述这些交付物。我们已经启程了，也许你能提供些帮助。你愿意在我们的Flickr收集上增加一些标签吗？

藏宝图

如果你读到了这里，现在可以得到一个回报。那就是大堆的交付物大堆的文字。还有，那就是问题所在：看不到森林怎么找到最好的树？我们只有回到自己习惯的事情上面。所以经常粗制滥造一堆线框图却还没意识到一个故事。所以我们在我们的墙上（还有你的墙上）制作了这幅藏宝图。

祝你好运！记得告诉我们你的发现！

怎样设计好产品的概念模型

兔子 — 2008-08-09 11:31:04

对于交互设计师来说，其工作的输出物主要包括：用户用例功能清单概念模型流程图故事板和产品布局图，其中概念模型是一个充满主观色彩工作，但是概念模型的质量对整个产品的交互设计至键重要，因为概念模型奠定了交互设计的基础和方向。

概念模型的定义：是对真实世界中问题域内的事物的描述，不是对开发产品本身的描述，有意识地忽略事物的某些特征，对产品需要解决的问题进行高度的概括和抽象的产物。

不同的人对相同的一个场景进行观察分析，可能提炼出各自不同的概念模型，所以说这是一个充满主观色彩的一个过程。然而，概念模型的质量对整个产品的交互设计的影响是至关紧要，因为概念模型已经去掉具象的东西，进行了高度的概括，所以可以很快的找到产品的关键点和它们之间的相互关系，从而大大提高表达的效率，也直接影响到后面的流程图的设计。

一个概念模型的实例
也许有些朋友还是不太明白概念模型，我就举一个简单的例子：
我们需要设计开发一个在线商品的网店，那这个交易的一个场景就是网店和客户之间的买卖过程。其相应的概念模型可以这样表示出来：

购买和销售对结算使用虚线是表示在这两个关键点均包含了结算的这个过程

我们还可以把上面的概念模型图进行扩展，可以画出下面的图：

如何找出概念？
1.最好是能够尽量充分地使用细粒度的概念来描述模型，而避免粗略描述。
2.不能简单地因为需求说明中没有明显的要求保留某个概念的信息或是概念中没有属性，就去掉概念，在问题领域中，那些只担当纯行为的概念也是存在的
3.用于寻找概念的“参考名单”

概念类目	举例
物理的或实在的对象	销售点终端、飞机
规格说明、设计或者事物的描述	产品规格说明、航班描述
地点	商店、机场
事务	销售、支付、预定
在线事务处理项	在线销售项
人的角色	出纳员、飞行员
包含其他事物的包容器	商店、银行识别号、飞机
被包含在包容器内的事物	销售商品项、乘客
系统外部的其他计算机系统或机械电子设备	信用卡授权系统、空中交通控制系统
抽象的名词性概念	饥饿的人、恐高症
组织	销售部、对象航线
事件	销售、抢劫、会议、出航、坠机、着陆
过程（通常不用概念来表达，但有时也会用概念来表达过程）	出售一个产品的过程、预定一个座位的过程
规则和策略	退货政策、取消政策
目录	产品目录、零件目录
财政收支、工作情况、合同等的记录	收据、分类帐目、雇佣合同、维护日志
金融工具和服务机构	信用卡、股票
手册、书籍	雇员手册、修理手册

概念模型的建模过程：
1.运用概念目录列表或名词性短语找出问题领域中的后选概念
2.绘制概念到概念模型图中
3.为概念添加关联关系
4.为概念添加属性

概念模型设计
概念模型不依赖于具体的计算机系统，他是纯粹反映信息需求的概念结构。
建模是在需求分析结果的基础上展开，常常要对数据进行抽象处理。常用的数据抽象方法是‘聚集’和‘概括’。
ER方法是设计概念模型时常用的方法。用设计好的ER图再附以相应的说明书可作为阶段成果

概念模型设计可分三步完成
   (1) 设计局部概念模型
       ① 确定局部概念模型的范围
       ② 定义实体
       ③ 定义联系
       ④ 确定属性
       ⑤ 逐一画出所有的局部ER图，并附以相应的说明文件

   (2) 设计全局概念模型,建立全局ER图的步骤如下：
       ① 确定公共实体类型
       ② 合并局部ER图
       ③ 消除不一致因素
       ④ 优化全局ER图
       ⑤ 画出全局ER图，并附以相应的说明文件。

   (3) 概念模型的评审,概念模型的评审分两部分进行：
       第一部分是用户评审。
       第二部分是开发人员评审。

相关话题：交付物源地址：http://www.uespace.com/post/192.html

画Web流程图的一点心得

丁宇 — 2008-10-03 09:04:12

一个哥们在MSN上告诉我，他们公司的交互设计师只产出流程图，并问我用什么标准评价流程图的好坏。他的说法把我彻底震了－这分工也太细了吧！也不知道该说他们那里这样是好还是不好。

不过仔细想来，我倒的确没有仔细考虑过流程图的好坏，正好借此机会自我总结一下。

1、各司其职的形状

在我的流程图中，适用于不同目的和功能的形状都有各自确定的规范。到目前为止，我一共定义了以下一些形状：

（1）开始和结束

作为整张流程图的头和尾，必须标清楚到底具体指哪个页面，以免日后出现歧义。

（2）网页

如你所见，网页的形状是一个带有漂亮的淡蓝色过渡效果的长方形，它的边框为深蓝色，中间写明了这个网页的用途，括号中的数字代表这个形状所对应的 demo文件的名称（比如这里是2.html），我有时会把流程图输出为网页的形式，并把每个网页形状和它所对应的demo文件链接起来，这样查看起来非常方便。对OmniGraffle来说这是小菜一碟，如果你被迫用Visio，嗯……

另外，所有从形状出来的线条，都具有和此形状边框一样的颜色。这样的做法不仅看起来漂亮，在复杂的流程图中还能轻易地标明各形状的关系。我没有见过类似的做法，所以这是由我首创也说不定，呵。

（3）后台判断

很常见的一个形状。我在用法上有一点和其他人的不同在于，我几乎总是让‘是’的分支往下流动，让‘否’的分支向右流动。因为流程图一般都是从上向下、从左到右绘制的，遵循上述规则一方面可以让绘制者不用为选择方向操心，另一方面也方便了读者阅读。

（4）表单错误页

既然有表单，当然会有错误信息。其实这个信息很重要，用户出错时惶恐不安，就靠着错误提示来解决问题了。你不在流程图里说什么时候显示错误页、不在demo里提供错误页，有些程序员会直接在网页上写个“错误，请检查”，所以UI设计师一定要对这个东西重视起来。

但一般来说也没必要把每种错误都在流程图中表示出来，因为含有两个文本框的表单就有三种出错情况了，多了就更不用说了。所以我都是把错误页变为表单的附属页，比如表单页的编号为2，那么此表单错误页的编号就从2.1开始排下去，每种错误放到一个附属页中，这样程序员在拿到demo时也能搞清楚什么意思。

结合网页和表单的形状，一个表单验证的流程图就是这样的：

（5）后台动作

并非所有后台动作都绘入流程图中（否则流程图就会变成庞然大物了），只有需要特别强调的后台动作（和用户体验直接相关的）才使用此形状。

（6）多重分支

多重分支指的是几种并列的情况，每种情况都有发生的可能，发生哪种取决于分支起始处的判断结果。

（7）对话框

有时候一些操作可以利用对话框来完成，这些对话框由js生成，显示在父界面之上。

（8）注释

这个形状（比如页面）详细的内容，或者需要解释的业务逻辑，甚至用户此处的情况等，我都会放到注释中，这样既降低沟通成本，又可作为备忘。

（9）跳转点

在一个复杂的流程图中，往往出现跳转到另外一个远处结点的情况，此时如果直接用线连过去，未免使得流程图显得凌乱，用一个跳转点就解决问题了。在点内标明跳转到的形状的编号，画起来容易，看起来也清楚。

此外，也可以利用跳转点来分割篇幅巨大的流程图，Yahoo!就这么用。

（10）子流程

分割篇幅巨大的流程图，更好的办法是用子流程。

要注意的是，如果你在流程图中使用了子流程这一形状，一定记得同时附上子流程图，以消除影响项目质量的不确定性因素。另外，在子流程图中也可以标明其所属关系。

（11）流程块

可以用流程块将整张流程图分隔为几个部分，并为每个部分单独命名（比如“流程块1”等）。这样做的目的在于从视觉上使复杂的流程图变得更为清晰，在沟通时也方便。

2、图例和流程图信息

在团队合作中，图例是必须的，否则没人知道你画出来的东西到底是什么。即使流程图只给自己看，也最好养成标注图例的好习惯。其实这道理有点类似程序中的注释。

流程图信息也是必备的。其内容至少应包括作者、时间、流程图名称和版本（如下图）。这一方面可以让读者（其他同事）在有问题时能够方便地找到作者你，也起到了meta的作用。

3、绘制流程图的工具

Mac下首选OmniGraffle，Windows下除了Visio，似乎没有更好的选择（虽然Visio已经很难用了）。

4、评价流程图的好坏

我觉得一个好的流程图至少应做到以下几点：

密切地迎合了用户的心理状态、如实的反映了用户的操作习惯。流程图是要指导UI设计的，是UI设计的参照物，如果流程图本身无法正确描绘出用户的情况的话，UI十有八九会出问题；
覆盖了各种可能的情况和细节。这非常重要。任何在先期不确定的因素，都会在项目中成为随时引爆的地雷，都会直接降低最终上线的UI质量。此种情况真是屡见不鲜。但同时这条又很难做到，因为它不仅要求设计师熟悉用户，也要设计师充分知晓产品的商业逻辑，还要了解系统的运作机制，落下以上任何一个方面，都会在流程图中留下死角。这个问题我不知道有没有更好的解决方案，不过与PD和系分反复沟通是个行之有效的方法；
考虑到系统的设计和承受能力。系统的运作机制和承受能力必须在绘制流程图过程中考虑进去，以免出现流程图被开发人员枪毙的情况。我的习惯是，在绘制流程图时和系统分析师频繁沟通和交流，确保每一个环节都是可行的；
确保别人看得懂你的流程图。别人现在看不懂，你自己以后也一样看不懂。为了降低沟通成本，把流程图画清楚吧。

5、其它

（1）想办法把流程图绘制得漂亮些。谁不喜欢漂亮的东西呢？

这是我做过的一些流程图，当然文字全部模糊掉了（放图之前犹豫了好长时间－这样做不知是否有损我的职业道德。我特意请教了Fenng，他觉得没事。如果谁觉得有问题请直言不讳地告诉我）。

（2）如果你在公司里不是一锤定音式的人物的话，你就需要对你的文档进行版本管理。流程图也不例外，什么时间发布的什么版本，都要清楚地标出来，“ 最新”是个用不得的词。

我就说这么多了，抛砖引玉而已，蓉儿等人看你们的了！

噢对了，问个事儿：大家有没有觉得我每次写的文章都太长了？

[图]一些网站交互的手绘稿

xiaoxiao — 2008-10-09 11:57:25

越来越多的设计师开始使用Axure设计Web交互类站点，Axure在某些地方有着天然的优势，但我还是推荐手绘稿来进行前期设计，也就是纸原型。理由很简单，速度快、效率高、容易改。

无意在Flickr上发现了Soxiam的一些手绘稿的照片，很有感觉，发上来看看。

这里是Soxiam以手绘稿为主的相册：http://www.flickr.com/photos/soxiam/sets/224126/

交付物不是越多越好

千鸟 — 2008-12-25 12:59:08

——读《设计沟通十器》

这本书在07年理论满天飞的大环境下是一支独秀，起码看起来更像在做事。书主题讲设计沟通，价值在于针对不同流程、方法交付物提出了成体系里的实践结论。上月的阅读推荐书单中，我对《Communicating Design》的定义是贯穿Structure, Skeleton, Surface三层的指导。

看得出作者对每种方法都有较深入的研究，作为一本总结性的实践大全，指导性自然很强。但我想如此严谨的交付应该是作者多年的工作总结，不太可能在一两个项目中完整施展出来，搞不好还会误导读者。结合瀑布递推、敏捷迭代两种流程写写不同观点。

文档先行

其实就是瀑布递推的流程应用，但本书所涉及的交付物知识结构，我认为定义有小问题。上月在操作参考中也顺便提到本书某些缺陷，同时给出了蓝图、文档、原型的交付物组织参考。又快速浏览了一遍，仔细阐述几个点：

其一通用性不够强，没有明确轻重缓急，什么是必须的？什么是次要的？什么是加分的？成功产品不一定都经过了专业方法的洗礼，或者说只是一笔带过。

其二关系模糊，所定义的用户需求文档、策略文档、设计文档组织有点混乱。比如第三章可用性测试计划、第四章可用性报告，出现在第一部分用户需求文档中，我开始怀疑现实了。

其三缺乏前瞻性，我坚信xhtml原型的发展空间、美好前景，但也归属于文档显然不合适。还是曾经那个观点：用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。

文档滞后

其实就是敏捷迭代的流程应用，首先应该强调，敏捷迭代不是反对文档，而是滞后。最重要的，设计师必须对传统文档应用了如指掌之后，才可能在敏捷中把控好节奏、有所失必有所得。本书没有提，或者说作者认为不与主题相关。

著名的Flickr概念模型，好多同行看了叹为观止，第117页也有引用例子。但据我所知，这幅图是在产品正式运营两年之后所画，阶段性总结而已。或者在专业角度，本书更适合做咨询。

设计师积累到一定程度，必然会形成自己的交付物标准，并且在实践中不断优化迭代。但如果是团队，个人标准还远远不够，得需要团队标准来规范。本书就是作者经过积累、总结，提供给同行们的一份参考答案。也许我们一时半会无法领会其中的内涵，但不管从理论、还是实践入手，这本书的价值都不可磨灭。

浅谈产品设计的表达格式

奇遇 — 2008-04-13 23:04:21

很多时候，领导要求你高效的工作，且有些领导认为：语言传达可以使沟通更高效，没有必要花费时间去做文档。我只赞同“使沟通更高效”的想法，当然不能只为了做文档而做文档，但是沟通需要一个平台，我们需要基于某一个“东西”进行沟通。由于语言表达的极限、理解的差异化，对于同一个“东西”的讲解，不同的人在脑海中会形成不同的“样子”。

在软件产品设计中，我们通常会针对“用户定位、产品定位、发展方向（需要考虑可扩展性)、交互方式、视觉风格”等基本问题进行沟通，或者要把想法和成果让领导给予确认。在实际操作中，我们已经把各项工作分成了很多层面，这里我们要谈谈产品设计在不同层面表现的格式，这里根据自己的经验分成四个层面，也就是下面的四个大标题。

一、产品的概念层面

1.行业分析，同类产品对比。如果我们想做某一个行业的产品，一般我们会对这个行业先做个分析，会考“虑成本最低优势、可替代性、差异化、潜在新产品威胁”等战略问题，同时考虑自己的产品定位，一般会先做一个同行业产品对比分析文档，建议包括以下内容：

1）产品特点（长处）、价格对比；2）功能对比；3）界面及点评；4）定位建议。

要表达上面提到的四点，我想做个word文档就搞定了，前两点用表格表达，后两点用文字描述即可。举个功能对比格式的例图：

图1-功能对比表格

2.用户定位

1）用户分类；2）角色设计；3）场景描述

这部分的内容都是比较专业的，结构也都是文字描述形式，建议大家参考《赢在用户》这本书，很系统讲了用户研究这块。

3.产品名称及功能

1）产品名称及视觉识别系统描述

拿土豆网举例吧，当然，我只是随便举例，并未实际分析，实际要比我的举例复杂的多，也不去考证是否准确。

产品名称：土豆网。

视觉识别：土豆面具（标志）。

2）产品规格表，即产品功能详细列表。

图2-产品规格表示例

二、产品的结构层面

这个层面要做的事情，通俗的说就是：“如何用界面组织功能”，“界面之间的关系是怎样的 ”；分解开来就是：“功能组织”、界面组织、逻辑流程图、用户使用流程图（界面流程图）。

1.用卡片的形式给功能分类，并表达清晰功能的从属关系。

图3-卡片式功能结构图

2.逻辑流程图

图4-E-R流程图，这部分应该有程序设计去做才好，但有时候产品设计师也要理清楚这些。

3.界面流程图

图5-屏幕流，每个框代表一个界面，当然，你可以把每个框换成实际的界面，看个人喜好了。

4.界面原型图，如果想表达更清晰一些，可以画成界面原型流程图或者干脆做出界面原型。

图6-无风格的线框图，可以辅助说明信息。

三、产品的交互细节

这个问题曾令很多交互设计师头疼，总是不能很细致准确的传达界面交互，我们试图画出很准确的交互图，但语言表述的准确性和细致性仍然不尽满意，这里介绍使用伪代码描述交互，因为伪代码逻辑近似开发逻辑，便于准确传达给程序工程师，保证设计细节的控制。但要设计师去设计伪代码，确实需要点时间去锻炼一下，此外还要形成一套易读的伪代码标准，便于大家在阅读伪代码时，保证描述的一致性。

1.用户交互的表现方法

图7-交互图，构成：用户、界面、操作条件及路线。

2.伪代码的表现方法

1）定义界面元素，形成一套界面元素库，可以做成一个文档标准，并整理出各个界面元素的伪代码写法，使用时可直接调用即可。

定义界面元素有很多现成的参考，比如Vista的UX Guide，在微软的官方网站都能找的到。举个定义Vista普通按钮的例子：

图8-图表说明了是 Command Buttons，并用表格的形式说明了属性。

2）举一个使用伪代码书写的简单例子

图9-用伪代码的形式描述一个按钮。

其实没有啥，正常的描述，只不过用近似代码的形式描述出来，相必做程序设计的哥们都不陌生。

四、产品的视觉设计层面

在软件产品中，视觉部分通常被称之为GUI，在这个层面所要表达的格式没什么好说的，就是设计图。但很多时候做出所有界面的图显然是不明智之举，其实界面可以归纳起来，即把所有界面归类，然后每类做出一张图即可；界面中的细节变化怎么办？好办！把界面布局标注出尺寸规格，并作为标准传达，剩下的事情是，只要把细节元素、交互视觉做出图来就行了。至于界面的布局和组织，前面的第二个层面已经很清楚了。

现在拿微软和苹果的系统UI指南举几个例子：

图10-苹果的尺寸标注图

图11-Vista的状态标注图

小结：

一般视觉设计都有视觉设计师（或者称GUI设计师）来完成，而概念设计、结构设计、交互细节是有产品设计师（或交互设计师）来完成。可能有人要问我，那么产品经理做啥呢？产品经理是个管理职务，这里不做赘述，可参考在《协作，而非争权》中的描述。本篇根据实战把产品设计分成了四个清晰的层面，并对各层面要产出的文档格式做了系统的描述，当然不可能很详尽，但在每个层面都提供了一个简单的小例子。如果你对这方面有过很多实践，希望这里能提供一些借鉴，日后有时间会分享每一个层面的设计细节。同时，有更好的表达格式，环境分享、补充。

相关话题：交付物源地址：http://www.ui123.com/blog/?p=90

比“以‘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里面做流程图即可。

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

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

初探用户体验架构 2

心弦 — 2008-01-02 22:34:12

第一次来？先看看“有感于与三通的对话”和“初探用户体验架构（“有感于与三通的对话”续篇）”，否则可能看完了都不知道我到底要说啥。看过前两篇的请继续往下读，接着批判。

确立设计流程和各阶段交付物

如果说界面设计的哲学还能凭感觉胡说几句的话，这个设计流程和交付物可绝对是马虎不来的，因为其质量的高低将直接影响最终的设计质量。

一般来说，采用UCD的流程大体上遵循“研究－设计－测试－实现”这样一个流程，所不同的只在于，1）是使用类似开发中“瀑布”还是“敏捷”的方法；2）每个阶段的产出物及其衡量标准。对于第一个不同，似乎传统行业倾向于使用“瀑布模型”，而互联网公司更倾向于“敏捷”。第二个不同则大有文章可作－相对于设计流程，对各阶段交付物质量的把控显然更为重要，因为流程本身最重要的作用，就是在一定效率下保证合格交付物的产出。那么，前文一再谈到的规范，就正是作用于这些交付物。合理的规范不仅可以极大的提高工作效率，更重要的意义在于保证交付物具有一定的质量。

为了避免讨论太空洞，下面我将以一直在参与的一款产品（以下简称“A产品”）为例，说说我在推广的一些规范（值得一提的是，由于可能涉及信息保密问题，我只能大致讲下概括）：

“A产品”UI编码规范 v0.5

简介：总结、归纳和整理“A产品”在Velocity模板、XHTML、CSS和Javascript等方面的编码规范。
组成部分：《“A产品”UI编码规范 v0.5》、“‘A产品’CSS文档库”和“‘A产品’Javascript文档库”。
价值及意义：提升UE/UI、开发和测试的工作效率，降低工作成本，通过统一化的代码控制质量。

“A产品”视觉设计规范 v0.1

简介：总结、归纳和整理“A产品”在视觉上所应具有的风格。
组成部分：《“A产品”视觉设计规范 v0.1》。
价值及意义：提升UE/UI团队内部的工作效率，降低沟通成本，探索产品自身的设计风格。以后新设计师加入项目组时，此文档将起到培训的作用。

“A产品”信息提示管理规范 v0.1

简介：对“A产品”相关页面的信息提示进行统一管理和存储……
组成部分：《“A产品”信息提示管理规范 v0.1》。
价值及意义：避免出现遗漏信息提示、信息提示中文案不好的问题，减少工作成本。

“A产品”Demo版本控制方法 v0.2

简介：在多人协作时，通过这个方法来管理每个人的交付物，做到在trunk上设计和开发，在milestones上演示……
组成部分：《“A产品”Demo版本控制方法 v0.2》。
价值及意义：提高多人协作的工作效率，降低项目组成员间的沟通成本。

“A产品”UI控件使用规范 v0.1

简介：统一界面的布局和控件的使用，给用户统一的体验……

“A产品”文案写作规范 v0.1

简介：统一文案的文风及措辞，减少歧义，用简洁、通俗且专业的语言给用户引导和帮助。

规范看起来很多？其实在一个拥有复杂业务逻辑、许多不同部门的人协作的项目中，一些明确清晰的文档只会减少沟通成本。

未完待续，白鸦别急，呵呵：）

我们的设计流程

承志 — 2007-08-13 22:28:49

淘宝面试的最后一个环节，是请应聘者向面试官提问，使面试官有机会解答应聘者对公司、团队以及工作等等方面的疑问。在我面试过的设计师当中，大约有三分之一会问我：“淘宝的设计流程是怎么样的？”我不是很了解问这个问题的人为什么会有如此高的比例。也许这是一个“安全”的问题，不会对面试有什么危害；也许目前设计师在工作中普遍碰到“流程”问题或“没有流程”的问题；也许这个话题涉及各家公司的“机密”，确实无从找到相关的资料。

总而言之，虽然来面试淘宝的设计师人数有限，但我斗胆假设：目前国内所有网页设计师中的三分之一想了解更多关于“设计流程”方面的知识，而我们也不认为这是什么“机密”的话题(我了解的各公司设计过程都八九不离十，名称不同，本质上是一样的)。所以，就在此简单介绍一下淘宝UED的设计流程，期望对这三分之一的设计师有所帮助。

Step 1：原型（Prototype）

设计的第一个阶段，我们称之为原型设计，主要是设计产品的功能、用户流程、信息架构、交互细节、页面元素等等。如果你觉得听上去这些概念都比较悬的话，我就用大白话来说：原型设计，就是完全不管产品长得好不好看，只把它要做的事情和怎么做这些事情想清楚，把它怎么和用户交互想清楚，而且把所有这些都画出来，让人可以直观地看到。

至于怎么画出来，那就随你了。用纸笔画，用白板水笔画，用Photoshop画，用Visio画，或者像我们一样用Axure画，都可以。只要把上面提到的这些都事无巨细地表达出来。

在原型的交付物（Delivery，也就是某个阶段的产出物）中，最重要也最常见的就是线框图（Wire Frame），这玩意儿不用多解释了，看下面这张图就明白：

在画线框图的时候，要把握好细节的刻画程度。有些东西只要画个框就行了，而有些东西需要把文案都设计好。以免你的老板或是需求方揪住角落里的广告banner该有多大这种问题与你纠缠不休，而忽视了最重要的页面主体部分。

此外，还要牢记：原型就是用来让人改的。它存在的价值就体现在被修改了几次，被更新了几次，以及它的下一步被少改了几次。

Step 2：模型（Mock-up）

在原型被大家接受之后，就该关心产品长得好不好看了。我们以“模型”这个词来统称该步骤的交付物。和原型相比，它关注于产品的视觉设计，包括色彩、风格、图标、插图等等。

要清楚的是，这不是一步由“美工”来“美化”的工作。视觉设计师需要对原型设计有深刻的理解，对交互设计和尚未进行的HTML/CSS/JS的 Code都要有充分的了解。如果不能从全局的角度来做视觉设计，则只能是做做把水晶效果改成金属效果这样的“自娱自乐”，而对产品本身没有任何有价值的帮助。如果原型说：“在这个页面上，A比B重要。”，那他的脑子里就要有十七八种可以表现“A比B重要”的视觉语言可供选择。这是对设计模型的视觉设计师的基本要求。

更高一些的要求，才是视觉设计的“原始功能”。“倒底是选水晶效果还是金属效果？”，“这个按钮选什么颜色好？”等等。这一类的思考和选择，应着眼于产品的气质、品牌等等，在各种产品间保持一定的统一，在用户心里打下视觉的烙印。其实要做到这一点是很难的，特别是还要满足上一点的要求。一般来说，如果能90%的把交互设计的成果和品牌形象表达出来，已经是很好的结果了。从我自己来说，就常常很郁闷不能用好的视觉语言来表达自己在原型设计中的想法，总是做完模型就打个七折:(

更更高的要求，有些问题用交互设计是很难解决的，这时就需要一个有创造能力的视觉师，可以从视觉设计的角度来创造性地解决问题（一时还没想出好的例子，想出来再补上）。

总的来说，模型设计是件非常困难的事情。它的工具是感性的，但设计过程又要求非常理性，必须在各种约束条件中解决问题。而目前能从较高的角度来来看“视觉设计”的人还不多，大多还停留在“效果”、“风格”等表面议题上。个人以为在“Web标准”和“用户体验”之后，视觉设计是Web设计专业化运动的第三波，市场的需求已经存在，只差有人推动一下。

模型的设计一般来说都是用Photoshop了，下是是个例子（与原型的例子对应）：

Step 3：演示版（Demo）

这步我就不多说了，Demo就是按照原型和模型用xHTML/CSS/JavaScript等等前端技术实现出来，以便后端的开发工程师可以接手编码。这个过程让小马、正淳专门起个新帖来详细介绍吧。只提一点，前端开发在有些公司是不放在设计团队的，而我们认为前端开发从很大程度上来说是对用户体验的提升和保证，开发只是它的一个手段和形式。所以就把这块工作一直留在我们团队，现在看起来这样很棒：）

把上述原型、模型转为xHTML/CSS之后就是这个页面了：

http://favorite.taobao.com/collect_list——-g,nrxwy2lumhgozsvz2cq3tk6w64-.htm

Step 0.5/1.5/2.5/3.5

居然还有半个半个的步骤？是的，这是我们的用户研究过程。在各个阶段的前后，我们会根据具体情况选择是否投入精力到用户研究上。用户研究的形式也很自由：给会员打个电话，旺旺上随便找人聊聊，到公司来做可用性测试，到会员家中访谈……怎么方便怎么实用就怎么做。我们还没有精力放在太多的“学术”性质的理论研究上，对研究方法也是不拘一格，“能抓老鼠”就行。关键的关键，研究的结果如何表现到产品上，如何吸收单个用户的意见来服务所有用户。

在这一点上，我们做得还很不够，积累也很薄，需要向同行们多多学习，也请大家多多指点。

最后……

关于流程，要注意：

设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”；
“100分”的完美作品，很有可能没有遵循流程，而是天才地融合了创新、传承和执行力的作品；
“流程”这种东西，只有与环境相匹配才能带来正面的作用。

以上是我们UED团队目前的设计流程，也许你也发现了，它和大多数公司的设计流程是差不多的。我们也在不断地修改和发展这个体系，有不足的地方也请大家多指教。如果你借鉴了我们的流程，在工作中发现有什么问题，也请回来告诉我们，谢谢大家！

如何表述交互过程？

不言堂 — 2008-10-18 13:10:25

如何准确直观的描述交互过程？我们可以利用“效果图”+“操作流程图”+ “过程控制说明”三种图例组合同时加以常规的文字描述就能直观又全面的描述交互过程

以某个具体任务为例，三种图例分别起到下述的作用

效果图：直观的展现任务对应的界面效果

操作流程图：描述任务中各种状态的相互关系及流转方式

过程控制说明：描述任务完成的过程需要的用户操作，以及用户操作引发的系统及处理

效果图绘制技巧：应该说效果图的绘制没有太多的技巧可言，只要能够表述效果就可以了。当然选择合适的工作会对绘制起到很大的帮助。客户端程序我直接使用开发语言，比如.NET，网页端，习惯用axure
操作流程图绘制技巧：

1、描述整个操作过程的主题，可以是涉及的窗体、操作、状态、结果

2、利用线条描述特殊的操作流程

3、标绘流程中，特殊的或者需要说明的部分

4、附注说明部分
过程控制说明绘制技巧：

1、剥离过程中必须的用户操作

2、描述每个操作引发的系统需要处理工作。

过程控制描述，实际上是为了给研发人员更多的信息提示，告知什么操作必须由用户触发，而什么结果需要是系统直接提供，以及比较快速的检测某个动作引发的效果、处理是否遗漏。

------------------------------------------------------------------------

参考范例：

这个例子是地理信息系统里的一个比较复杂的功能，仅说明做法。
“同类属性选择”功能说明：在地图上显示与当前选择要素属性相同的其他要素。
效果图

操作流程图

1：任务开始有两条通路

打开同属窗体->选择参考要素
图上选择参考要素->打开同属窗体

2、3：允许任务操作过程中，修改“参考要素”

同上未选中同类要素时，直接图上修改参考要素
图上已选中同类要素时：
1. 图上提供右键，选择参考要素
2. 图上提供右键，取消选中->选择参考要素

4、可对参考属性进行修改，每次修改立即图上显示结果
过程控制说明

相关话题：交付物源地址：http://buyantang.blogbus.com/logs/30347193.html

巧用需求、设计文档里的图

不言堂 — 2008-10-18 11:49:20

用例图
创建用例图涉及到为一组用例建立系统边界和定义特定主角与用例之间的通讯路线。
在开发项目的初期，用例图可以描述实际的活动和动机。您可以在项目的后期改进用例图以反映用户界面和设计细节。

用例描述了特定角色及其功能的需求以及各个角色之间的关联关系。

在界面角度，我们如何看待用例?

通过用例图，分析角色需求的最小值，协助确定重点角色（重点角色是各类角色的一个交集），明确辅助角色，以及各个角色的基本需求

状态图
状态图表示状态机。通过记录事件和转换，状态图显示了对象在其生命周期中依次经历的各种状态。

状态图描述了一个任务可能的状态，以及各个状态间的关联关系（每个状态应该是平级的），状态图在辅助研发人员检查程序完整性的同时，也为交互设计人员任务状态提供有效的提示。

作为交互设计时的操作模式的一种指导，检测现有的交付是否满足任务不同状态间的切换，以及如何切换

活动图

活动图是状态图的一个特例，其中所有状态均为动作状态，并且源状中的动作一经完成即会触发控制流。

活动图与特定的类或用例相关，它描述方法的内部行为。使用活动图可以表示内部生成的动作驱动的流。使用状态图可以表示响应外部事件的流。

活动图能提醒您注意并记录并行和同时发生的活动。这使得活动图成为建立工作流模型、分析用例以及处理多线程应用程序的得力工具。

活动图直观的描述不同的角色或者不同部门对于同一任务之间的衔接以及关联关系。

通过活动图，可以了解任务的整体流向和办理逻辑，同时也可以描述整个系统大框架的业务逻辑。

相关话题：交付物源地址：http://buyantang.blogbus.com/logs/30323955.html