关于界面原型设计的再思考

昨天看了一篇ITEye上一篇关于界面原型设计讨论的帖子，其中某君的观点引起了偶的注意，他在帖子中如是说：

“个人观点，而且一直以来，都是用JSP代码，而且是基于后台框架的（根据时间情况），基本上是半成品，作出的原型后基本不需要修改（90%已经跟客户确认过）；而且我们的原型时在需求调研阶段并行做的。基本上需求完了，界面原型也完了。

以前做过的原型的程度有，界面原型，样式、风格，布局，功能基本都与真实产品一样：

1、存JSP/HTML+CSS+JS，

2、JSP/HTML+CSS+JS + 后台java代码（如Struts），只是简单的页面跳转，没有任何逻辑处理

”.....(这里省略很多此君误导偶的高论)

见原文：http://www.iteye.com/topic/1019296?page=2#2089719

昨天晚上一读完此君高论后让偶热血沸腾，便开始构思在以后的G4.Builder中要如何按照他的这个理论将界面原型设计工具设计出来的原型和后续开发无缝接轨的问题。想了一夜，想明白了：这个理论基础就是错的。如果按照此想法去实现我的G4.Builder势必被引入歧途。唉，还好醒悟得早。这也再一次警醒自己，可以开放视听，但不要轻信别人言论，要做一个有独立思考能力的人。

此君解释了为什么要建议那么做的几条原因，下面偶逐一批斗一下,交流就该碰撞，还望楼主莫见怪。

此君即本人

-------------------------

他说：

1、在做界面原型时间，基本上90%都不需要修改，开发可以直接重用，而其他方式实现，比如PPT，word，gui designer等工具，时间比较快，但是基本交互完后，100%无法供后续开发使用，即重用率为0；

偶说：

客户给你那么多做需求时间吗？你有快速生成界面又能生成代码且这个代码还能很好的无缝的被后续开发平台使用的工具吗？开发这样一个工具的成本几何？

----客户给你那么多做需求时间吗？

客户给多少时间，是在做项目立项的时候，商务上和项目经理或者相关的技术人一起确定项目完成的周期的，不是说客户给多少时间。整个项目周期确定以后，具体每个阶段分配多少时间，是项目组说的算，不是客户说的算，难道你们做项目的时候，比如项目总时间5个月，客户会要求你们必须在15天内把需求搞定? 你们会听客户的吗？

-----开发工具

1、没有想过去开发这样一个工具，但是有考虑过按照我们的UI 开发框架的基础上，做一个eclipse的开发插件，生成基本的代码。因为我们没有考虑过去实现一个什么自动化的开发工具，任何去说卖或者什么的，我们需要系统开发，而不是自动化的代码工具。而且我始终认为，有些地方是可以用自动生成，而且效果很好，我们也有，但不是软件，是我们自己按我们的需要，结合我们框架的实际，写的一些自动化程序，比如根据数据生成对应的java类，可以生成hibernate的类（包括注解，而且可以自定义自己的生成规则，那些生成，那些不生成），也可以生成ibatis的java类，也可以生成基本java实体类；运行也很简单，配置好生成规则后，写个bat文件运行就ok了，也可以通过ant，也可以直接在IDE里运行，而且在任何时候，只要你想运行就运行（一般数据库改动）；当然也许你会认为我们在重复造轮子，外面很多自动化工具。但是请注意，外面的工具都是通用，比如您现在做的G4.Builder自动化工具，能按我的要求去实现吗？外面的那些功能，能帮我生成一个基本的类，并入带各种我想要的功能吧，比如再这个类封装将数据转换为flexGird控件需要的数据格式和数据模型吗？能动态通过该类去控制页面的展示比如列宽，行高，设置是CSS吗？

所以，什么东西都结合实际，脱离了实际，说的难听点，那些东西对于我们公司或者我们的框架来说，是一无是处。不如我们写的东西好。前面说的那些东西，就是我说的，为什么我们在做demo的时候，有时候会结合我们的后台控制框架控制。当然这也需要时间，所以我有说了，要看时间

2、对于你说的自动化工具，尤其是在web成的自动化，我始终认为，尽管自动化工具可以做出很漂亮原型效果，也可以跟后台无缝结合，但是也只能是有自动化工具确定，但是自动化生成的东西，不一定与用户需求的一样，比如java后台要分5层，4层，比如我web要做js，css分离，但是你的工具不一定是这样划分的。或者说我这里想div标签，那里想用span,别的地方又想用table。当然，不是说技术上做不到。在一个，看过那么多的代码生成器，尤其是在web层的，感觉生成出来的代码，可读性和可维护性都是非常差的，比如基本的注释。我搞过质量管理，我对这些是非常重视的，因为我们的系统，是要自己维护的。

我的观点，不管什么东西，只有结合自己的实际才有用或者才能发挥最大。脱离了自己的实际需求，那么有可能不但起不到好的作用，还有可能成为绊脚石。、

-------------------------

------------------------------

他说：

2、跟客户沟通的时候，容易沟通，因为具有交互性，所有客户配合很好，大家也很容易了解彼此想要的东西；而其他工具做的原型，都不具备交互性，或者交互性非常非常的少，会导致客户不配合；我就遇到过这样的情况；让客户确认需求，让客户看原型，客户根本不鸟我们，你发给他，他都不看，然后几天后你问他有什么问题，人家说没有看~~~~~~

偶说:

做需求就是和客户面对面交互，我们要抓住的是客户的功能性需求而非在做需求阶段把时间拿去搞一些花哨的所谓的可以点击可以跳转可以提示信息的交互界面来误导客户，让客户停留在兴奋型需求上而不去深挖最有价值最能主导需求分析成败的功能需求上。这个环节，并不是说不做界面原型，要做，但要有度。

从我的实际情况，确实是这样，那个将近1000万的项目，开始就是这样，具体情况，原文里已经说明，我想你肯定也看到了。而且我没有说做需求不需要跟客户面对面的，我们也是需要去跟客户沟通了，比如需求阶段，假设2个月的需求，那么基本上前一个月，可能就主要是跟客户沟通，获取用户的需求，基本上了解后，人们再细化需求，接着就开始做原型，做好原型后继续跟客户沟通再挖掘需求；

大家都了解需求的重要性，但是我们在这个环节上做界面原型，不代表我们没有用心去做需求，不代表我们只是让客户停留在兴奋型需求上；那只是你的个人观点，你们知道我们的需求做到什么程度？

对于你的理解，我只能说，仅仅是以你的理解去看待问题，或者你们以前就是那么认为的，或者你认为我们的公司或者团队就是去忽悠客户的。你怎么就能断定我们需求阶段做的工作就是去‘搞一些花哨的所谓的可以点击可以跳转可以提示信息的交互界面来误导客户’？你怎么就能断定我们“没有深挖客户的需求呢”？你怎么就能断定“我们的原型做的过度了呢”？。原型有是否过度，不是你说的算，我没有要求大家都做到我们这个程度啊，我都说，要做成我们这样，是要具备一定的条件的，你们不具备这样的条件，要做成我们这样的效果，自然是过度了，但是我们能做到啊，说的难听点，我觉得我们做的原型不一定比你用工具的慢？我们相关的组件都相对来说都是比较全的，而且有相应的支持，比如美工，比如技术组等等。

--------------------------------

他说：

3、把风险往前提，在需求阶段通过原型，客户配合好了，需求就更好做了，分先也少点了，而且设计阶段的工作提到了需求阶段，将界面设计不符合客户要求的时候，而且也能极少发现我们做的是不是客户想要的。因为如果到设计阶段再去考虑界面，而且一般都是在开发到一定阶段或测试的时候，客户才会介入，此时发现设计不符合客户要求的时候，那就要修改，风险就更大了，因为往往到编码阶段，是最紧张的时候，而且时间的问题更加明显。

偶说：

在需求阶段穿插一定的界面原型设计目的是要辅助需求分析人员更好更顺畅的和客户进行交互沟通。并非是把界面设计的工作往前提，更不是要让客户确认以后系统的界面就是长这么个样子了.一般来说客户是不会来干预你的界面的，你做的再漂亮设计得再艺术对于客户来说只是兴奋需求，所以说风险在于功能型需求而非兴奋型需求。

我们做界面原型，不否认，在需求阶段确实是让客户顺带确认了界面原型。但是不代表我们就没有做好用户需求的挖掘啊?我也说了，界面原型提高了我们与客户之间的需求理解能力以及沟通能力，那么我们有具备这个条件顺便做好系统设计（原型），我做了也没有什么不可以啊。

-------一般来说客户是不会来干预你的界面的

那是你没有遇到那样的客户，你说客户不在乎界面是什么，那是你可能没有遇到那样的客户，我们就遇到过，比如上面说的那家世界有名的企业，涉及客户近30个财务部门的需求人员，每个人的观点都不一样，这个说那样放，那个说这样放；还有，客户提供的excel报表，我们按她给的报表一模一样的设计出来（客户要求），包括颜色，结果在讨论需求和确认的会议上，人家发标了说，怎么做的那么难看（每个人的审美观不一样，其实不难看），我们说了，是按你给的excel样子做，人家说什么，人家说那我的在excel上看的很好看啊。中途在该原型的过程，今天这样该，明天那样该的情况不少见。

-----风险在于功能型需求而非兴奋型需求

我想没有否认功能性需求的重要性，但是你能说非功能性需求就不重要吗，但是可能你所指的功能性需求仅仅是UI而已，实际还包含了很多，比如性能等；那我们就说UI，UI的展现显示，有的可能很简单，改改也花不了多少时间，但是有些展示，就有可能涉及到你的实现，你的数据，你的设计问题，那就不是你说的那么简单了。我们就遇到过，还好，用户是在实现阶段提出来的（改变他们的需求展现，也就是UI了），那个改动，就是伤筋动骨，把原来的设计实现全部推翻了，必须重新设计实现。这个风险算不算大，加入这个问题是到了用户验收测试了才提出来，那时候时间已经不多了，你怎么处理，算不算是风险呢？？所有功能模块都实现完以后，再大概程序，请问还有多少时间给重新去修改需的问题，或大的改动，当然你可以说提需求变了，加时间了或者说我们设计不好了！但是就算是简单的修改，如果很多要改，这算不算风险。

   有的项目是政治任务，时间点必须完成，超过一个小时都不行，比如我去年的一个项目，时间点是卡死的，人家客户的N十年大庆，项目必须在大庆前上线，而且不能出问题，大庆上要演示系统，行业上全国各大有名的公司老总都来了，市级领导、省部委的重要领导（包括省长，国家Xx部的领导），你能出点问题吗，我们但是赶这个项目，加班，通宵是常事，请问哪个情况下，你们UI问算不算问题，严重不严重？？？当然这种情况不多见。

------------------------------------

他说：

4、界面原型好了后，因为90%的功能界面客户都已经确认了，所以后期大范围修改界面原型的情况几乎是不可能的，除非需求有很大的变动；而且我做的界面的基本交互已经模拟出来了，比如按某个按钮会怎么处理，有些都会模拟出来，实在不容易实现或时间太急就暂时不实现，跟客户沟通的时候会跟他解释；所以到编码阶段，开发员基本不用管太多的界面处理，基本上只专注于自己的后台逻辑实现，页面就往里套数据就ok了，开发也很happy；

偶说：

客户需求阶段出来的界面原型只是辅助需求分析的一个输出成果。给后续设计阶段(包括界面设计)的一个参考。此是需求才做结束，你弄出来的那个原型就能说以后很少修改？？连库表结构什么样都不清楚，这种做法那你可能得在需求时候把设计全做了，回来就可以直接进入代码实现阶段了.这似乎是个一点也不好笑的笑话。

这个只能说，每个公司要求不一样，每个公司有自己的最佳实践，你认为不可能的，不代表别的公司或团队不可能。我们需求阶段出界面原型，确认输出输入字段，基本的处理流程，但是没有说数据库设计也做了，当然有些简单的数据表，也基本上需求的那些东东，也不存在什么设计不设计。但是你认为不可能的，在我们的团队里就是把它变为了可能。

我一再强调，每个公司要求不一样，你们仅仅是把需求阶段的原型作为辅助的东西，不作为后前实现的一部分，所以你那么认为，而我们的认为需求阶段做出的东西，在能实现的前提下尽量达到实际系统的要求，不需要做过多的改动。我们对意见的标准不一样，所以在你那存在问，但在我们这不存在问题，或者问题不大。

就像很多公司很要求质量，很多公司不重视质量一样，有些事情对于你们来说不可思议。比如我们要求的每个阶段的输出都有严格的质量要求，比如文档，比如编码，比如注释，比如review机制，比如我们的自动化。从代码基本规范，到注释，程序存在的隐含的bug，质量报告，测试报告，编译，测试，部署，各个阶段中的相关结果告知相关人员，比如编译出错等等，都是自动化的，然后再辅助少量的人工review等，自动化可以帮我们做了很多事情。对于我们来说，这是很easy的事情，对于你（或者很多公司来说）来说，恐怕又是不可思议的事情。但是你认为的不可思议，不代表别人不能实现。

-----------------------------------

下面偶简单说一下偶结合自己经历过的项目并结合今天界面设计这个话题总结出来的一个界面设计环节软件过程，欢迎大家拍砖：

1.大家肯定会纠结过这样的问题，在软件过程中我们到底要不要做界面设计？界面设计在什么时候做？界面设计用什么工具做？界面设计的输出是什么？做界面设计付出的成本和带来的效益如何？

界面设计必须得做，而且要两份。

一份就是和需求一起的以需求附件形式输出的界面原型。这个界面原型可以使用pencil等界面原型设计工具来超级快速的实现，他会有很多缺陷比如显示字段不全，布局摆放不合理等等。但这都是正常的，因为他只是在和客户需求交流时的一个附带输出。他的意义在于辅助说明需求分析，给后续的设计提供参考。比如，我下面一份图所示：(只用了5分钟就画出来了)

对于你这个功能，我们也可以在5分钟内出来啊，甚至不需要五分钟（当然展现形式不一定跟你的一模一样（毕竟我们的组件是结合我们的展现，而不是像你这样的展现），但是就是查询，显示信息和grid展现的功能），当然，不包括页面控制逻辑(js)，我不知道你的是否包括页面js的逻辑控制。但是如果要我们做的跟你一模一样的展现，说实话，可能30分钟也出不来，但话又说回来，如果用你的工具做做我们一模一样的展现，如果你不修改你的工具的实现代码，估计一辈子也做不出来（仅仅是估计，不要钻牛角尖）。

-----------------

另一份就是在需求分析的基础上做了概要设计(含数据库设计)，并在进行功能模块详细设计的时候出来的。我觉得真正意义上的界面设计应该是和功能模块详细设计并行的，只有在有了库表对具体功能模块进行详细设计的同时也才出得来在代码实现阶段能直接以此为模版进行开发的界面设计。此阶段的界面设计我认为很重要，第一：界面元素界面风格界面布局方案小到一个很小的元素和页面边距是多少的细节都要在此界面设计中反映，代码实现必须按照这个界面设计来做，如果不按照这个界面做，到时候自由发挥出来的界面那就可以让开发人员自己改到统一风格上去，这是开发人员也没什么话说。第二：界面设计和详细设计是相辅相成的，界面上放置的任何一个元素肯定是和后台有一一关联关系的，并不是随便乱放。而后台设计也决定了界面元素甚至是界面布局。这样就互相促进，是设计人员考虑得更周全，而不是写个设计文档出来，界面什么样也不知道。到时候开发人员看这个这个纯文字的设计就去画界面，这样不仅风格不统一而且设计文档的质量考虑的是否周全都大打折扣。界面设计文档可以单独出报告也可以和功能详细设计报告合并。

下面是偶在做功能模块详细设计的同时在需求分析阶段出的界面原型基础上做的界面设计，如下图所示：

当然界面设计不应该仅仅是一张图，还应该辅以文字说明一些控制逻辑、约束规则、跳转逻辑等等。

最后做个广告哈：)

eRedG4(易道系统集成与应用开发平台)是一个开放源代码的、面向企业计算环境下异构系统集成与行业应用快速二次开发的平台。

您可以通过下面的地址获取到G4最新版本和相关资源：

GoogleCode项目主页

http://code.google.com/p/g4-xiongchun/
在线演示系统暨G4平台在线交流社区

http://web230531.host89.chinajsp.net
eRedG4平台总设计师个人博客

http://hi.baidu.com/eredlab