程序界面设计

设计“好看”的用户界面（王咏刚 2003年10月）1 问题引入两周前，我的一个朋友小W找我聊天，跟我说了件烦心事儿：他们公司开发的一套行业软件在竞标时败给了竞争对手；当时，用户给出的理由是，小W他们的软件界面粗糙、简陋，看上去远不如竞争对手的界面那么专业。

当然，小W和我都明白，对于竞标失败而言，这个理由并不充分——在行业软件市场上，大多数竞标失败都有着更深的背景原因，比如客户关系的好坏；但在公开场合里，软件性能、售后服务、用户界面等更为冠冕堂皇的理由却总能成为客户拒绝你的最好托词。

为了不在今后的竞标中被客户和竞争对手轻易抓住把柄，小W下决心改进他们的软件界面。

经过研究，小W和同事们发现，他们公司开发的所有软件几乎都存在用户界面粗制滥造的通病。

程序员们经常随心所欲地设计窗口、摆放控件，图标、字体和颜色的使用也没有统一的标准，由此开发出来的软件尽管在功能和性能上都表现得非常出色，但界面大多简陋不堪，一眼看上去就像是土法烧制的陶盆儿陶罐儿——单独摆在桌上还不觉得怎样，一旦和官窑里烧出的上等瓷器摆在一起，立马就会相形见绌，惨不忍睹。

为了改变现状，小W他们的第一反应是请专业的美工来主持界面设计工作。

小W说：“好看不好看的问题当然属于艺术范畴。

程序员们都是工程师，没有半点儿艺术头脑，再怎么折腾也是白搭。

所以，我们一定要请专职的平面设计师来设计界面，程序员只要按照设计师的思路编程实现就行了。

”这个主意听上去不错，小W也的确从广告公司请来了一位平面设计师。

“当然，像麦肯、奥美那样的大广告公司我们也请不起。

我们请的那人是专做平面设计的，身价不高，在行里却也小有名气——当然，比我们这些外行强多了。

”“那么后来呢？”我喝着咖啡不怀好意地问，那情形就像是电影《绿茶》里姜文在向赵薇刨根问底。

“后来？要是后来一切都OK了，我还找你干什么？”小W把一肚子苦水倒在我面前。

原来，平面设计师来到小W的公司以后，工作还算努力，也画出了许多漂亮的界面设计稿，但程序员们就是没法把这些设计变成现实：要么是设计出的界面像游戏软件的界面一样动感十足，让人难以接受（用户方的领导绝不会容忍下属们对着游戏画面优哉游哉地完成日常工作）；要么是设计出的界面与软件的功能自相矛盾，必备的功能没法融入到界面之中（比如，为了保证美观，设计师限制了子窗口的大小，结果好几个控件就找不到立锥之地了）；要么是界面设计得过于前卫，根本就无法用现有的窗体或控件技术实现……光是这些技术问题还不算什么，最要命的是，设计师经常对程序员们指手划脚，总是说“你们不懂，这是艺术规律”。

结果，艺术规律败给了严酷的现实：当平面设计师给出的方案一次又一次被程序员们否决，大多数程序员开始消极怠工了，几乎所有人都放下了手头的工作，一边摇头一边嘟哝：“界面都定不下来，还编什么程序？”。

“你说，我该怎么办呢？”小W痛苦地问。

“你说呢？”我幸灾乐祸，一脸坏笑。

2 一些题外话像其他软件开发环节一样，用户界面设计也可以借助一些现成的工具。

有一次，我们要为客户准备一个产品方案。

方案里的好几个软件模块我们从来就没有真正实现过（这种“空手套白狼”的做法在行业软件市场里相当普遍）。

为了让我们的方案更有说服力，售前工程师们干脆用制图软件Visio 里的用户界面绘制功能，把尚未问世的软件模块画得有模有样，窗体、菜单、按钮、工具栏、对话框等界面元素也都一应俱全。

在方案里集成了这些界面图片以后，半数以上的用户就不会怀疑这套系统的真实性了——毫无疑问，这也是一种界面设计工作，尽管其中有些招摇撞骗的味道。

应当说，要描述和展现用户界面设计方案，最直观的方法就是把界面的样子画出来。

在程序员看来，白板或稿纸上的一张界面示意图往往就能说明所有问题。

不过，当我们需要在不同的开发环境中交换设计方案，或是要管理和检索界面设计文档的时候，图片信息就不如格式化的文本信息那样方便了。

为此，人们陆续设计出了许多“用户界面描述语言”。

利用这些语言，我们可以像编写程序那样“编写”用户界面。

比如说，Delphi中用来描述窗体特性的*.dfm文件，其中的文本内容就是一种相当不错的用户界面描述语言。

与其他描述性语言类似的是，用户界面描述语言也有标准化和XML化的倾向。

迄今为止，人们已经提出了AAIML、AUIML、XIML、XUL、UIML等一系列基于XML 标准的用户界面描述语言①。

W3C正在制订的XForms标准②也是XML家族的一员，它很可能成为未来设计和开发Web用户界面的核心技术之一。

有关用户界面描述语言的研究和探索工作的确有助于用户界面设计的标准化。

如果有哪一种用户界面描述语言真能成为业界公认的标准，并进一步促使所有可视化开发工具在描述用户界面时都使用统一的数据格式，那我们在开发过程中，也许就能把Visual Basic .NET的窗体设计直接粘贴到VisualAge、Kylix或是C#Builder的开发环境里——这对于需要在不同环境下开发软件的程序员来说，当然是梦寐以求的一件事了。

3 案例分析在本文的案例中，我的朋友小W为了软件界面好看不好看的问题而苦恼万分。

他所选择的解决方案——聘请专职的平面设计师——看上去不无道理，但实践起来却困难重重。

我个人认为，这里面最主要的原因是：除了游戏等少数需要炫耀外观的软件之外，大多数软件的界面设计其实并不等同于通常意义上的平面设计。

举例来说，一个没有编程经验，又不了解用户需求的平面设计师，他可以给出漂亮的图标或配色方案，但他多半说不出下拉列表框和组合框在用途上的差异，他也不一定知道菜单项和工具栏按钮该如何排列才符合用户的使用习惯，至于像“预览对话框该选择有模式对话框还是无模式对话框”或“哪些控件需要使用上下文菜单”等更为专业的问题，他恐怕就更加束手无策了。

最重要的是，没有软件开发经验的平面设计师和普通的程序员之间很少有可以互通的专业语言：设计师们难以理解配置管理、螺旋模型等软件工程术语，程序员们也不大明白矛盾空间、非对称平衡等设计专业名词。

应该说，小W的公司里程序员和设计师之间的龃龉恰恰起因于缺乏共同语言的两类人难于相互交流。

那么，是不是应该有一个“用户界面设计师”的职业，专门负责软件用户界面的研究与开发呢？没错，国外许多规模较大的软件公司都为项目组配备了专职的用户界面设计师，微软公司还在其微软解决方案框架（MSF）中明确指出项目组必须设置用户体验角色（User Experience Role）以增强软件的可用性③。

不同公司对该职位的称谓和定位可能不尽相同，但大多数公司都要求这些专职的用户界面设计师兼具软件原型开发、用户需求管理和图形界面设计等三方面的能力。

这里面的道理非常简单：首先，如果设计师对软件开发一无所知，程序员们早晚会把他轰出项目组；其次，如果设计师不能理解用户需求，那他和一个只知道显摆前卫的行为艺术者就没什么分别；最后，如果设计师没有平面设计的根基，那他岂不连最后一点存在的价值都没有了吗？下面是我最近从网上摘录的，美国一家软件公司招聘用户界面设计师时对应聘者水平的要求：z拥有计算机科学或相关专业的学士学位；z熟悉用户界面设计的基本原则；z善于将业务规则、用户操作和功能需求转化为软件特性；z至少在一个项目中有过用例分析和UML建模的经验；z能够使用Java Swing设计用户界面；z能用JSP设计Web应用程序的界面；z能够使用脚本语言快速开发软件原型；z能熟练使用Photoshop、Illustrator和Dreamweaver软件；z对用户界面的美学特征和可用性有较强的判断和甄别能力；z善于在团队中工作；z优秀的口头和书面表达能力。

怎么样？这个要求蛮高的吧？这更加形象地说明，要设计出最漂亮、最优秀、最出类拔萃的用户界面，软件开发、需求管理和平面设计这三样技术缺一不可。

“打住，打住！”小W已经怒火中烧了，“你这不是逗我玩吗？要请这么一个界面设计师得花多少钱哪？我们公司可没这个实力！”没错，大多数中小型软件公司没能力聘请专职的界面设计师。

不过别忘了，我上面说的是理想情况。

聘请专职的界面设计师固然可以开发出最漂亮的软件界面，但没有界面设计师的参与也不意味着只能破罐子破摔。

我们的目的是把界面设计得尽量好看，但“好看”有多重标准，不同的行业，不同的市场，对“好看”的要求也不尽一致。

如果你要开发的是游戏软件或艺术网站，那你恐怕就只有雇佣最出色的艺术家来绘制用户界面了。

但是，如果要开发的只是普通的行业软件，你根本没必要把软件界面打造得像MSN Explorer一样异彩纷呈。

对于小W他们的软件来说，只要保证用户界面简洁、大方，易于操作，与流行的软件风格保持一致，用户就不会再有什么意见了。

“要做到这一点，”我斩钉截铁地说，“根本用不着什么界面设计大师，你们公司的普通程序员就完全可以胜任。

当然，得让他们掌握一些用户界面设计的基本准则。

”经不住小W的软磨硬泡，我拿起纸笔，搜肠刮肚，好容易写出了下面这些我认为重要和值得推荐的界面设计准则：根本大法在用户界面好看不好看的问题上，“东施效颦”的做法通常比“推陈出新”更为有效。

这很容易理解，一个在窗口布局、色彩搭配、字体风格等方面处处模仿微软Windows的程序员虽然很少能享受到艺术创新的快感，但他开发出的软件却总是有着和Office或IE一样“好看”的界面。

软件已经发展了这么多年，每一类软件都有其流行的界面风格和设计惯例。

既然不是界面设计大师，就不要满脑子标新立异，老老实实地照猫画虎总不会有错。

主窗体布局主窗体（或称主窗口）是图形用户界面的核心。

主窗体中有菜单、工具栏、对话框、客户区、状态栏等各式各样的界面元素。

对普通程序员来说，安排这些界面元素的规则只有一条：如果在流行的商业软件（特别是微软的软件）中找不出你使用的布局方式，那么千万别犹豫，赶快否定自己的设计吧。

例如，我曾见过这样一个软件界面（见图1）：图 1 数据视图的简单堆积在图1所示的界面中，程序员把三个数据视图（两个表格和一个多行编辑框）排列在主窗体右边的客户区里。

主窗体和三个数据视图都有各自的滚动条和可视区域。

这种简单堆积数据视图的做法，只能造成一种后果，那就是一眼看过去到处都是滚动条，每个区域都可以滚动。

新上手的用户根本想不清楚该用哪个滚动条来寻找自己需要的数据。

从实现层面讲，这种做法也需要程序员小心地维护所有视图的大小和相对关系，以避免主窗体的大小变化引起客户区的混乱。

相比之下，把数据视图放在不同的子窗体或属性页中的做法就会让窗体布局更为简明有序。

控件排列整齐，一定要整齐，任何不整齐的用户界面都不是好界面。

窗口和对话框中的所有控件都必须整齐排列。

实际上，几乎所有现代可视化开发环境都为我们提供了调整控件大小、对齐控件以及等距离均匀排列控件的工具。