在软件设计前先画界面图

hennry注:

需求<-同时做->界面（html/css) 　<-->  开发

不过最好用“快速后台数据”填充界面

画出全部（几乎）界面图好似不敏捷？疑问？

 

在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式 。
总是有人抱怨在需求和软件设计之间仍然有很大的鸿沟需要填补，这是至今仍然未能有效解决的软件工程难题。多年以来，有很多人一直在寻找从需求到设 计的直接的形式化映射方法，但是收获很少。实际上软件工程对于软件生命周期前面的那些阶段并没有多大的帮助。为了响应 o6z 说的努力在在现有技术基础上杀死人狼的号召，我来推荐一种有效的设计方法。

这种方法其实非常简单，就是不要急于从需求转到软件设计，而是根据需求文档（可以是传统的需求说明书也可以是用例）先画出系统的界面图来。用什么 画图呢？你可能立即会想到 Word、Visio、ROSE 一类的工具，我现在告诉你这是错误的做法。你应该采用最快的方式把界面图画出来，因为界面图主要是用来交流的 （是给人看的而不是给机器看的），所以你不需 要太拘泥于形式。你找些白纸和一支铅笔 ，马上就可以开展这项重要工作了。如果用白纸和铅笔，我一天最多可以画 20 张界面图，但是用 Word 我的速度可就慢多了，因为我还要考虑排版、美观等等无聊的细节。
你要把界面的布局画的详细些，起码界面上所有的功能点（比如所有的按钮和超链接）应该全部画出来。不仅要画出第一级页面 ，那些第二级页面、弹出 页面、子页面 也都要画出来。他们之间的逻辑关系和导航关系 都要明确地标记出来。你最好尽量考虑的细致一些以便页面制作人员（实际上我们是由程序员自己来制 作页面 的，可能又会引起某些人的惊诧和愤慨了）可以参照这些界面图不需要费什么脑子就能顺利把页面做出来，而不是他们做出来后你又要告诉他们这个地方不对 那个地方不对。如果你能把这些界面图全部想象出来并且能细致地画在纸面上（当然这个工作并不象这里说的那么容易），那么系统该做成什么样子你就胸有成竹 了。 使用这些界面图来进行讨论也会比较具体和深入。需求文档总是给人以不够具体的感觉 ，界面图画出来后，需求就非常具体了（一目了然，程序员因为直接参与这项 工作，因此对于需求非常清楚，做开发的时候可以大量减少由于理解上的问题而产生的 bug）。而且还可以根据界面图的数量和复杂度估算工作量，和客户讨价还价的时候心里比较也有底 ，客户对我们估计的工作量也比较信服。当然你还要尽量把界 面设计的美观大方而且容易使用，这方面可以参考我上面介绍的那本书和 Alan Cooper 的《软件创新之路》。

这些界面图需要讨论上两到三次才能定稿，讨论的时候最好能有最终用户的参与 ，以便尽早获得他的反馈。在这时候发现需求理解上的错误，修改只需要在白纸上重新画几张界面图，成本可以说是最低的。定稿后这些界面图要作为重要的项目文档归档保存。

下一步工作是根据界面图制作出页面 ，这里我指的是正式的页面（而不仅仅是一个由超链接形成的界面原型），包括全部的 JavaScript 脚本。我们现在创造了一种新的开发方式，可以完全不做后台的开发把全部页面制作好 。然后再写后台的代码和配置。因为我们目前工作量的大约 2/3 集中于前台的页面和 JS 上 ，所以页面全部做好后可以说 2/3 的工作量就已经完成了。

有很多的经验都是软件工程的经典教材中所没有的，难道我们就可以忽略这些经验了吗？有那些项目组是采用这种方式来做开发的？

 

其实真的没有什么神秘的，只要你想做，你也完全可以画的出来的。基本上和你们将来做好的页面是一样的（当然可能还会有一些修改，但是结构布局在讨 论结束时候就已经完全确定了，美工需要帮助我们的只是调整一下配色、做几个漂亮的图片和有立体感的按钮等等）。画界面图是非常重要的工作，有经验的开发人 员在画界面图的过程中实际上已经在思考系统如何设计和开发了，并且会尽量将界面设计的易于开发，因为这些工作都是将来自己要做的，所以他会尽量不把自己逼 进死角。
由程序员（当然我作为 PM 要领着他们一起做）来控制页面结构布局是非常重要的，因为只有程序员最清楚系统应该做成什么样子。当然要对程序员的审美能力做一些必要的培训，页面布局要美观大方，不能太难看了。如果有这方面的问题，在讨论时起码我这一关就通不过。

我为什么这么重视界面，因为这确实是非常重要的工作，原因在《软件创新之路》中已经写的很清楚了。界面是软件最重要的外部质量之一，我曾经在这方面摔过跟头 ，不想再犯同样的错误了。

 

我再补充一下，不是需要画完所有的界面图才可以做软件设计的（那样又堕入了“瀑布模型”的老路上），而只是需要完成主要的场景就可以 了，只要这些功能场景 相互独立，并且确实可以独立完成而彼此没有影响。在一个增量开发 的团队中，需求搜集、画界面图、软件设计、开发是经常进行的工作。

经过我们长期的思考加实践，我们现在完全有能力定制出一种真正适合于我们的开发过程了，根本就不需要去照搬 RUP、XP、FDD、ASD、Crystal，那只是没有经验的开发团队所热衷的事情。而我实际上并不认为一个标准的过程是杀死人狼的关键，这个观点在 《软件工艺》第 15 章：“软件工程隐喻的危害”中已经阐述的很清楚了。

实际上画界面图是对系统的一次建模过程 （或者说是一次在开始建造前宝贵的思路整理过程）。如果你能细致地画出系统的界面图，你就非常清楚地知道自 己要做什么和系统将来会做成什么样子，而我相信你也一定能做的出来。毕竟知道如何做相对于知道需要做什么还是简单的。如果你连在白纸上都无法画出系统的界 面图，我如何能够相信你能做出来呢？ 不是你的技术不好，而是你对要做什么根本就没有深入思考过，根本就没有概念。即使你有匹夫之勇，我如何敢确信你肯定能做出用户真正需要的软件产品来呢？

至于以后的软件设计，我仍然建议你在白纸上做设计，而不是依赖于 ROSE、Together、PowerDesigner 这类的工具。当然我更愿意把这归为个人的爱好，仅供大家参考。

 

其实大家可以看出我关于这个问题思考的转变。在最初的时候我们确实是一开始就直接做界面设计的。随着对这种开发方式理解的深入，以及《面向使用的软件设 计》对我的帮助，我认识到其实首先还是应该搞清楚用户真正想要完成的任务 ，然后再开展交互设计来支持用户想要完成的任务。基本用例就是用来描述用户想要完 成的任务的，编写基本用例的过程就是任务建模的过程。界面设计是必须要认真做好的，但是直接做界面设计（无论是在纸上还是使用 RAD/CASE 工具）确实会造成某种程度的局限。

 

dlee

我没有看过《敏捷建模》。这种方法是我们自己试验过觉得效果不错的方法。我们对界面图是分成为界面图设计和界面图制作两部分（感觉没有必要按照某本书上那 样分，我觉得保持我们自己的特色没有什么不好）。界面图设计就是在白纸上画界面图，要达到能够直接制作页面的详细程度，所以就不只是界面流程图了。
程序员制造的 bug 有很大一部分是因为他不理解需求（根本就不知道要做成什么什么样）造成的，这样的方式程序员很早就参与进来，就会大大减少这样的问题。

上次庄表伟说 XP 中从来没有界面设计人员的位置，我觉得这确实是一个问题。哪怕象我们这样由程序员来做页面，也至少应该有界面设计师这样一个角色存在。

确实比较适合 Web 开发，至于这种开发方式是否还适合其它类型的开发我还没有想过。

 

呵呵，我也是在仔细阅读了《面向使用的软件设计》后再看 Word 这样的软件，感觉到有了很多新意，对于其中一些地方为什么要设计成这样有了比较深入的理解，同时也发现了一些可用性方面的问题。因为 M$ Office 大家用的很多，非常熟悉，所以这本书里面的很多反例都是拿 Office 举例的（一个现成的靶子）。不过 M$ 确实在软件的可用性方面下了很大的功夫。Linux 应用软件要想占据桌面的一席之地，在可用性方面也需要下很大的功夫。

我其实是倾向于 ddd 的看法的，而不大同意 o6z 和 notyy 的意见。界面设计不能等同于原型，界面设计以及对于用户 如何使用软件 应该在很靠前的阶段就加以充分考虑。我的意思只是说在界面设计之前还应该有一个 任务建模 的 阶段，要完全搞清楚用户想要使用这个软件来完成什么任务（是用户真正的目的，而不是程序员惯用思维所强加给他要做的一些事情，例如敲键盘）。界面设计对于 细化需求确实有非常大的帮助（使需求变得非常具体），这一点 o6z 说的很对。 不过不要一上手就画界面图 ，那样未必能得到支持用户完成任务的最佳的交互设计。当然界面设计和软件设计未必一定要有明确的先后顺序，适当的时候 并行进行是有可能的。

另外再澄清一下一些比较容易混淆的概念：
界面设计 != 交互设计，界面设计是整个交互设计中的一个阶段。
界面设计 != GUI，在《面向使用的软件设计》中举了一个嵌入式系统使用声音和信号灯做界面的例子。GUI 做的再花哨，如果没有进行过深思熟虑的设计，在可用性方面未必一定比字符界面更好。
易用性不是交互设计的唯一目的，一个好的软件应该对于初学者和熟练用户都能提供很好的支持。对于熟练用户，易用性并不是他们主要关心的目标，他们更关心的是完成任务的效率。所以我很少说“易用性”，而总是说“可用性”。
“使用鼠标即可完成全部操作”，只是做了一半工作，一个可用性非常好的软件，应该使用键盘就可以完成所有使用鼠标可以完成的操作。因为熟练用户更喜欢使用快捷键的操作方式，可以达到更高的效率。

 

o6z

dlee可能你把界面图和界面流程图的概念搞混了，你的意思大概是应该先完成界面流程图，界面图这个东西可以在完成界面风格定义以后的任何时候进行完成。
这个界面流程图是我认为进行一个软件设计的第一个图，同时也是功能分析的时候需要考虑的一个图。但是似乎只有在《敏捷建模》这本书中才提出过这个概念，真的很遗憾。不过我知道很多人都在使用这样的一个工具进行他们的工作。
这个图示非常的直观，当然如果你愿意使用一些真的界面表示这个图示也是很有意义的，不过内容其实是一样的。

 

o6z

其实很多行之有效的东西都是我们自己总结出来的，但是过后一看很早以前就有人在用了。这不能不说是一种交流的不充分的结果，但是也显示出其实有效的东西会在不同的环境中自然的发展起来。

liloboy
另外的原因也是不自信还有越是简单有效的东西我们就会越去忽视去promote它.
因为那个比起什么OO,什么Use Case理论什么的都不值一提,根本没有"学术价值"

 

o6z

快速原型和界面流程图不是一个概念，快速原型是一个实实在在的程序，而界面流程图只是一些图示。

 

flyisland

我碰过一些朋友，他们是是直接用html做出界面来（包含页面跳转），可以认为是一个最简单的原型。
然后用这个原型和客户进行交流，有不一致的地方就修正，OK后就以此为基础开发。
而且他们有工具可以根据html原型生成structs框架，所以对开发速度提高很多。

 

esmile

界面设计是产品开发前期一项非常重要的工作。可惜很多的程序员是对这个不屑一顾 的,认为那只是美工的事而已.界面是否美观，布局是否合理，操作流程是否符合end user的习惯，需要认真考虑!

现在我们在做的这个产品(不是C/S,B/S的,MFC写的application),就是程序员和美工配合,在软件设计前先用Dreamver 画界面图,而且很详细,可以说每个细节都实现到了,90%的界面都出来了.同时反复的和业务人员交流,然后修改,消除理解上的误差.以前我们做开发时也不 是像这次这样做得这么详细,以前也只是在需求文档里有一些主要界面的图片(占30%左右),然后在开发时让程序员去"发挥",去定义具体的界面.我们这次 也是个尝试,想看看两种不同的开发流程会有什么不同?哪一种更加有效?

 

在设计界面过程中,确实由于自己直接的参与了更多细节的界面设计而对整个产品的需求更加清晰了,这对我后面框架的设计帮助很大.

这点是我目前不好掌握的.也就是说,界面设计到什么程度才是最划算的?这个火候怎么来把握?

做这种详细的界面设计是需要花费一定的时间的.我们现在模拟了整个产品的90%的界面,说实话,我自己都觉得是否有点过?这个只能等这个产品做完了才能从总体开发的角度来做一个评价了!