不过做图表的特效倒是有，和你给的不太一样

你看看这个是不是你想要的效果

http://hci.stanford.edu/jheer/files/zoo/ex/networks/force.html

下面是合集地址

http://queue.acm.org/detail.cfm?id=1805128

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

（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和系分反复沟通是个行之有效的方法；

考虑到系统的设计和承受能力。系统的运作机制和承受能力必须在绘制流程图过程中考虑进去，以免出现流程图被开发人员枪毙的情况。我的习惯是，在绘制流程图时和系统分析师频繁沟通和交流，确保每一个环节都是可行的；

确保别人看得懂你的流程图。别人现在看不懂，你自己以后也一样看不懂。为了降低沟通成本，把流程图画清楚吧。

前端开发流程概述

前端开发流程可分为需求分析、开发阶段、测试阶段、维护阶段，下面分别进行叙述。

2.1 需求分析

这个环节中，首先是和客户进行交流，了解客户的需求，然后分析项目的可行性，撰写项目需求文档。如果项目可行，则起讨论具体方案，分模块分步骤进行规划，分析项目进度安排、所需成本，进行原型设计（包括页面布局图，页面逻辑流程图，说明文档等。通过原型设计，可以让项目组和客户都可以对项目有一个直观感受，同时可以低成本高效率的复现业务场景和各模块流程）。

可以说需求分析阶段是整个前端项目的基础，基础不牢，地动山摇。可以试想，如果和客户沟通不顺畅，有的方面客户没搞清楚是什么效果，开发完成后就可能与客户发生纠纷；如果可行性有问题，有的模块很难实现或成本超出预算，就很难处理。

2.2 开发阶段

这个环节是前端工程师主要参与的部分，按照需求分析阶段的规划按步骤完成任务。

根据产品需求分析文档和原型图进行UI设计，对产品的整体美术风格、交互设计、界面结构、操作流程等做出设计。负责项目中各种交互界面、图标、LOGO、按钮等相关元素的设计与制作。

根据UI设计进行规划，提取界面中可以复用的模块方便重复利用，分析界面是否有实现难度比较困难的地方，进行沟通和功能排期，按功能大小以及难度进行功能时间的评估，和后端沟通好排期时间，保证大家能够更有效地开发合作，针对功能复杂的地方要先理清思路。

不要盲目开发前端搭建框架。根据设计图进行前端界面开发，以及遇到的问题及时与产品、UI、后台人员沟通，保持大家信息一致，针对不清楚的地方也要及时沟通，以免做错功能。

根据后端接口进行字段填充，以及部分功能开发。针对缺少的字段或者数据结构进行提出，及时与后端反应，尽量让大家都能以最小的改动完成后续开发工作。前后端都要按照规范进行开发，针对不规范的地方要给与提出、指正，营造出规范的工作模式，以后维护成本和沟通成本更低以及开发效率更高。如果前端的设计进度远远超前后端的接口和数据结构设计，也不必等后端，可以自行开发nodejs服务器配合postman等接口软件进行开发。

前后端功能联调、完成自测。检查功能完成情况，看是否有遗漏，出现问题及时沟通解决。

2.3 测试阶段

发布测试、修改bug、发布上线，自测完成后提交测试，测试根据提交的项目以及需求进行测试，提出bug给相关人员修改，开发人员周期性的配合修改bug，保证今天能够修复昨天的bug。

发布dev环境，配合测试，修复bug以及需求优化

发布test环境，修复bug以及需求优化

发布it环境，修复bug以及需求优化

发布pre环境，修复bug以及需求优化

pre验收之后，发布线上环境，产品进行验收

2.4 维护阶段

如果客户验收通过，项目就进入了维护阶段，程序的维护包括程序上线后后续bug的修复和程序版本的更新。

3 个人经验总结

3.1 文档很重要

前端项目的文档似乎已经作为前端工程化的标准流程之一了，文档写的好，可以便于同事快速了解你的代码功能和需求，便于协作。可以想象，随之项目复杂度增加，体量越来越庞大，开发团队人数也越来越多。这种情况下，如果像变魔术一样隐匿中间流程而直接得出结果，后果可想而知：项目复杂度越增加就越难以管理，开发效率低，合作混乱，结果甚至导致项目死亡。

好的文档看起来就像一个产品说明书，但作用却远远超过了说明书，不仅仅告诉你如何使用，还应该告诉你项目的设计思路，用了哪些组件，哪些部分不完善，将来有什么规划等等。这是一份比较好的说明文档。

3.2 与客户及时沟通很重要

3.3 扎实的基本功很重要

尽管当下框架、函数库、工具包等更新迭代非常快，前端工程师有很多新的知识要学，但原生JS、HTML和CSS依然是重要的基本功，在学习前沿工具的同时不能放弃基本功的训练。