设计“好看”的用户界面
（王咏刚 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）
以增强软件的可用性③。不同公司对该职位的称谓和定位可
能不尽相同，但大多数公司都要求这些专职的用户界面设
计师兼具软件原型开发、用户需求管理和图形界面设计等
三方面的能力。这里面的道理非常简单：首先，如果设计
师对软件开发一无所知，程序员们早晚会把他轰出项目组；
其次，如果设计师不能理解用户需求，那他和一个只知道
显摆前卫的行为艺术者就没什么分别；最后，如果设计师
没有平面设计的根基，那他岂不连最后一点存在的价值都
没有了吗？
下面是我最近从网上摘录的，美国一家软件公司招聘
用户界面设计师时对应聘者水平的要求：
.. 拥有计算机科学或相关专业的学士学位；
.. 熟悉用户界面设计的基本原则；
.. 善于将业务规则、用户操作和功能需求转化为软件特性；
.. 至少在一个项目中有过用例分析和UML 建模的经验；
.. 能够使用Java Swing 设计用户界面；
.. 能用JSP 设计Web 应用程序的界面；
.. 能够使用脚本语言快速开发软件原型；
.. 能熟练使用Photoshop、Illustrator 和Dreamweaver 软
件；
.. 对用户界面的美学特征和可用性有较强的判断和甄别能力；
.. 善于在团队中工作；
.. 优秀的口头和书面表达能力。
怎么样？这个要求蛮高的吧？这更加形象地说明，要
设计出最漂亮、最优秀、最出类拔萃的用户界面，软件开
发、需求管理和平面设计这三样技术缺一不可。
“打住，打住！”小W 已经怒火中烧了，“你这不是逗
我玩吗？要请这么一个界面设计师得花多少钱哪？我们公
司可没这个实力！”
没错，大多数中小型软件公司没能力聘请专职的界面
设计师。不过别忘了，我上面说的是理想情况。聘请专职
的界面设计师固然可以开发出最漂亮的软件界面，但没有
界面设计师的参与也不意味着只能破罐子破摔。我们的目
的是把界面设计得尽量好看，但“好看”有多重标准，不
同的行业，不同的市场，对“好看”的要求也不尽一致。
如果你要开发的是游戏软件或艺术网站，那你恐怕就
只有雇佣最出色的艺术家来绘制用户界面了。但是，如果
要开发的只是普通的行业软件，你根本没必要把软件界面
打造得像MSN Explorer 一样异彩纷呈。对于小W 他们的
软件来说，只要保证用户界面简洁、大方，易于操作，与
流行的软件风格保持一致，用户就不会再有什么意见了。
“要做到这一点，”我斩钉截铁地说，“根本用不着什
么界面设计大师，你们公司的普通程序员就完全可以胜任。
当然，得让他们掌握一些用户界面设计的基本准则。”
经不住小W 的软磨硬泡，我拿起纸笔，搜肠刮肚，好
容易写出了下面这些我认为重要和值得推荐的界面设计准
则：
根本大法
在用户界面好看不好看的问题上，“东施效颦”的做法
通常比“推陈出新”更为有效。
这很容易理解，一个在窗口布局、色彩搭配、字体风
格等方面处处模仿微软Windows 的程序员虽然很少能享
受到艺术创新的快感，但他开发出的软件却总是有着和
Office 或IE 一样“好看”的界面。软件已经发展了这么多
年，每一类软件都有其流行的界面风格和设计惯例。既然
不是界面设计大师，就不要满脑子标新立异，老老实实地
照猫画虎总不会有错。
主窗体布局
主窗体（或称主窗口）是图形用户界面的核心。主窗
体中有菜单、工具栏、对话框、客户区、状态栏等各式各
样的界面元素。对普通程序员来说，安排这些界面元素的
规则只有一条：
如果在流行的商业软件（特别是微软的软件）中找不
出你使用的布局方式，那么千万别犹豫，赶快否定自己的
设计吧。
例如，我曾见过这样一个软件界面（见图 1）：
图 1 数据视图的简单堆积
在图 1 所示的界面中，程序员把三个数据视图（两个
表格和一个多行编辑框）排列在主窗体右边的客户区里。
主窗体和三个数据视图都有各自的滚动条和可视区域。这
种简单堆积数据视图的做法，只能造成一种后果，那就是
一眼看过去到处都是滚动条，每个区域都可以滚动。新上
手的用户根本想不清楚该用哪个滚动条来寻找自己需要的
数据。从实现层面讲，这种做法也需要程序员小心地维护
所有视图的大小和相对关系，以避免主窗体的大小变化引
起客户区的混乱。相比之下，把数据视图放在不同的子窗
体或属性页中的做法就会让窗体布局更为简明有序。
控件排列
整齐，一定要整齐，任何不整齐的用户界面都不是好
界面。
窗口和对话框中的所有控件都必须整齐排列。实际上，
几乎所有现代可视化开发环境都为我们提供了调整控件大
小、对齐控件以及等距离均匀排列控件的工具。不知道为
什么，很多程序员就是不愿意使用这些功能，他们宁可相
信自己的眼睛也不相信开发环境中的自动化工具。
当然，除了随意摆放控件位置、随意设定控件大小的
极端做法以外，我还见过另一种极端。有一家很有名的软
件公司为了规范项目组的界面设计风格，居然在其开发制
度中规定：界面中每一组控件都必须用GroupBox 包围起
来。结果，那家公司开发出的软件大多都有像图 2 一样的
界面：
图 2 滥用GroupBox 的界面
据说，该公司这样做的目的是为了使控件的排列更加
整齐。但看过图 2 就可以知道，无论控件排列得多整齐，
对话框中层层嵌套的线框总会在视觉上给人留下杂乱无章
的感觉。显然，这是一个自作主张、画蛇添足的典型案例。
窗体留白
如果窗体边缘或窗体中的某个区域有大量空白，那你
就应该重新考虑窗体的大小和控件的排列方式。
很多程序员喜欢在窗体（特别是对话框）的四边留下
大量空白。这种“宽边”窗体事实上很不招人喜欢。仔细
看一下Office 等商业软件中每个对话框的边缘设计，边缘
紧凑、线条简洁才是今天的主流风格。
一些懒惰的程序员习惯于简单地从上到下或从左到右
摆放控件，而不顾及这种做法会在窗体中留下多少空白区
域。图 3 中所示的对话框简单地把控件由上至下排列，结
果在右上角留下大量的空白，一眼看上去整个对话框有向
左倾斜的趋势（这种左重右轻的错觉在平面设计中可以被
归入视觉心理学的研究范畴）。
图 3 右上角留白的对话框
重新排列控件，或是调整窗体及控件的大小就可以解
决窗体留白的问题。对于无法在设计时准确调整窗体大小
的界面（比如一些由程序自动生成的界面），如果实在没办
法挤掉空白，那也不妨把所有空白都整齐地保留在窗体的
最右边或者最下边，这可以尽量保证窗体的整洁。
主菜单
把菜单项按逻辑关系组合在一起。菜单的层数不要超
过两层。
合理安排菜单项对于软件的最终用户来说非常重要。
很多用户（包括我在内）使用新的软件时，都是依靠菜单
而不是联机帮助来熟悉每一项软件功能的。一般来说，菜
单的编排都有业界的标准或惯例，如果你非要把“复制”
和“粘贴”功能放在“工具”菜单里，那我只能说你是成
心为用户设置障碍了。此外，菜单的层次有助于在逻辑上
划分软件功能，但层次过多的菜单只会让用户叫苦不迭。
图 4 独特的菜单设计风格
例如，图 4 是我见过的一个菜单设计方案。程序员在
每个菜单项的左右两边都加上了“【”和“】”符号。据说
这样做是为了让菜单更清晰、更醒目。我并不认为这样做
有什么不好，关键是程序员忘了给菜单项加上助记字符（带
下划线的字母），用户没法用“Alt”加字母键这样的键盘
组合来选择菜单项了，这对那些用惯了键盘的用户来说可
不是什么好消息。
工具栏
确保工具栏中所有按钮都可以对应到主菜单中的某个
菜单项。
这个原则的重要性在于，如果在主菜单找不到工具栏
里提供的某项功能，用户就只能用鼠标来触发该功能了。
万一用户的鼠标出了故障，或是碰到了因为追求操作速度
而迷恋键盘的用户（在某些网络游戏里，只用键盘不用鼠
标的高手通常都被归入“键宗”一派），你的软件就得挨骂
了。
顺便提一句，我见过有人把工具栏按钮设计成图 5 中
的样子：
图 5 “汉字”工具栏
这种“汉字”工具栏的设计纯属糟蹋工具栏的名声。
如果你找不到合适的图标，那就干脆别用工具栏算了；如
果你一定要用汉字来注明按钮的功能，那为什么不用更规
范的做法——ToolTip 提示呢？
图标
没学过美术就不要自己画图标。只要不侵权，使用别
人的劳动成果既能省力，又不会出差错。
用户界面中的许多元素，比如菜单、工具栏、树形图、
列表框都可以配上图标。现在网上有很多免费的图标库可
供下载，那些无处不在的老面孔（比如磁盘、打印机、望
远镜这样的图标）更不会引发什么版权纠纷。因此，在图
标的使用上，程序员应当异常坚决地执行“拿来主义”。
不过，使用图标要有统一的风格，千万别混用不同风
格、不同类型的图标。比方说，图 6 中的工具栏一共只有
10 个图标，却混杂了线条图、立体图、卡通图等三种风格，
设计这种“大杂烩”界面的程序员的确缺少了一点专业精
神。
图 6 混用不同风格图标的例子
上下文菜单
这里的上下文菜单是指点击鼠标右键后弹出的菜单。
上下文菜单的内容一般和鼠标点击的对象相关。设计上下
文菜单的注意事项和设计工具栏类似：
把最常用的、与特定对象相关的操作放在上下文菜单
中，同时，确保这些操作也可以通过主菜单实现。
出于懒惰或其他原因，很多程序员爱犯这样的错误：
只在上下文菜单中提供与特定对象相关的操作，主菜单和
工具栏都不再重复提供这些功能。这么做的后果是，如果
用户不知道鼠标右键可以打开上下文菜单，那就永远也找
不到这些功能了。很显然，上下文菜单只是用户操作方式
的一种，在用上下文菜单为鼠标操作开辟绿色通道的同时，
我们也应当利用主菜单为键盘操作提供方便。
字体
只使用最常见的，或是用户点名要用的字体。
也许是因为多数开发环境都可以用所见即所得的方式
轻易调整字体的缘故吧，在各种界面要素中，字体似乎是
程序员最喜欢发挥想象力的一个领域——我经常在一些充
斥着初号大字和“彩云”、“琥珀”等变形字体，满眼是倾
斜、旋转、闪烁等花样文字的界面跟前头晕目眩。依我说，
既然不是专业的平面设计师，我们程序员还是别在这方面
卖弄为好。
最稳妥的方法是：只使用“宋体”、“黑体”等常见字
体，只使用Windows 系统默认的字号大小。尽量少用斜体、
下划线等修饰手段。当然，用户决定一切。当用户在字体
方面有特殊需求（比如为了醒目起见加大某些文字的字号）
时，我们当然应该照办不误了。
使用字体时的另一个常见错误是字体和容纳该字体的
控件大小不匹配，像图 7 所示，输入框的大小和框内的字
号相比差距过大——这种界面明显是程序员随心所欲、不
负责任的产物。
图 7 控件和字体不匹配的例子
色彩搭配
色彩搭配是一门很深奥的学问。如果你不准备深入学
习相关的理论知识，那最好别在界面中使用和系统配色方
案差别太大的色彩。
WIN32 API 用COLOR_BACKGROUND 、
COLOR_BTNTEXT 等宏定义来表示系统缺省配色方案中
的每一种色彩，用户可以通过改变Windows 外观来改变这
些色彩组合。严格按照系统配色方案的要求使用这些色彩，
可以保证界面中的色彩组合既符合Windows 风格的要求，
又能在Windows 外观改变时与其他程序的色彩搭配保持
一致。
如果你一定要用鲜艳的颜色（比如红色）来提醒用户
某件重要的事情，那么记住，这些颜色用得越少越好——
如果不经专业技法处理，大面积的红色、绿色、紫色或者
橙色都很容易让人产生视觉疲劳以及眩晕、恶心等不适症
状。
错误信息
笼统或技术性太强的错误信息只会让用户深陷泥潭。
大多数软件的用户都不是精通计算机的专业人士。如
果普通用户看到图 8 中的这条错误信息，他会作何感想
呢？
图 8 技术性过强的错误信息
在普通用户当中，没有谁会知道DBCC 这个命令要在
哪里运行，更不会有人知道什么是“分配页”，什么是“段
ID”。向用户报告这样的错误信息还不如立即终止执行的
做法干净利落。
当然，完全忽略技术信息又不利于专业人士对系统故
障的诊断。常见的做法是把技术信息记录在系统日志里，
界面上只告诉用户“系统出现故障，请联系..”。图 9
中把友善的提示语和专业的技术信息结合在一起的做法也
非常值得推荐：
图 9 改进后的错误信息
分辨率
用户的显示器可能在不同的分辨率下工作，你的软件
界面必须能适应分辨率的变化。
我知道有不少程序员开发的软件都只能在某种特定的
分辨率（比如1024×768）条件下保持界面的美观。许多
程序员为了省事，干脆就按用户通常使用的分辨率大小，
把窗体中所有控件摆放到合适的位置。在大多数情况下，
这种软件的用户界面非常整洁，可一旦用户改变分辨率，
窗体中的控件就立即东倒西歪，有的甚至无影无踪了。
顺便问一句，测试软件时，你做过分辨率方面的实验
吗？你的软件界面（GUI 或Web 页面）能在Sony W 系列
笔记本的超宽屏幕（1280×768）上靓丽如初吗？要是移植
到联想天玑掌上电脑的袖珍显示屏（320×240）上呢？
从技术上讲，适应不同的分辨率，不过是要在响应每
个窗体的WM_SIZE 消息时，调整好相关窗体的大小。应
该说，这项工作并不十分困难，任何聪明、勤快的程序员
都可以做得到。
4 补充说明
本文讲的是用户界面好看不好看的问题。按说，这些
涉及心理感受的事情并没有绝对的对与错之分。我写的这
几条准则既不全面，又不深刻，更谈不上循循善诱、诲人
不倦。你完全可以说我批评的某种设计方案其实非常出色，
因为那是某某主义设计风格的杰出代表。但我们不要忘了，
软件不是颓废派诗歌，不是解构主义文本，更不是哪个无
病呻吟的家伙自娱自乐的工具，软件要满足用户的需求，
迎合用户的口味，要让用户在掏腰包的同时心满意足、气
定神闲，别动不动就吹胡子瞪眼——说到底，只有广大用
户才是评价用户界面好看与否的最终权威。
正因为如此，微软、IBM、惠普、苹果、Oracle 这些
大企业才要不惜代价建造所谓的可用性实验室，或是用统
计学的方法跟踪、调查、实验、分析用户的操作习惯和审
美取向，简单说这是要花大价钱搞清楚用户到底有多少高
雅情操抑或低级趣味，这种做法当然最正确、最有效、最
符合科学规律，也最能解决我们在界面设计中碰到的各种
问题。
所以，还是那句话，如果我们自己没能力开展类似的
研究，那不妨惟主流软件和主流企业马首是瞻——这么做
实际上是借大公司的研究经费和研究成果为己用，往小了
说这叫凿壁偷光，往大了讲这叫海纳百川，你又何乐而不
为呢？
5 总结一下
.. 程序员一样可以设计出好看的用户界面。
.. 最关键的是模仿和学习，最好能让自己设计的界面和
主流软件一样好看。
① CoverPages. XML Markup Languages for User Interface
Definition. http://xml.coverpages.org/userInterfaceXML.html,
2003
② W3C. XForms Specification.
http://www.w3.org/TR/xforms/, 2003
③ Microsoft. MSF Team Model.
