关于界面原型设计

不知道大家都用什么工具做界面原型

1. 白纸、铅笔、橡皮，有时候还需要剪刀。可惜大部分情况下保真度不高而且难以表述页面流程；
2. Word。。。。
3. PPT。。。
4. Flash，同 PPT，更加难以使用。适合制作小屏幕界面原型；
5. HTML，本文就是想讲如何使用 HTML 快速进行 Web 界面原型设计。
6. 使用axure这个工具

以上几个方法基本用过，但都存在很多问题。

如：如果几个人负责做界面原型时，共享问题。。。

不知道大家有没有好的方法。

评论

47 楼 beyondqinghua 2011-05-31  

我们公司需求变化要求很高，一般都用PPT画，也画得很逼真。

46 楼 fflame 2011-05-30  

在这个帖子里收获良多。
之前一直都不大关心界面的作用和实现的，现在自己弄项目才感觉到重要性。

45 楼 aaashun 2011-05-19  

你用Axure有多人共享的特性, 这需要svn的支持，相关资料很多

44 楼 eredlab 2011-05-19  

<p>
</p>
<div class="quote_title"> 写道</div>
<div class="quote_div"><strong>不知道 eredlab  是否认同！</strong></div>
 认同了 睡觉去

43 楼 xieyanhua 2011-05-18  

<div class="quote_title">eredlab 写道</div>
<div class="quote_div">
<p>偶又发起了一个关于界面设计的口水贴  欢迎大家过去喷几句 ：）<br><br><a href="/topic/1047210">http://www.iteye.com/topic/1047210</a></p>
<p> </p>
</div>
<p> </p>
<p>很简单的一个问题，也有很多人讨论过，在此再提一提这个老问题，不是真的要讨论出一个结果，只想以此说明问题，任何事情都需要前提条件，那样才有意义：</p>
<p>          </p>
<p><span style="color: #ff0000;">     问题1、JAVA和C++两门语言，那个语言烂？</span></p>
<p>                 答案一：java语言烂-------结果肯定是绝大部分JAVA的程序员看不惯，奋起反击，甚至也会包括部分的C++程序员。</p>
<p>                 答案二：C++语言烂-------结果肯定是绝大部分C++的程序员看不惯，奋起反击，甚至也会包括部分的java程序员。</p>
<p>                 合理的答案：无法解答，没有更多的信息来判断谁好谁坏。你这样回答，99%的C++和99%的JAVA程序不会反驳你，生气其他语言的程序员也不会反驳你。</p>
<p>                 </p>
<p> </p>
<p><span style="color: #ff0000;">     问题2、做一个WEB开发，是JAVA语言好/烂，还是C++好/烂？</span></p>
<p>                你回答 C++语言烂，我想99%的java程序和C++程序都不会反驳你。</p>
<p> </p>
<p><span style="color: #ff0000;">     问题3、做一个底层的电信通信控制模块，是JAVA语言好/烂，还是C++好/烂？</span></p>
<p>                你回答 JAVA语言烂（其实用‘烂’这个字不合适，用‘不适合’可能比较合适），我想70%以上的java程序和99%C++程序都不会反驳你。当然，java也可以做一些底层的东西，尽管JAVA的性能也在不断的提升，但是总体来说，java的性能不如C++，这是不争的事实，大多数正常的程序都不会反驳，在剩下的30%中，可能有一部分人不那么认为，要看要做的软件的性能等各方方面的约束了，在都能实现并达到要求的前提下，可能java比C++更适合。再剩下的一部分偏执型的，也都不需要理会了</p>
<p> </p>
<p>     </p>
<p><span style="color: #000080;">     三个本质一样的问题，同样的答案为什么会出现不一样的反应，问题再与，第一个问题没有任何参考条件或者实际的环境下进行讨论，下结论是没有任何意义的。</span></p>
<p> </p>
<p><span style="color: #0000ff;"><span style="color: #000000;"><strong>不知道 eredlab  是否认同！</strong></span> </span></p>

42 楼 eredlab 2011-05-17  

<p>偶又发起了一个关于界面设计的口水贴  欢迎大家过去喷几句 ：）<br><br><a href="/topic/1047210">http://www.iteye.com/topic/1047210</a><br></p>
<p> </p>

41 楼 haole 2011-05-17  

为什么要界面原型呢？
主要原因还是需要没有分析清楚，系统架构人员没有对业务系统有一个清楚的认识。
只要能把需求分析清楚，与客户交流清楚，何必要界面原型？
再说，当系统复杂后，有时间能够清晰、详细的进行界面原型吗？

40 楼 redouble 2011-05-16  

系统原型工具还有很多啊。这里说几个我用得比较熟的：
balsamiq mockups
serena prototype composer
demni
omnigraffle
pencil

39 楼 xieyanhua 2011-05-15  

抛出异常的爱 写道

xieyanhua 写道

抛出异常的爱 写道

to:xieyanhua

页面上百之后.....
需求分析麻木

效率会有下降
客户看着反感,
画页面的人开始唬弄
拷贝来拷贝去

你是怎么应对的?

1、页面量大的问题（我不知道几百个的页面量算不算大，当然有的大系统，比如erp，拿就算了，也不是说几个月能搞定）。

从我的经历来说，还真的发生发现您所的情况。反正，你们说的情况基本上都是正面的；当然，可能我们是小公司，做的项目都不算大（最大的1000万左右，但是也是由多个小系统组成，每个系统50～120万左右）。刚刚看了一两个以前的demo页面量，没有全部看完，其中一个569个页面，一个481个页面。打击感觉都还好。

这个是我写错误，实际上是没有发生过您所说的情况，在我以前的公司中，基本不存在你说的那些情况。

2、需求麻木，不太理解您的意思

由于页面这东西 列表 列表 表单 表单
十多个一样的东西在一起
分析分析就 麻木了...
每个表单改了又改客户看着没业务毛病也要改改字体才爽


呵呵，至于表表，列表，做MIS，是免不了了。但是如果过个表单或列表同时在一个页面上，还是比较少的。呵呵，可能我们做的系统比较简单。呵呵

“每个表单改了又改客户看着没业务毛病也要改改字体才爽”，这个的话，就要跟客户沟通好了，一是从商务上去规范客户的行为；二是我们需求人员要引导客户，那些是重点，那些不是重点，大家明白了这点，应该就不会有太大的问题了；三就是看时间了，如果大家时间都很充足，也无所谓，呵呵，改就改了，反正客户出钱麻，呵呵

   我们的做法是，基本上做那部分的需求分析，同时会做界面原型，一般一周一次到两次，初步跟客户沟通确认。曾经也有在客户现场开发的情况，因为涉及到客户而是几个部门，到需求后期，基本上每周两到上次的确认会议，昨天下午开会确认要求该的问题，会后开始修改，可能花一天或半天时间修改。改好后，再次开会讨论（当然不单单一个功能，可能几个功能同时进行）。一直到需求结束。有的客户也不是很配合，时间关系，大家都很忙，但是客户的需求负责人会总体负责，要求他们的人员配合，我们的项目部的负责人会跟他们提要求，也就是职责分明。出问题，谁的责任谁负责。

3、效率问题，相对来说，采用我的模式，确实效率会地点，因为化界面原型和部分逻辑实现，是要花时间的。
效率是指开发效率下降,
页面这东西本来就是些js活,ajax活,iframe
这些东西作需求时可能作也有可能不作,
作开发时也扯皮


这个东西，就看大家或则团队怎么去看了，如果只是应付式的，大家看不到好处，或者理解不到他的好处。那大家肯定不太容易去接受。不管采用什么模式，关键你要让大家了解到它所带来的好处，并且确实能带来好处。

确实，页面的东西就是js、css或html的活，可做可不做，关键看公司或者团队的要求，做到什么程序，如果团队或者团队负责人都觉得无所谓，自然不会有好的效果，只有大家都将需求阶段做的原型是以后工作的一部分，大家都有良好的质量意识，才会用心去做好每件事，做需求的原型也一样。

这个个好说，每个工作阶段都会有输出成果，输出成果的标准都是项目立项时就确定的，所以，只要根据标准去衡量就好了，达不到标准的就要改了。

项目立项时，团队组件好后，准备进入开发的时候，包括demo，就要跟组员培训，强调项目中的开发规范，大家必须要遵守的。

但是也不是很多，很多公司都是页面的控制，不设计到后台java的控制。再说了，现在做了，以后99%可以直接使用。也不觉得多花很多时间，比如，不按我的方式走，需求需要2个月，按我的模式，可能需要3个月；需求阶段是多花了时间，但是实现阶段我们花的时间也少了啊。（项目中时间是不变的，前面的时间多了，后面的时间肯定就少了，但都在我们的可控范围内）

4、客户反感或程序忽悠：

客户什么 都想管理
这块什么颜色
这个东西放在那边
这里突出一点.
业务什么的......


客户的想法肯定是五花八门的，但是开始可以有这种想法，但是，随着需求阶段的不断深入，越接近后期，规范和约束就越大，也就是说，客户随意发挥的空间就越小，这点问题不大，大家都明白，我们想要的是什么。而且每个阶段的工作不可能无限期拖延，当然，如果客户愿意付出（money等），而且公司也能接受.那就另当别论了。

而且，作为需求人员/做需求的开发员，应该要去引导客户，我们优先考虑的是重要的功能，需求等，而页面花哨的东西时间允许，可以考虑，但是如果时间不允许，就要跟客户解释，展示不考虑这些修改，但是以后正式系统中肯定会按他们的要求修改实现的。

如果是业务的变来变去，这个也是可以跟客户要求的，走正规途径，不是你说我就改。这种情况也遇到过，国企，需求一个刚毕业的研究生，想法很多，也是变来变去，昨天说那样做，今天又另外一种，后台后变了，包括已经上线的模块，我们也很郁闷，受不了啊，而且刚毕业的，什么东西都想要很完美，但是实际是不可能。之所以出现这种情况，跟公司的管理流程有关，不规范。客户其实有需求接口人，这个研究生实际只是负责某个部门的需求，跟我们提的需求，公司也没有走正式的需求或者需求变更流程。

后来我也建议公司，走正规流程，虽然说可能我们还是要安客户的需求实现，但是问题性质不一样，以后正规流程，客户随意性太大，可能某天脑子一发热，就跟你说，也不考虑是否可行，而且如果延期，最终问题还是归在我们。但是走正规流程，需求人员在给我们提需求的时候，至少会更加慎重。而且更关键的是，我们要确认责任所属谁。

我的经验来说，都是正面：
就拿上家单位来，给国企做的：

采用我的模式之前：
在我去之前，跟客户沟通，就是靠嘴巴沟通，然后将客户的信息记录下来，转化为自己的需求文档，可能附带一些图，比如visio化的流程图或模块图之类的，去跟客户沟通，效果就不用说，非常差，而且需求理解透不透彻，换跟做需求的人员的能力水平有关，有的很多问题，跟客户理解的差距很大。有时候，拿着那些GUI或excel的界面原型，和需求文档让客户确认，让客户看，几天后，我们问客户有什么问题，人家说没有什么问题（实际上是他们没有看，也就无从说什么确认了），而我们实际实现后，客户端不是他们想要的，为什么？人家说，你们给我们的那些原型，都不能交互，点了也没有反应，也看不出什么来，你们的需求文档，那么多，正面能看等过来，中而言之，是非常不配合，我们也没有办法，确实是我们的责任比较大，再一个，客户的领导肯定是向着 他们的员工，不会帮我们说话，所以很无奈。

开发员也很无奈，因为一般我们都是开发员做需求的，基本上从一开始的需求到后期的实现，都是开发完成的（小公司，无法配备专门的需求人员）。很多时候，不是每个开发员都有相关的行业知识，所以很多东西无法理解客户的需求，或者替客户挖掘需求，提出更好的建议，跟客户沟通很困难（因为客户不是很配合），又没有很好界面的东西跟客户沟通，客户也提不出什么问题。因为需求理解的问题，在编码设计的时候，经常要改动，开发员很郁闷。

采用我的模式后：
客户配合好多了，因为找不到理由了，我们的原型是可交互的，流程基本都按业务要求实现（80～90%），客户在上面操作，就知道是不是他们想要的东西了，但是有些还是需要跟客户讲解说明。所以如果客户再不配合，我们可以跟他们的相关负责人提要求，出问题，拿是谁的责任就是谁的责任了。而单纯的文字配图片的需求规格说明书的确认，基本上也是没有问题，都是按界面原型和用户需求编写的，一般差别都不大，所以用户确认了界面原型，基本上需求确认也就差不多了。客户不需要花很长时间去看枯燥的文字版的需求，看有交互能力的原型，更有吸引力。呵呵！经验来看，效果还是非常不错的。

开发员，有了那样的界面原型，跟客户沟通容易多了，客户配合了，彼此挖掘需求就容易多了，而且我们的开发员也可以提一些改进建议。再一个，因为在需求阶段，客户基本已经确认了需求和页面风格。所以，在后期的编码设计，基本上页面改动不会很大。所以开发也很开心啊，而且本来页面也是他自己做的，早做晚做都是他在做。既然这样的效果，他们当然也乐于接受了。而且从大家的反馈来说，效果都不错。

5、画页面的人开始唬弄，拷贝来拷贝去。

通用的东西有时会作好几次,
还有就是CSS每页一套比着看着对了不管IE6了
还有就是有人从后台转过来的东西不全
比如总页码,当前页码


如果有人不熟悉，我想应该是你们的开发或者相关的配套不是很全面吧！拿我们的做界面原型的UI框架来说，不管你是前台后者后台，只要你有一些基本的html，js，css就够用了，剩下的基本你就是看别人做好的东东，修改一下就ok了，而且很多都是组件时的，比如你提到的什么分页，或者列表grid展示等等

而且，一般做界面的，一般只需要实现基本功能，一些复杂的js，css都是有专门人负责，包括一些组建的完善等，也是有专人负责。

培训业是必须的，在做demo之前，肯定要给组员培训，怎么使用框架开发demo

前面已经说了，画界面也是开发员在自己做的，所以基本不存在上面的问题，对于copy来copy去，拿就看公司了，确认是存在这样的问题。但久以后，不会了。

首先，每个公司都有自己的开发规范，开发规范在项目立项时就已经制定好，包括文档规范，编码规范，jsp，css，js，java，sql等，目录规范，都是有严格要求的。如果不遵守，那他就要修改，如果长期犯相同的错误，那会跟他的个人利益挂钩，考核什么的。再一个，我们都会有review机制，不符合的，自然也通不过。

你提的问题，在我采用的那么多公司中，基本没有出现错太大的问题，当然，我们公司基本都不是什么大公司。呵呵

基本上我们的team也是作原型的
不过是先画纸上
一页一页翻着讲
有问题随时改.....问题大了就重画
不过也是不很理想

想要试试你的方式
不过你有什么规则之类的
可以借鉴一下么?

对于规则什么的，我理解的你指的规则，对我来说，实际就是公司的规范，至于规范，每个公司规范都不一样。而且每个公司的情况不一样。

那我们以前的公司或经历来看吧：
1、在公司没有行程UI开发框架之前，我们的UI框架包括Struts后端的控制，根据后时间安排，如果时间充足，我们的数据就是由有太struts控制生成（甚至有些可能是数据的了），因为前面说了，经过一段时间后，实际很多东西都起来了。不单单只是HTML了，这样，我们前期做的demo，复用率就更高了，以后编码实现，开发开发工作量就更少了（那前面那个进1000w的项目，到第三个子系统后，基本都是这种模式了）。

2、我们会专门的技术支持，即有技术组支持，ui组支持，UI组，其实也就是美工了，我们的美工设计、PS、HTML、CSS、JS和浏览器的兼容性都很了解，所以基本上遇到这些问题，或者复杂页面效果或控制，都交由美工去负责；对于web组件的问题，比如我们当时用的flexgrid等，由另外一个同事负责，而且为了支持前端的需求，后端可能需要一些处理，比如按组件需求，后端生成相应的数据格式等，则又由另外的同事负责，当然，这些人不是说只做这些事，他们也做别的，只是每个方向都有一些人专门研究负责，他们根据任务或问题的紧迫性，确定是否实现或者什么时候这些新提出的功能。

3、前面说到UI，我们的美工确实很不错，写的CSS复用率都很高，也很清晰，所以我们在写jsp或页面的时候，是比较容易的，而且如果遇到那些水平很烂的美工，我遇到过，那即使他做出了基本的html，css，js出来，你写页面同样很郁闷，比如我上次遇到一个每个，设计非常垃圾，一个系统的登陆页面，就是一张完整的图片，一张图片1MB多，你说晕部晕，人家还振振有词，我们以前都是这样设计的（很多图简单，都是一大图片来实现），而好的美工，会考虑很多，通过很多小图片来实现；在一个就是CSS，她的CSS，都是特定的，比如写死的，按元素的ID来，你的ID变了，就不能用了，等等，所以美工的水平和他的设计理念也是很重要的。

4、丰富的组件支持，即使没有很多的组件，也需要有相应的人重点关注或研究。即用到的东西都有人负责，这样开发demo及系统的实现开发就能比较容易或顺利开发了，也即相关的人员只需关注他自己的部分或实现，其他部分则不需要太关注。在开始，UI框架或者说系统开发框架还没有的时候，那么美工就要给我们HTML,css,JS了，这种情况，开始可能不是很顺利了，我们也经历了这样的一个过程。但是一但一个一个系统正式开发完后，基本UI框架也基本成形，加上中途和后期持续的晚上该进，第二个、第三个... 系统的demo和系统开发，就是越来越容易了。

5、至于规范，其实也没有什么，在web层：

• 整个系统会有一个统一的，公共的CSS，或基本的js(js框架，结合开源的自己封装的)
• 剩下的每个页面有对应的对应的js，css（很少，一般只有少数的页面，可能需要特殊的效果，这时可能才有自己的CSS文件）。
• jsp页面，不允许出现任何JS或则css代码，保证页面的整洁，便于后期维护，所有的js，css都必须通过文件方式引入页面
• 一些公共的资源，css，js等文件，都统一在一个页面里，任何其他页面再引用该页面；
• web要求，框架提供好的各种UI控件（比如布局，弹出窗口的对话框等），封转好的组件（如树形控件，ajax控件）等，必须使用框架里的，而不能使用别的，比如框架使用的属性控件是A，如果实现树形控件，就必须使用A，而不能随意使用其他的树形控件；包括ajax，我们使用是jquery，但是我们不允许使用原生的ajax，所有交互必须使用我们封转好的ajax工具组件；等等。
• 在相关阶段开始前，如果有规范约束的，在开始前做培训，比如需求开始前有需求规范培训，做demo前，有ui框架培训，编码前，有编码规范培训等。比如做需求前，会培训需求文档怎么写，有什么内容，每项的目的是什么，要求是什么，等等，让大家明白。即让大家知道要怎么做，而且知道为什么那么做。而不是简单的知道那样做就行了，如果不理解为什么要那么做，可能做出来的东西还是不是你想要的。
• 团队要有统一的项目规范，这个是必须的，否则没人一个风格，就郁闷了。一些规范是可以通过自动化工具支持的，可以省去很多人力。人工去做，效率低，很费时。
• 必要的review，前面说review，有些是可以通过工具去做的，比如代码review，可以通过工具检测是否符合规范，是否存在质量或潜在bug的问题；进入人工review，一般都是看设计和实现是否合理的了，规范性检查就比较少了。
• 公司支持，很重要，有些工作是要成本的，如果公司不支持，领导不重视，就比较难了。

暂时是这么多吧，这只是一种参考，未必适合每个公司，每个公司的情况不一样。我以前基本上都是那样做。
web部分的划分：


需求阶段的功能描述样例：

• 对于输出，也会对应一个表格，该功能简单没有具体的输出要求，所以没有表格，实际输出部分的表格表样和输入的表格差不多，就是输出什么字段，数据格式怎么样，比如数值型的，小数精确几位；日期型，日期显示格式要求是什么，yyyy-MM-dd 还是 yyyy-MM-dd HH:mm;ss等
• 我们的需求文档，或者说需求阶段的工作，实际是包含了一些设计阶段的工作，比如数据长度限制，数据字典的选项及其选值范围，数据类型，反正能确定的都确定了，到时候数据库的设计就差不多了，至少取值什么的都不会变化太大；当然页面原型就不用说，可定是设计阶段的工作了，但是你可以看到，我们的界面原型就是正事系统的效果，基本上是不需要修改的。
• 之所以这么细，主要是让开发元拿到这个需求，就知道要做什么，怎么做，做成什么效果（原型），有什么要求，限制等，这样不免得到编码阶段，开发元还要挖心思去想我要怎么画页面，怎么布局等等，影响开发效率。对数据的要求，详细的话，在设计数据库的时候，很多久不再需要考虑太多，直接就可以用，或者有比较详细的参考，设计起来也比较容易，至少不需要考虑什么数据格式啊，什么选值的问题了。

38 楼 抛出异常的爱 2011-05-13  

xieyanhua 写道

抛出异常的爱 写道

to:xieyanhua

页面上百之后.....
需求分析麻木

效率会有下降
客户看着反感,
画页面的人开始唬弄
拷贝来拷贝去

你是怎么应对的?

1、页面量大的问题（我不知道几百个的页面量算不算大，当然有的大系统，比如erp，拿就算了，也不是说几个月能搞定）。

从我的经历来说，还真的发生发现您所的情况。反正，你们说的情况基本上都是正面的；当然，可能我们是小公司，做的项目都不算大（最大的1000万左右，但是也是由多个小系统组成，每个系统50～120万左右）。刚刚看了一两个以前的demo页面量，没有全部看完，其中一个569个页面，一个481个页面。打击感觉都还好。

2、需求麻木，不太理解您的意思

由于页面这东西 列表 列表 表单 表单
十多个一样的东西在一起
分析分析就 麻木了...
每个表单改了又改客户看着没业务毛病也要改改字体才爽

   我们的做法是，基本上做那部分的需求分析，同时会做界面原型，一般一周一次到两次，初步跟客户沟通确认。曾经也有在客户现场开发的情况，因为涉及到客户而是几个部门，到需求后期，基本上每周两到上次的确认会议，昨天下午开会确认要求该的问题，会后开始修改，可能花一天或半天时间修改。改好后，再次开会讨论（当然不单单一个功能，可能几个功能同时进行）。一直到需求结束。有的客户也不是很配合，时间关系，大家都很忙，但是客户的需求负责人会总体负责，要求他们的人员配合，我们的项目部的负责人会跟他们提要求，也就是职责分明。出问题，谁的责任谁负责。

3、效率问题，相对来说，采用我的模式，确实效率会地点，因为化界面原型和部分逻辑实现，是要花时间的。
效率是指开发效率下降,
页面这东西本来就是些js活,ajax活,iframe
这些东西作需求时可能作也有可能不作,
作开发时也扯皮

但是也不是很多，很多公司都是页面的控制，不设计到后台java的控制。再说了，现在做了，以后99%可以直接使用。也不觉得多花很多时间，比如，不按我的方式走，需求需要2个月，按我的模式，可能需要3个月；需求阶段是多花了时间，但是实现阶段我们花的时间也少了啊。（项目中时间是不变的，前面的时间多了，后面的时间肯定就少了，但都在我们的可控范围内）

4、客户反感或程序忽悠：

客户什么 都想管理
这块什么颜色
这个东西放在那边
这里突出一点.
业务什么的......


我的经验来说，都是正面：
就拿上家单位来，给国企做的：

采用我的模式之前：
在我去之前，跟客户沟通，就是靠嘴巴沟通，然后将客户的信息记录下来，转化为自己的需求文档，可能附带一些图，比如visio化的流程图或模块图之类的，去跟客户沟通，效果就不用说，非常差，而且需求理解透不透彻，换跟做需求的人员的能力水平有关，有的很多问题，跟客户理解的差距很大。有时候，拿着那些GUI或excel的界面原型，和需求文档让客户确认，让客户看，几天后，我们问客户有什么问题，人家说没有什么问题（实际上是他们没有看，也就无从说什么确认了），而我们实际实现后，客户端不是他们想要的，为什么？人家说，你们给我们的那些原型，都不能交互，点了也没有反应，也看不出什么来，你们的需求文档，那么多，正面能看等过来，中而言之，是非常不配合，我们也没有办法，确实是我们的责任比较大，再一个，客户的领导肯定是向着 他们的员工，不会帮我们说话，所以很无奈。

开发员也很无奈，因为一般我们都是开发员做需求的，基本上从一开始的需求到后期的实现，都是开发完成的（小公司，无法配备专门的需求人员）。很多时候，不是每个开发员都有相关的行业知识，所以很多东西无法理解客户的需求，或者替客户挖掘需求，提出更好的建议，跟客户沟通很困难（因为客户不是很配合），又没有很好界面的东西跟客户沟通，客户也提不出什么问题。因为需求理解的问题，在编码设计的时候，经常要改动，开发员很郁闷。

采用我的模式后：
客户配合好多了，因为找不到理由了，我们的原型是可交互的，流程基本都按业务要求实现（80～90%），客户在上面操作，就知道是不是他们想要的东西了，但是有些还是需要跟客户讲解说明。所以如果客户再不配合，我们可以跟他们的相关负责人提要求，出问题，拿是谁的责任就是谁的责任了。而单纯的文字配图片的需求规格说明书的确认，基本上也是没有问题，都是按界面原型和用户需求编写的，一般差别都不大，所以用户确认了界面原型，基本上需求确认也就差不多了。客户不需要花很长时间去看枯燥的文字版的需求，看有交互能力的原型，更有吸引力。呵呵！经验来看，效果还是非常不错的。

开发员，有了那样的界面原型，跟客户沟通容易多了，客户配合了，彼此挖掘需求就容易多了，而且我们的开发员也可以提一些改进建议。再一个，因为在需求阶段，客户基本已经确认了需求和页面风格。所以，在后期的编码设计，基本上页面改动不会很大。所以开发也很开心啊，而且本来页面也是他自己做的，早做晚做都是他在做。既然这样的效果，他们当然也乐于接受了。而且从大家的反馈来说，效果都不错。

5、画页面的人开始唬弄，拷贝来拷贝去。

通用的东西有时会作好几次,
还有就是CSS每页一套比着看着对了不管IE6了
还有就是有人从后台转过来的东西不全
比如总页码,当前页码

前面已经说了，画界面也是开发员在自己做的，所以基本不存在上面的问题，对于copy来copy去，拿就看公司了，确认是存在这样的问题。但久以后，不会了。

首先，每个公司都有自己的开发规范，开发规范在项目立项时就已经制定好，包括文档规范，编码规范，jsp，css，js，java，sql等，目录规范，都是有严格要求的。如果不遵守，那他就要修改，如果长期犯相同的错误，那会跟他的个人利益挂钩，考核什么的。再一个，我们都会有review机制，不符合的，自然也通不过。


你提的问题，在我采用的那么多公司中，基本没有出现错太大的问题，当然，我们公司基本都不是什么大公司。呵呵

基本上我们的team也是作原型的
不过是先画纸上
一页一页翻着讲
有问题随时改.....问题大了就重画
不过也是不很理想

想要试试你的方式
不过你有什么规则之类的
可以借鉴一下么?

37 楼 xieyanhua 2011-05-13  

再补充一点，就是要有相关的支持，配套要起来，你不要说我程序画界面的时候，你的整套代码风格还没有确定下来，拿是美工的事。

我们的情况:开发员在画界面前，项目的样式风格以及是确定的，基本的CSS，js,html都已经确定了，在画界面的过程中，如果有地方自己无法实现，或者需要什么图片，那么美工就会支持。如果不能使用以前的样式风格，那么美工在我们画界面之前，就会设计好并切好页面给我们，我们直接套用就可以了。

在一个，就是在项目立项前，对组员进行必要的培训，包括规范要求说明，框架说明，UI说明等等。就是让大家了解必要的东西，知道如何去做。

这些都是必须的功课。

36 楼 xieyanhua 2011-05-13  

抛出异常的爱 写道

to:xieyanhua

页面上百之后.....
需求分析麻木

效率会有下降
客户看着反感,
画页面的人开始唬弄
拷贝来拷贝去

你是怎么应对的?

1、页面量大的问题（我不知道几百个的页面量算不算大，当然有的大系统，比如erp，拿就算了，也不是说几个月能搞定）。

从我的经历来说，还真的发生发现您所的情况。反正，你们说的情况基本上都是正面的；当然，可能我们是小公司，做的项目都不算大（最大的1000万左右，但是也是由多个小系统组成，每个系统50～120万左右）。刚刚看了一两个以前的demo页面量，没有全部看完，其中一个569个页面，一个481个页面。打击感觉都还好。

2、需求麻木，不太理解您的意思
   我们的做法是，基本上做那部分的需求分析，同时会做界面原型，一般一周一次到两次，初步跟客户沟通确认。曾经也有在客户现场开发的情况，因为涉及到客户而是几个部门，到需求后期，基本上每周两到上次的确认会议，昨天下午开会确认要求该的问题，会后开始修改，可能花一天或半天时间修改。改好后，再次开会讨论（当然不单单一个功能，可能几个功能同时进行）。一直到需求结束。有的客户也不是很配合，时间关系，大家都很忙，但是客户的需求负责人会总体负责，要求他们的人员配合，我们的项目部的负责人会跟他们提要求，也就是职责分明。出问题，谁的责任谁负责。

3、效率问题，相对来说，采用我的模式，确实效率会地点，因为化界面原型和部分逻辑实现，是要花时间的。但是也不是很多，很多公司都是页面的控制，不设计到后台java的控制。再说了，现在做了，以后99%可以直接使用。也不觉得多花很多时间，比如，不按我的方式走，需求需要2个月，按我的模式，可能需要3个月；需求阶段是多花了时间，但是实现阶段我们花的时间也少了啊。（项目中时间是不变的，前面的时间多了，后面的时间肯定就少了，但都在我们的可控范围内）

4、客户反感或程序忽悠：我的经验来说，都是正面：
就拿上家单位来，给国企做的：

采用我的模式之前：
在我去之前，跟客户沟通，就是靠嘴巴沟通，然后将客户的信息记录下来，转化为自己的需求文档，可能附带一些图，比如visio化的流程图或模块图之类的，去跟客户沟通，效果就不用说，非常差，而且需求理解透不透彻，换跟做需求的人员的能力水平有关，有的很多问题，跟客户理解的差距很大。有时候，拿着那些GUI或excel的界面原型，和需求文档让客户确认，让客户看，几天后，我们问客户有什么问题，人家说没有什么问题（实际上是他们没有看，也就无从说什么确认了），而我们实际实现后，客户端不是他们想要的，为什么？人家说，你们给我们的那些原型，都不能交互，点了也没有反应，也看不出什么来，你们的需求文档，那么多，正面能看等过来，中而言之，是非常不配合，我们也没有办法，确实是我们的责任比较大，再一个，客户的领导肯定是向着 他们的员工，不会帮我们说话，所以很无奈。

开发员也很无奈，因为一般我们都是开发员做需求的，基本上从一开始的需求到后期的实现，都是开发完成的（小公司，无法配备专门的需求人员）。很多时候，不是每个开发员都有相关的行业知识，所以很多东西无法理解客户的需求，或者替客户挖掘需求，提出更好的建议，跟客户沟通很困难（因为客户不是很配合），又没有很好界面的东西跟客户沟通，客户也提不出什么问题。因为需求理解的问题，在编码设计的时候，经常要改动，开发员很郁闷。

采用我的模式后：
客户配合好多了，因为找不到理由了，我们的原型是可交互的，流程基本都按业务要求实现（80～90%），客户在上面操作，就知道是不是他们想要的东西了，但是有些还是需要跟客户讲解说明。所以如果客户再不配合，我们可以跟他们的相关负责人提要求，出问题，拿是谁的责任就是谁的责任了。而单纯的文字配图片的需求规格说明书的确认，基本上也是没有问题，都是按界面原型和用户需求编写的，一般差别都不大，所以用户确认了界面原型，基本上需求确认也就差不多了。客户不需要花很长时间去看枯燥的文字版的需求，看有交互能力的原型，更有吸引力。呵呵！经验来看，效果还是非常不错的。

开发员，有了那样的界面原型，跟客户沟通容易多了，客户配合了，彼此挖掘需求就容易多了，而且我们的开发员也可以提一些改进建议。再一个，因为在需求阶段，客户基本已经确认了需求和页面风格。所以，在后期的编码设计，基本上页面改动不会很大。所以开发也很开心啊，而且本来页面也是他自己做的，早做晚做都是他在做。既然这样的效果，他们当然也乐于接受了。而且从大家的反馈来说，效果都不错。

5、画页面的人开始唬弄，拷贝来拷贝去。前面已经说了，画界面也是开发员在自己做的，所以基本不存在上面的问题，对于copy来copy去，拿就看公司了，确认是存在这样的问题。但久以后，不会了。

首先，每个公司都有自己的开发规范，开发规范在项目立项时就已经制定好，包括文档规范，编码规范，jsp，css，js，java，sql等，目录规范，都是有严格要求的。如果不遵守，那他就要修改，如果长期犯相同的错误，那会跟他的个人利益挂钩，考核什么的。再一个，我们都会有review机制，不符合的，自然也通不过。


你提的问题，在我采用的那么多公司中，基本没有出现错太大的问题，当然，我们公司基本都不是什么大公司。呵呵

35 楼 witcheryne 2011-05-13  

xieyanhua 的建议不错， 收益

+1

34 楼 hyj0903 2011-05-10  

java_vm 写道

我们目前用的原型工具就是axure这个工具，很好用的，效果很多都可以实现，如弹出层、对话框等，至于楼上有朋友说多人做原型的时候很麻烦，这个axure都可以实现哈，配合svn就可以了。。。。。我们目前也是几个人同时使用一个工程的！

可能是我没用好。。。

到现在为止，经过大家的意见，觉得用axure和html做界面原型比较合适。

33 楼 java_vm 2011-05-10  

我们目前用的原型工具就是axure这个工具，很好用的，效果很多都可以实现，如弹出层、对话框等，至于楼上有朋友说多人做原型的时候很麻烦，这个axure都可以实现哈，配合svn就可以了。。。。。我们目前也是几个人同时使用一个工程的！

32 楼 jnoee 2011-05-10  

我们现在用html做demo挺快的，基本上一个较为熟练的开发人员一天可以完成20+页面。

直接用html做demo有2个好处：
1. 客户的体验非常直观，基本上就是最终系统的展现。
2. demo可以直接用于开发，相当于完成了一部分开发工作。

想用html迅速的开发demo有前提条件：
1. 要有一套组件较为丰富的UI框架。（例如：ext、dwz等）
2. 需要进行一定的培训，让开发人员熟悉UI框架中的组件，从而灵活的组装自己的页面。

即便没有现成的UI框架，也建议由美工定制一套，这不单是开发demo需要的，也是页面代码整洁规范的保证。

31 楼 maxiaoxia 2011-05-09  

原来也用原型工具来着，后来发现不如直接做页面，web直接用dw,客户端的用delphi现在也用.net winform，因为很直观，也非常方便，谁都能做，比那些所谓的原型工具简便太多
首先了解功能，然后考虑布局，这时候你应该手里有些做好的模板尤其web，然后加控件，说明部分直接写到文档里面就行了，还能供开发时候参考

30 楼 抛出异常的爱 2011-05-09  

to:xieyanhua

页面上百之后.....
需求分析麻木

效率会有下降
客户看着反感,
画页面的人开始唬弄
拷贝来拷贝去

你是怎么应对的?

29 楼 sniciq 2011-05-09  

用EXT啊！！又快又好！

28 楼 peak 2011-05-09  

axure做网页原型很好。
EA做UML很好
PD做数据库很好