关于界面原型设计

to:xieyanhua

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

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

你是怎么应对的?

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

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

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

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

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

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

可能是我没用好。。。

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

xieyanhua 的建议不错， 收益

+1

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机制，不符合的，自然也通不过。


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

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

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

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

这些都是必须的功课。

基本上我们的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等
• 我们的需求文档，或者说需求阶段的工作，实际是包含了一些设计阶段的工作，比如数据长度限制，数据字典的选项及其选值范围，数据类型，反正能确定的都确定了，到时候数据库的设计就差不多了，至少取值什么的都不会变化太大；当然页面原型就不用说，可定是设计阶段的工作了，但是你可以看到，我们的界面原型就是正事系统的效果，基本上是不需要修改的。
• 之所以这么细，主要是让开发元拿到这个需求，就知道要做什么，怎么做，做成什么效果（原型），有什么要求，限制等，这样不免得到编码阶段，开发元还要挖心思去想我要怎么画页面，怎么布局等等，影响开发效率。对数据的要求，详细的话，在设计数据库的时候，很多久不再需要考虑太多，直接就可以用，或者有比较详细的参考，设计起来也比较容易，至少不需要考虑什么数据格式啊，什么选值的问题了。