软件开发制作使用visio画流程图的一点心得.docx

软件开发制作使用visio画流程图的一点心得.docx

《软件开发制作使用visio画流程图的一点心得.docx》由会员分享，可在线阅读，更多相关《软件开发制作使用visio画流程图的一点心得.docx（8页珍藏版）》请在冰豆网上搜索。

软件开发制作使用visio画流程图的一点心得

使用Visio画流程图的一些心得

一个哥们在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、评价流程图的好坏

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

1.亲密地迎合了用户的心理状态、如实的反映了用户的操作习惯。

流程图是要指导UI设计的，是UI设计的参照物，假如流程图本身无法正确描绘出用户的情况的话，UI十有八九会出问题；

2.覆盖了各种可能的情况和细节。

这非常重要。

任何在先期不确定的因素，都会在工程中成为随时引爆的地雷，都会直接降低最终上线的UI质量。

此种情况真是屡见不鲜。

但同时这条又很难做到，因为它不仅要求设计师熟悉用户，也要设计师充分知晓产品的商业逻辑，还要理解系统的运作机制，落下以上任何一个方面，都会在流程图中留下死角。

这个问题我不知道有没有更好的解决方案，不过与PD和系分反复沟通是个行之有效的方法；

3.考虑到系统的设计和承受才能。

系统的运作机制和承受才能必须在绘制流程图过程中考虑进去，以免出现流程图被开发人员枪毙的情况。

我的习惯是，在绘制流程图时和系统分析师频繁沟通和交流，确保每一个环节都是可行的；

4.确保别人看得懂你的流程图。

别人如今看不懂，你自己以后也一样看不懂。

为了降低沟通本钱，把流程图画清楚吧。

5、其它

〔1〕想方法把流程图绘制得漂亮些。

谁不喜欢漂亮的东西呢？

这是我做过的一些流程图，当然文字全部模糊掉了〔放图之前犹豫了好长时间－这样做不知是否有损我的职业道德。

我特意请教了Fenng，他觉得没事。

假如谁觉得有问题请直言不讳地告诉我〕。

〔2〕假如你在公司里不是一锤定音式的人物的话，你就需要对你的文档进展版本管理。

流程图也不例外，什么时间发布的什么版本，都要清楚地标出来，“最新〞是个用不得的词。