同常见软件保持一致性的设计
出色的用户界面在程序中将实现同用户以前用过的其它成功软件一致的动作。写商用程序软件的时候应该尽可能的给用户提供这种一致性。例如，EmbassySuit和CourtyardMarriot连锁旅店增长的非常快，因为商务旅行者知道这些连锁的旅店能为他们提供相似的客房和其它大体差不多的服务。最次也使得商务旅行者不必每到一个新的城市都为找新旅店发愁。你的软件的商务用户有同样的需求。你程序中提供的每个新的特色都可能让用户感到焦躁，迫使他们反复试验或着给你的维护小组打昂贵的长途电话。
提供可视反馈
如果你曾有过傻傻的瞪着自己电脑上显示的沙漏等着一个操作结束的时候，就会明白没有可视化的反馈信息有多糟糕。你的用户非常希望知道一个操作会花费多长的时间以便准备好足够的耐心。作为最一般的规则，当一个操作超过7～10秒的时候，大多数用户希望看到一个带有进度条的消息对话框。时间的长短要根据用户类型和应用程序的特点来调整。
提供声音反馈
上周，我有幸乘坐了一次电梯，这部电梯用悦耳的声音通知乘客他们到那一层了。大楼非常新，而首先，雇员们认为声音非常可爱。一层层的走来走去的六个月后，雇员忽略了声音，开始觉得它厌烦而不认为是一个帮助。同样的事情在你的用户界面上也会发生，除了一个是厌烦的声音限制在电梯之内，一个是到了工作间的每个人的耳朵里。把音效放到几百台电脑上，在开放式的工作间中就会产生刺耳的杂音。但无论如何，声音反馈是有用的，尤其是在你需要警告用户一个严重问题产生的地方，例如进一步的操作将导致数据的丢失或程序出错。允许用户取消声音反馈，除非错误不得不通知。
保持文字内容清楚
开发者常常通过增加大量词汇来尽力使文字反馈内容清楚。但事与愿违，他们最后使消息更不清楚了。简化文本标签、用户错误信息和一行的帮助信息上的词汇是一项挑战。文字反馈的任务可以交给科普作家，通常他们可以高效的处理。
提供操作路径跟踪
如果你的用户曾经说过象这样的话：“我也不知道怎么就到这个窗口了，可是我在这里了，我也不知道怎么才能退回去。”那么就是你没有提供一个可跟踪的路径，或者说，在这种情况下，是一个可重复的操作路径。提供一个可重复的操作路径说着容易做来难。应该从设计简洁的启动你指定的功能的菜单结构开始着手。
你也要指明你菜单结构的展开位置，避免超过两级的级联菜单。为每个对话框提供描述性的标题可以非常有用的提醒用户是哪个菜单项或按钮被按下后把他们带到当前窗口的。
提供键盘支持
键盘是用户桌面上常见的固定设备，为用户输入文本和数据提供了一个有效手段。在介绍图形用户界面程序时，我们常常假定用户把鼠标作为主要的交互设备。而用鼠标操作程序对于录入员或常用用户来讲是非常费时和低效的。
加速建可以给用户提供一种非常有效的操作方式来访问窗口中的指定菜单项和控件。加速建应该易于使用并限制在一到两个键（如F3或者Ctrl-P）。键盘在GUI的世界中有一定的限制，例如在实现象拖拽、点击、变大变小窗口等直接操作任务的时候。相对来说，你总会发现有一小批人坚持用鼠标从不碰键盘。这导致你需要对所有菜单和窗口操作提供完整等价的键盘和鼠标支持。
注意表达模式
把所有界面的各个方面连起来的一个重点是界面的外观和风格。外观和风格必须一致。用户使用一个窗体或对话框过后，在此基础上，他们希望在使用下一个窗体或控件时有同样的感受。
研究好的界面设计模式和连续性是最重要的。决定模式一定要用心，例如程序是有单文档界面还是多文档界面。模式也包括用户如何在程序中完成他们的任务。
指定合适的程序表达方式对开发后续窗口提供了很大的便利，因为它们有很多通用的内在框架。另一方面，如果你不尽早在你的界面设计中定义好表达方式，拖后对程序外观和风格的修改将浪费大量的时间和金钱，因为改动几乎会影响到所有的窗口。
有模式和无模式对话框
当我们需要用户的输入时，我们常常就需要用有模式对话框。使用有模式对话框一直被很多开发者尽量避免，因为它对用户限制太多。但不管怎样，有模式对话框在复杂程序中还是很有用的，因为很多人同一时间只在一个窗口内工作。当有特定任务时可以试着用有模式对话框。对不确定完成时限的任务无模式对话框是一种更好的选择，但有个提示：在同一时刻，要使用户的无模式对话框保持在3个以内。如果超过这个数的话，你维护部门的电话就会响个不停了，这时用户就很难把注意力集中到他们的任务上，却要花费很多的时间管理各种各样打开的窗口。利用图三中的表来决定合理的使用对话框和窗口。
|
何时使用对话框、窗口 |
|||
|
类型 |
描述 |
使用 |
例子 |
|
有模式 |
对话框 |
给出一个确定的任务 |
打开文件对话框 |
|
无模式 |
对话框 |
给出一个持久的任务 |
查找框 |
|
应用程序窗口 |
含有子文档窗口的窗口框架 |
给出一个对象的多个实例 |
文字处理 |
|
文档窗口 |
无模式对话框或者被应用程序窗口管理和包含的文档窗口 |
给出一个程序的多个部分 |
数据的多个视图 (表单) |
|
从属窗口 |
附属应用程序的主窗口 |
给出被父程序调用的另一个程序 |
调出一个程序的帮助 |
控件约定
控件是用户同程序交互的可见单元。用户界面设计人员面对着的控件集合取之不尽。每个新的控件带有自己特定的行为和特征。为每个用户选择合适的控件会产生更高的产出、更低的错误率和更高的用户满意度。可以在你的屏幕上按图四的表中列出的控件用法使用控件
|
控件使用说明 |
||
|
控件 |
范围内应用的数量 |
控件类型 |
|
Menu Bar |
最多十个子项 |
Static action |
|
Pull-Down Menu |
最多十二个子项 |
Static action |
|
Cascading Menu |
最多五个子项, 一层级联 |
Static action |
|
Pop-up Menu |
最多十个子项 |
Static action |
|
Push-button |
每个对话框中最多六个 |
Static action |
|
Check Box |
每组最多10～12个 |
Static set/select value |
|
Radio Button |
每组最多六个 |
Static set/select value |
|
List Box |
表中最多50行, 显示8～10行 |
Dynamic set/select value |
|
Drop-down List Box |
控件中一次显示一个选项，下拉框中不超过20项 |
Dynamic set/select single value |
|
Combination List Box |
控件中按标准格式一次显示一个选项，下拉框中不超过20项 |
Dynamic set/select single value; add value to list |
|
Spin Button |
最多十个子项 |
Static set/select value |
|
Slider |
依赖于显示的数据 |
Static set/select value in range |
最后，尽量在整个应用程序中保持这些控件基本行为和摆放的一致性。一旦你改变这些基本控件的行为，用户就会迷糊。要仔细想过才改，并且这些改变用的时候要一致。
使用设计规范
要理解出色的用户界面设计（GUI）背后的规范并把它们应用到自己的程序中是一个挑战。让我们检查一个程序，看看如何应用这些规范来改善界面。
看一看要重新设计的用户界面设计
图五中的界面被一家救护车分派公司用来维护客户数据，提供财务信息和分派救护车。应用程序是从字符系统移植过来的，包含很多设计错误，这些错误将影响到重要任务应用系统程序的用户使用。要记住，在重要应用系统中，界面的清晰简单尤其重要。例如这里，对请求的快速处理攸关生死。这个窗体中有如下错误：图五
- 顶层有太多的功能。用户要求新系统方便的提供所有信息，这使得窗体同时用于客户管理和救护车派送。如果你输入完整的客户资料并按更新按钮，记录就更新了。但是，如果你只输入最少量的客户信息，例如社会安全号，诊断，从哪里到哪里，然后按分派按钮，救护车就被派出。更新功能和派送功能需要在不同的对话框中处理。
- 太多按钮。右侧的按钮应该在父窗口中，也许就在工具栏中，但不应该在子窗口中。
- 差的导向帮助。GUI控件应该按使用的频率摆放。最重要的字段应该放在左上；次要的字段应该放在右下。当分派救护车时很难想象公司名和发票号是最重要的字段。
- 控件的不合理使用。设计者采用了文本标签而不是组别框来区分屏幕上的数据应该归哪一组。这许许多多的文本标签弄得屏幕非常乱同时使数据和标签很难区分。可编辑的字段应该用一个框子框起来，以便可以非常直观的看出那些字段可以更改。
- 缺乏
（转载 电子园）