这里说的原型仅针对基于B/S架构开发的项目。

目前有很多专业制造原型的工具例如axure、mockflow、InfoMaker和一些“非专业”软件：photoshop、Dreamweaver等等，如果你有足够的耐心使用word也可以做原型，当然还有笔、纸、橡皮擦。

我接触过很多原型制造工具，也做了很多所谓的原型，项目不同，公司不同，使用的工具也不一样。

团体认为用哪种工具制造原型，

第1取决于用哪种工具最适合项目人员间的交流与沟通。

第2要看原型制造者能否对此工具最熟悉,能以最快和最精确的方式让原型展现出来。这点非常重要，原型不单单是项目最直接的展现，同时要能快速反应，让相关人员尽早看到项目有哪些变化。

第3是方便原型制造人员后期修正及进行归档。

第4要看制造的是低保真原型还是高保真原型。

不可否认的是很多项目经理由于时间紧，任务重，无法忍耐程序员"闲置"等缘由。不会将很多时间用在原型的设计制造上。

同时大多数项目的原型最让人困惑的就是它到底细化到什么程度，也就是，什么时候视觉设计师可以进入任务，什么时候后台程序可以开始编程。普通B/S架构的开发顺序为：原型-》视觉-》前端-》后台，其顺序也不是直线的，前3步应该是环行循环进行的。

基于以上两种缘由是不是就产生了两类原型，一是底保真原型，二是高保真原型。如果严厉按照规章办事,单纯作为项目展现与交互说明的原型,应该只要"低保真"这一表现方式,但这毕竟只是个理想,随着项目的进行，大家对高保真原型的呼声会越来越高,大家都在期待在原型中看见更多的视觉效果。如今越来越多的原型制造软件都在提升控件的自定义视觉，是不是都把原型制造软件做成可以加后台加视觉从原型制造软件变为开发软件才是这些公司的的最终目标呢....

至今我仍没见到一个项目的整套原型是完全以低保真原型作为交付物的。目前接触最多的一种情况是用Dreamweaver制造高保真原型，不可否认用Dreamweaver做原型有很多弊端。

例如Dreamweaver并不是项目组所有人员都会，可交互设计师、视觉设计师、前端工程师、后台工程师都应该了解并会使用Dreamweaver。毕竟大家都是做B/S架构系统开发的，不是说要对Dreamweaver通晓，但最少应该达到像使用WORD软件那样可以进行基本操作吧。不了解前端就做出华丽效果的视觉设计师，不了解前端就对各控件的实现方式进行说明的交互设计师，他们最终的交付物会很惨白而且没有说服力。

作为基于B/S架构的系统，最后生成的大多数JSP页来自于HTML文件。在一定程度上也可以说制造位于低保真原型与前端页面两头的高保真HTML页的折中方案未尝不是个方法。

我认为比较好的任务方式是UI设计师和项目经理共同按照打印成册的需求分析对单一模块进行讨论，实时的在纸上手绘出模块中各控件，确定模块中所有控件的操作方式与要展现的数据，尽量确保其正确性。接下来，项目担任人不断保持在“3米之内”，看着原型制造人员将原型实现出来。这没有浪费了项目经理很多时间。项目经理不是干瞪眼发呆，他可以在原型实现的过程中考虑其他问题，或者做其他事情，但就是不能离开。让项目经理在3米之内是很重要的。在原型制造的过程中会出现很多一开始没有发现的问题，交互方式、和一些细节问题等等。一定要确保原型制造者和担任人能及时讨论。不要期待打分机、OA协同、或者SKPYE、MSN什么的可以及时找到他。要让所有的项目经理养成这个习惯。即：项目初期，哪也不要去。就得花上几周的时间与设计师共同拼出个高保真的原型出来。

当然在前期也可以进行众多人员参加的原型讨论会和项目需求分析会等等会议,但最后要记得还是要拉住项目经理,让项目经理与担任制造原型的人保持在3米以内。

文章题目中用了“讨论”一词，是十牌觉得在这类问题上讨论的空间很大，各个公司和团队也应该有本人的任务方式,也许采用灵活多变的方式合理制造并运用原型才是最合适的方式。