1. 一个哥们在 MSN 上告诉我，他们公司的交互设计师只产出流程图，并问我用什么标准评价流程图的好坏。他的说
法把我彻底震了－这分工也太细了吧！也不知道该说他们那里这样是好还是不好。
不过仔细想来，我倒的确没有仔细考虑过流程图的好坏，正好借此机会自我总结一下。
1、各司其职的形状
在我的流程图中，适用于不同目的和功能的形状都有各自确定的规范。到目前为止，我一共定义了以下一些形
状：
（1）开始和结束
作为整张流程图的头和尾，必须标清楚到底具体指哪个页面，以免日后出现歧义。
（2）网页
如你所见，网页的形状是一个带有漂亮的淡蓝色过渡效果的长方形，它的边框为深蓝色，中间写明了这个网页的
用途，括号中的数字代表这个形状所对应的 demo 文件的名称（比如这里是 2.html），我有时会把流程图输出为
网页的形式，并把每个网页形状和它所对应的 demo 文件链接起来，这样查看起来非常方便。对 OmniGraffle 来
说这是小菜一碟，如果你被迫用 Visio，嗯……

2. 另外，所有从形状出来的线条，都具有和此形状边框一样的颜色。这样的做法不仅看起来漂亮，在复杂的流程图
中还能轻易地标明各形状的关系。我没有见过类似的做法，所以这是由我首创也说不定，呵。
（3）后台判断
很常见的一个形状。我在用法上有一点和其他人的不同在于，我几乎总是让‘是’的分支往下流动，让‘否’的分支向
右流动。因为流程图一般都是从上向下、从左到右绘制的，遵循上述规则一方面可以让绘制者不用为选择方向操
心，另一方面也方便了读者阅读。
（4）表单错误页
既然有表单，当然会有错误信息。其实这个信息很重要，用户出错时惶恐不安，就靠着错误提示来解决问题了。
你不在流程图里说什么时候显示错误页、不在 demo 里提供错误页，有些程序员会直接在网页上写个“错误，请检
查”，所以 UI 设计师一定要对这个东西重视起来。
但一般来说也没必要把每种错误都在流程图中表示出来，因为含有两个文本框的表单就有三种出错情况了，多了
就更不用说了。所以我都是把错误页变为表单的附属页，比如表单页的编号为 2，那么此表单错误页的编号就从
2.1 开始排下去，每种错误放到一个附属页中，这样程序员在拿到 demo 时也能搞清楚什么意思。
结合网页和表单的形状，一个表单验证的流程图就是这样的：

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

4. 多重分支指的是几种并列的情况，每种情况都有发生的可能，发生哪种取决于分支起始处的判断结果。
（7）对话框
有时候一些操作可以利用对话框来完成， 这些对话框由 js 生成，显示在父界面之上。
（8）注释

5. 这个形状（比如页面）详细的内容，或者需要解释的业务逻辑，甚至用户此处的情况等，我都会放到注释中，这
样既降低沟通成本，又可作为备忘。
（9）跳转点
在一个复杂的流程图中，往往出现跳转到另外一个远处结点的情况，此时如果直接用线连过去，未免使得流程图
显得凌乱，用一个跳转点就解决问题了。在点内标明跳转到的形状的编号，画起来容易，看起来也清楚。
此外，也可以利用跳转点来分割篇幅巨大的流程图，Yahoo!就这么用。
（10）子流程
分割篇幅巨大的流程图，更好的办法是用子流程。

6. 要注意的是，如果你在流程图中使用了子流程这一形状，一定记得同时附上子流程图，以消除影响项目质量的不
确定性因素。另外，在子流程图中也可以标明其所属关系。
（11）流程块
可以用流程块将整张流程图分隔为几个部分，并为每个部分单独命名（比如“流程块 1”等）。这样做的目的在于从
视觉上使复杂的流程图变得更为清晰，在沟通时也方便。

7. 2、图例和流程图信息

8. 在团队合作中，图例是必须的，否则没人知道你画出来的东西到底是什么。即使流程图只给自己看，也最好养成
标注图例的好习惯。其实这道理有点类似程序中的注释。
流程图信息也是必备的。其内容至少应包括作者、时间、流程图名称和版本（如下图）。这一方面可以让读者
（其他同事）在有问题时能够方便地找到作者你，也起到了 meta 的作用。
3、绘制流程图的工具
Mac 下首选 OmniGraffle，Windows 下除了 Visio，似乎没有更好的选择（虽然 Visio 已经很难用了）。
4、评价流程图的好坏
我觉得一个好的流程图至少应做到以下几点：
1. 密切地迎合了用户的心理状态、如实的反映了用户的操作习惯。流程图是要指导 UI 设计的，是 UI 设计的
参照物，如果流程图本身无法正确描绘出用户的情况的话，UI 十有八九会出问题；
2. 覆盖了各种可能的情况和细节。这非常重要。任何在先期不确定的因素，都会在项目中成为随时引爆的地
雷，都会直接降低最终上线的 UI 质量。此种情况真是屡见不鲜。但同时这条又很难做到，因为它不仅要
求设计师熟悉用户，也要设计师充分知晓产品的商业逻辑，还要了解系统的运作机制，落下以上任何一个
方面，都会在流程图中留下死角。这个问题我不知道有没有更好的解决方案，不过与 PD 和系分反复沟通
是个行之有效的方法；
3. 考虑到系统的设计和承受能力。系统的运作机制和承受能力必须在绘制流程图过程中考虑进去，以免出现
流程图被开发人员枪毙的情况。我的习惯是，在绘制流程图时和系统分析师频繁沟通和交流，确保每一个
环节都是可行的；
4. 确保别人看得懂你的流程图。别人现在看不懂，你自己以后也一样看不懂。为了降低沟通成本，把流程图
画清楚吧。
5、其它
（1）想办法把流程图绘制得漂亮些。谁不喜欢漂亮的东西呢？
这是我做过的一些流程图，当然文字全部模糊掉了（放图之前犹豫了好长时间－这样做不知是否有损我的职业道
德。我特意请教了 Fenng，他觉得没事。如果谁觉得有问题请直言不讳地告诉我）。

10. （2）如果你在公司里不是一锤定音式的人物的话，你就需要对你的文档进行版本管理。流程图也不例外，什么时
间发布的什么版本，都要清楚地标出来，“ 最新”是个用不得的词。
我就说这么多了，抛砖引玉而已，蓉儿等人看你们的了！
噢对了，问个事儿：大家有没有觉得我每次写的文章都太长了？
10 月 8 日更新：继续阅读支付宝交互设计师 Joycce 的流程图分享，也欢迎参加这次“流程图征集、分享和讨论活
动”。