GUI设计禁忌2.0 思维导图模板_ProcessOn思维导图、流程图

GUI：Graphical User Interface(用户图形界面)

基本原则

关注用户及其任务，而不是技术

理解用户

业务决策、经验调查、协作

目标是要生成一个配置文件，以描述计划如见的主要目标用户，应当包含工作描述、工作资历、教育状况、薪酬、绩效评定、年龄、计算机技能水平以及任何相关的身体或社会特征。

决定谁是目标用户

选择一个特定的基本目标人群作为目标用户群，以便集中他们的设计和开发工作

确认目标用户群与开发机构的战略目标一致

营销和销售部门负责用户的识别和分类

设计人员需要理解用户

开发人员过滤或补充营销和销售部门有关谁是产品目标用户的想法

调查目标用户的特点

理解用户还需要经验调查：了解潜在用户的相关特征，有助于开发人员发现特定的用户群

用户并非介于"初学者"与"老手"之间

对计算机的总体了解：他们对于计算机的总体知识了解多少

任务知识：他们执行目标任务的熟练程度如何

系统知识：他们对特定软件产品或类似对象的了解程度如何

理解任务

确定要支持的任务集

机构的战略目标，反映其创立者，高管层和股东的利益

其雇员的专业意见

其过去的历史

其资产、流程和基础设施

其对市场基于和定位的认识

其研究人员已经开发出来的新技术

调查目标任务

在开始设计或实现任何工作之前，开发人员需要尽可能确切的了解目标用户如何完成软件要支持的任务

任务分析的目标是要彻底理解软件将要支持的活动

执行任务分析的最佳途径是与用户或类似于目标用户的人交谈并观察他们

发个文用户和观察用户工作都很重要，这两种技术互为补充

与用户协作以了解任务

对于理解任务来说，与用户写作甚至与理解用户更为重要

访问和观察的局限性使得单纯依赖从任何一种方式获取的结论都有很大风险

通过将双方反馈引入到任务发现和分析过程中可以克服这些局限性

良好的任务分析可以回答一些相当详细的问题

与应用程序的目标任务领域相关的人员执行什么任务

哪些任务是常用的，以及哪些很少用到

哪些任务最重要，哪些最不重要

每个任务的步骤是什么

每个任务的结果是什么

每个任务的信息来自哪里，每个任务所产生的信息是如何使用的

哪些人做哪些任务

每个任务需要使用什么工具

执行每个任务时人们会遇到什么问题（如果有的话），什么类型的错误比较常见？这些问题和错误是由什么引起的？错误的破坏力如何

完成这些任务的人员使用什么术语

不用任务如何关联

完成任务需要与其他人进行哪些沟通

考虑软件工作的环境

工程师常常将他们正在设计中的对象看作是宇宙唯一的东西，没有考虑使用技术的环境，以及在这种环境中使用技术时用户总的体验是什么

以技术为中心的视野狭隘是人类易犯的错误

人们都关注他们自己的目标和愿望，而经常忽略周欸环境中还有其他事情会影响到应用技术解决问题的结果

首先考虑功能，然后才是表示

首先考虑功能不意味着什么

并不意味着首先设计和实现功能，然后再关心用户界面

软件用用程序的用户界面不仅仅是软件的外观，还体现了一些深入到架构中的设计决策

首先考虑功能意味着什么

软件应用程序体现了特定的概念以及概念之间的关系

这个软件将向用户展示什么概念，他们是用户要从任务领域认识到的概念吗，或者是新概念，若是新概念能变成成常见概念的扩充吗，或者他们是从计算机科学引入的外来概念吗

用户会用这个软件创建、查看或操作什么数据，会从数据中提炼出什么信息，如何提炼，会用哪些步骤，用户输入到软件的数据来自哪里，从软件中生成的数据又在哪里使用

这个应用程序会提供什么选项、选择、设置和控件，这不是一个关于如何表示控件的问题，而是关于他们在软件中的功能，目标和角色，这是关于这个软件提供什么选项的问题

开发概念模型

什么是概念模型：设计人员希望用户理解的应用程序模型

任务焦点

利用那些用户所熟知的概念使概念模型聚焦于任务，避免外来概念

系统操作与他所服务的任务之间的映射越直接，用户接受目标概念模型的机会就越大

执行对象/操作分析

概念模型最重要的部分是对象/操作分析

对象/操作分析的示例

管理活期账户的软件

对象/操作分析：交易、支票和账户，应排除与任务不相关的哪些对象，例如缓冲区、对话框、模式、数据库、表和字符串

基于任务的概念模块应包括填写/作废支票、存款和取款以及账户结算这样的操作，如不包括那些与任务无关的操作，比如单机按钮、加载数据库、编辑表格行、刷新缓冲区和切换模式

对象关系

对象/操作分析的一个重要作用是定义和表示对象之间的关系

开发一个词典

规定了要在整个软件及其文档中使用的术语

由整个团队开发，最好是由团队的技术编写者来管理和实施

编写任务场景

完成一个概念模型，开发人员就可以仅用来自模型的术语编写用例或场景，用来描述使用这个应用程序的人们

概念模型上的基本用户界面设计

用户界面应基于概念模型进行设计，将概念模型的抽象概念转换为具体表示、控件和用户操作

对象/操作分析可以作为开发起点

概念模型关注设计过程

影响系统概念模型的单方面变更是不允许的

与用户对任务的看法保持一致

争取自然

不要让用户做不自然的事

不不自然的行为是指用户所执行的操作与他们的目标没有明显的联系

强加专断的限制

软件可能侵犯用户自然直观感觉的另一方面是给用户强加专断的或表面上专断的限制

使用用户的词汇，而不是你自己的

让程序内部内容在程序内部进行处理

找到正确的功能/复杂度平衡点

功能和易用性之间通常存在一个平衡，对于应用程序中的每个特性、功能或能力，都必须有一种途径提供用户调用或控制

设计技术降低复杂度

恰当的默认值

模板或者封装的解决方案

指南性的路径和向导

渐近式显示

通用命令

特定于任务的设计

可定制性

设计要符合常见情况

使得易于实现常见的结果

为了得到一个想要的结果，用户必须要指定的量不应与结果的复杂度成正比例，应当与期望结果偏离常用结果多少成比例

两种类型的常用："用户有多少"与"使用频率如何"

有多少用户需要该功能？是所有或几乎所有用户、大部分用户、极少用户还是几乎没有人使用它

用户使用该功能的频度如何？需要该功能的人们是每几秒就使用它，还是几分钟、几小时、祭天、几周、几月或者几年才使用

设计规则

越频繁使用的功能，需要的点击应越少

越多用户使用某功能，它就应该越明显

为核心情况设计：不要为"边缘"情况付出太多工作

不要分散用户对他们目标的注意力

不要让用户解决额外问题

不要由于计算机产品和服务强加给他们的额外问题而分散对原本那些问题和目标的注意力

不要让用户通过排除法来推理

最大限度地减少解决计算机技术领域中问题的需求包括不让用户通过排除过程来猜测软件是如何工作的

促进学习

"从外到里"思考，而不是"从里到外"

软件开发人员在进行设计时，经常假定用户会自动了解开发人员的意图（里->外）

确保用户界面对于那些不知道设计人员意图的人们有意义（外->里）

一致性、一致性、一致性

避免gotcha

如果软件到处不一致，会迫使用户不断的考虑，因而分散了用户对任务的注意力

试图前后一致的危险：难以定义、多方面的、容易受到解释的影响

无论如何一致性都是好的

让一致性以用户为中心

提供一个低风险的环境

传递信息，而不仅仅是数据

认真设计显示，获取专业帮助

视觉顺序和用户焦点

易于浏览

匹配介质

注意细节

屏幕属于用户

错误思想

使鼠标指针跳动或变形到新的位置

将控件移向指针

重新定位、拉伸或收缩窗口

保持显示惯性

培养用户对更改的认值和理解

最大限度地减少对用户继续工作能力的破坏

设计应满足响应需求

什么是响应性

响应性与性能相关，但他们是不同的，交互式软件可能又很高的响应性，但性能可能很低

性能是以每单位时间的计算数量来度量的

响应性是以是否符合人的时间需求（最终是满意度）来度量的

响应性差的示例

对按下按钮、滚动条移动或对象操作的反馈延迟

阻碍其他活动的费时操作且不能中止

没有提供任何线索来表示操作会花费多久

忽动忽停的、难以跟上的动画

执行用户未请求的内部"内务性"任务时忽略用户的输入

Web上的响应：虽然很差但正在改善

web浏览器与服务器之间的通信受到影响

web设计人员和开发人员忽略了响应性需求以济如何时间响应性

设计应满足响应性

对用户操作即时做出应答，即使返回答案需要一定的时间

让用户知道系统何时忙碌，何时空闲

在等待功能完成期间允许用户执行其他操作

让动画的移动变得流畅清晰

允许用户放弃他们不想再执行的冗长操作

使用户能够判断操作将花费多少时间

尽可能允许用户设置他们自己的工作步调

通过用户试用发现错误，然后修复它

测试结果甚至可能令经验丰富的设计人员大为惊讶

为纠正测试所发现的问题安排时间

测试有两个目的：信息目的和社会目的

易用性测试的信息目的：找到导致用户困难的用户界面问题，并利用准确的问题性质来提出改善建议

易用性测试的社会目的使开发人员确信有一些亟待纠正的设计问题，使他们更容易接受易用性测试是一种重要的开发工具

在不同时间、针对不同目的进行测试

在开发中执行测试的时间点

测试方法的正式程度

GUI控件禁忌

使用了错误的控件

混淆复选框和单选按钮

变体A：单独的单选按钮

没有经验的程序员不知道单选按钮与复选框之间的区别

GUI工具包提供了一个通用的开关按钮，程序员未正确设置其属性

由于功能需求中的变动，一组单选按钮中的一些选项被删除了，但没有人重新设计用户界面来反映出这一点

选择中的选项数据根据情况来变化，软件未将"单个选项"当作特殊情况

变体B：将复选框当作单选按钮

开发人员不知道复选框与单选按钮之间的区别或如何显示单选按钮

变体C：互斥的复选框

当GUI工具包将单选按钮和复选框看作一种通用开关按钮控件的不同变体时，容易发生此错误

程序员将一组原来不想管的开关设置更改为互斥的，以适应软件功能需求中的变化

实现约束

复选框和单选按钮适用于不同类型的设置

单选按钮

选项数目是固定的，并且较少：2~8个

面板上有足够的空间，可以显示所有选项

复选框

表示一个开关设置，值应该互相独立

可以组合在一起便是一组相关的开关设置

允许用户选择一组可用选项中的一个有限子集

复选框应该是独立的，但复选框组缺必须限制选中选项的数目

选择GUI工具包的建议

将复选框和单选按钮作为两种不同的控件类型

将表示一个选择的一组单选按钮作为一个单一的控件

将单按钮组合、下拉菜单和滚动列表作为同一种"多选一"控件类型的不同表示来对待

在非开/关设置中使用复选框

复选框有时用于二选一的情形，但这两个选项并不是明确相反的

使用命令按钮作为开关

大多数GUI工具包都提供一个命令按钮控件（也称动作按钮），命令按钮调用一个操作或触发一个事件

有时命令按钮被错误的用作开关控件，点击按钮打开某个开关或切换到另一种模式，再点击它就观赏了这个开关或返回原来的模式

GUI工具包中的命令按钮控件时用来调用命令或初始化时间的，只会短暂的显现按下的章台，然后恢复成未按下的样子，命令按钮没有持久的状态

使用选项卡作为单选按钮

将选项卡当作单选按钮，也就是将它作为表示选择的方式，这些选择影响应用程序的行为，而不仅仅是显示哪个面板

选项卡纯粹时导航控件，它影响用户再应用程序中的位置，也就是影响其他设置的可见性，选项卡本身不应该是设置

太多选项卡

选项卡面板的一个重要目的就是通过重叠不同的控件或信息面板来节省空间，因此它们共享相同的屏幕空间，但其本身就要求很大的空间，沿着某一边沿（通常是顶部）的可用空间并不能容纳过多的面板，当选项卡超出该限制时，就发生了错误

变体A：因小失大

增加面板的宽度以便容纳更多选项卡：使用选项卡来节省空间->浪费空间来使用选项卡

变体B：在左边添加选项卡，在右边添加选项卡，四周都有选项卡

用户将认为这样的一个面板是一个分层结构，其中沿顶部的选项卡是主要的，而沿底部或旁边的选项卡是次要的

变体C：缩短标签

牺牲选项卡的清晰成都来获得更窄的选项卡，也是另一种因小失大的例子，不会在所有的语言中奏效

变体D：多行选项卡

当多行显示选项卡时，从非首航的任意一行选择一个选项卡不仅会显示选中选项卡面板，而且会将这个选项卡所处的行变为第一行，
如果单击第二行的一个选项卡，该行立即从指针下面移到第一行

避免大量的选项卡

面板的数目太大了，真正的问题时面板太多了，将他们重新组织为更少的面板，从而减少选项卡的数量

使用另一个控件来代替选项卡

不使用选项卡，使用单选按钮、下拉菜单或滚动列表在不同的显示面板之间进行切换

稍微增加面板的宽度

在皮不得已的情况下才使用，而且在缺少的水平空间很小的情况下使用

永远不要使用多行选项卡

屏幕属于用户

保持屏幕惯性

为只读数据提供输入控件

不可编辑的文本字段

不可编辑数据的输入控件的错误用法

设置了可编辑属性但未设置外观

GUI工具包允许我这样做，因此他肯定是没有问题的

我已经将他设置为禁用了

标签只用作标签

它看起来应该与可编辑的屏幕i相同

它是用户可编辑的，但不能直接编辑

数据变化

不可编辑的数据永远不应该在那些看起来可编辑的或可操作的控件中显示

复选框

单选按钮

菜单

滑动条等

对于有约束的输入滥用文本框

错误的观念：文本字段更易于编码

错误的主要来源：TTY-GUI转换

保守的使用文本字段

文本框仅用于真正非结构化的、自由格式的数据

文本字段的几种替代

大多数GUI工具包都提供了可用于替代文本字段的专用输入控件，它们用于收集有很高约束的用户数据，开发人员也可以从简单的控件来构建专用的输入控件

错误的使用控件

动态菜单

大多数应用程序

具有多种操作模式，模式不同，可用的菜单栏命令也不同

支持几种不同的内置数据类型，当前选择的数据类型不同，则可用的命令也不同

复合文档应用程序

增加和移除菜单，而不是菜单项

过于严格的数据字段

易于编码，难于输入

提供用户友好的、稍微宽松的输入字段并不能难

使字段长度与数据匹配

接受常见格式

接受广泛使用的格式

注意不要拒绝合法数据

不区分字母大小写

提供一种模式

为文本字段设置结构

没有默认值的输入字段和控件

省略默认值的原因

没有合理的默认值

社会、政治或法律要求

没有默认值的文本和数字字段

没有初始值的单选按钮

避免对用户将要选择什么做出任何假定

迫使用户明确的做出选择

允许用户不选择（与前两个原因相比较不常见）

不带默认值的下拉菜单

没有值的菜单比没有值的单选按钮更自然，单选按钮上"没有值"意味着其可能的值被设置为none

菜单比单选按钮显示更多的选项，单选按钮最适合2~8个选项，而菜单可以显示数十个选项，这使得开发人员不太容易选定一个恰当的默认值

不恰当的默认值

需考虑

常见意义

业务逻辑

经验和现场数据

个人用户的数据

任意选择

反向复选框

指选中时关闭某个功能或属性，而在未选中时打开它，它们是与用户的期望"反向"的

复选框应起到正向功能，当选中复选框时，应打开某项设置，而当取消时则关闭它，这是用户所期望的

导航禁忌

未显示用户当前所在位置

未标识窗口或页面

桌面应用程序：窗口没有标题

web：未标识页面

导航栏：在站点的导航栏中标识当前页面项

页面标题：将页面标题放置在靠近页面内容顶端的明显位置

不同窗口使用同样的标题

变体A：窗口的标题只命名了应用程序

变体B：程序员复制了代码，但忘记了更改标题

变体C：程序员不知道这个标题在其他地方被使用了

变体D：程序员认为这个标题对两个窗口都适用

窗口标题与命令或链接不符

桌面软件中的错误

计算机用户会咬文嚼字的理解标签和其他有助于导航的屏幕信息

此错误的一个常见原因

用户指定用来创建新对象的属性通常与现有对象中的属性相同，因此GUI程序员常常将一个对话框同时用于两种功能

web上的此类错误

类似的标签不匹配再web上也会发生

窗口或web页面的标题应反映出打开它们的命令

如果对用户理解有利的话，两者不完全一致也是可以的

一种有效的解决方案：允许使用命令来设置窗口标题

将用户引入歧途，又不为他们显示路径

使用户偏离正确道路的按钮和链接

引入歧途，而且无法返回

位置不当的促销信息将客户引入歧途

不要分散用户对他们的任务的注意力

自身链接

用户在向下滚动页面时单机自身链接，页面重新显示顶部

页面每次显示时都有变化的图像

页面包含动画、applet或其他动态内容

变体A：导航栏中的自身链接

变体B：哪一个是主页

变体C："面包屑式"的导航中的自身链接

变体D：其他地方的自身链接

对话框层次过多

避免对话框的层数超过两层

这一规则只适用于对话框

同样适用于web上显示的对话框

真对话框

独立的浏览器窗口

类似于对话框的页面

某些类型的对话框不在考虑范围内

一些对话框提供的功能十分简单，是一些用户很熟悉的常用功能，不会分散用户的注意力或是误导用户

将窗口层次结构图形化或列出大纲

消除层次过深的方法

一些GUI使用额外的窗口来提供渐进式显示，即将细节隐藏起来，直到用户要求查看它们

有些对话框用于提供命令选项

糟糕的搜索导航

互相竞争的搜索框

变体A：糟糕！这是个错误搜索！

变体B：两个相同的搜索框，如何选择？

变体C：哪一个是最好的？

搜索结果的浏览方式不佳

搜索结果不仅应提醒用户搜索项是什么并提示命中数，而且应该让用户易于浏览命中结果

干扰搜索结果

将区别隐藏在复杂的结果中

强迫用户单机命中结果

文字禁忌

不利于交流的文字

术语不一致

纵览全局：列出所有术语

变体A：同一概念使用了不同的术语

变体B：同一个术语用于不同的概念

每个概念使用一个术语

创建一个产品词典

对于公共概念使用行业标准的术语

词典的实施

让用户对词典进行测试

使用消息文件

变体B，重复文本串

文本串冗余（本应该是一个文本串）

不同情况的文本串相同

含义不清的术语

变体A：术语模糊

变体B：不同概念的术语在意思上有重合

变体C：概念过于相似

避免同义词

不要使用常见的同义词来表示软件中的不同事物，确保软件中各个概念的术语彼此之间清晰地区分

避免含义模糊的术语

让用户对术语进行测试

书写不好

变体A：前后不一致的书写样式

变体B：措辞、语法、拼写和标点符号使用不当

请擅长写作的人员完成

软件中出现的文本内容不应该由程序员来编写，技术作者才是完成这些工作的专业人士

检查所有文本内容的拼写

文字过多

冗长的说明和标签

冗长的链接

在传递信息时，只使用必要的文字

避免冗长的文本段落

使用标题、短语、要点

链接要短，控制在1~3个词，用非链接文本进行解释

避免链接列表中的重复，删除重复的文本或将其移动到标题中

删除无用文本的示例

目标：易浏览、清楚、简捷

以开发人员为中心的文字

用词晦涩

变体A：使用程序员行话

缺乏停止使用行话的意识

即使意识到他们在使用行话，也没有停止使用的能力

它们相信如果人们要使用计算机，就需要理解计算机的行话

时间紧迫而没有足够的书写人员，因此程序员就假设将来会有人检查和完善它们

展现技术概念和实现细节的设计和用户的任务不相关

变体B：通用词成了程序员行话

变体C：动词用作名词

了解用户

基于用户的任务词汇开发产品词汇

不要在GUI中使用组件名

在用户界面中将用户称为"user"

无用的错误消息

变体A：错误消息由底层代码显示

变体B：没有向上层代码提供错误发生的原因

变体C：使用通用消息组件

用任务术语来表达错误信息

不要仅仅指出问题，还要提供解决建议

将错误信息上传给能够向用户清楚说明的上层代码

使用消息和消息显示组件来接收运行时的细节

不同类型的消息面向不同的对象

指示用户错误：面向最终用户

日志活动：面向用户端的系统管理员

辅助调试和跟踪：面向开发人员

引起误解的文字

错误的消息

文字独立存在时有意义，但在GUI中引起误导

在命令标签中错误的使用或不适用"…"

省略号成为一项标准

变体A：省略了"…"

变体B：滥用"… "

不是所有打开新窗口的命令后面都要加省略号

这条标准对所有平台均适用

对于图形化的按钮标签应该怎么办

图形设计和布局禁忌

不好的布局和窗口放置

容易忽略的信息

人们会过滤的信息

状态指示器

模式指示器

输入提示

结果

错误消息和状态消息

控件

变体A：太小或太普通

变体B：不是用户注视的地方

变体C：淹没在大量雷同的信息当中

构建一个视觉层次结构

让重要信息变大

将重要信息放在用户正在注视的地方

使用颜色来高亮显示

其他使信息突出的方法

尺寸大小、位置、颜色

粗细、密度、颜色、饱和度

图形和符号

少用和慎用特殊手段

对话框和弹出窗口

声音

振动和动画

不要主次不分

将对话框控制按钮与内容控制按钮混合放置

将特定于数据的按钮放置在远离数据的地方使人们很难发现按钮与数据之间的关联

用于控制整个对话框的按钮与那些控制特定数据的按钮之间没有视觉上的区别

不恰当的使用组合框

变体A：单个设置外加组合框

变体B：组合框外再加组合框

变体C：整个窗口就是一个组合框

单选按钮之间间隔太大

标签与数据字段距离太远

变体A：标签太靠左，而数据字段太靠右

变体B：标签与其他设置之间的距离比它们自己的距离还近

规则1：不要将标签和数据字段放置在表单或控制面板的两个相反的边缘

规则2：防止少数的长标签影响整个表单的对齐

规则3：标签与对应字段之间的距离应当比它与其他字段之间的距离更近

右对齐设置标签

将标签宽度调整为文本的长度

规则4：将标签放置在字段上方

标签的对齐方式不一致

窗口初始位置不合适

变体A：在同一坐标显示所有窗口

变体B：在父窗口的中央显示子窗口

变体C：不在屏幕内显示子窗口

确定每个窗口的显示位置

最佳位置取决于窗口类型

一些通用的启示

窗口应当总是在屏幕中完整打开

连续出现的同一类型窗口应交错安放

外部子窗口与其父窗口只应部分重叠

确保子窗口不会覆盖其父窗口中的重要信息

不要将所有窗口直接堆积在一起

排版错误

文字过小

应用程序中大多数文字都过小而且不可调，甚至比现有产品的字体还小，而现有产品的字体已经很小了

软件的默认字体太小，45岁以上的用户很难舒适的阅读

数字簿上的键的标签太小，多数用户无法轻松阅读

影响字体大小的因素

屏幕分辨率

显示器大小

字体最小是10磅，而12磅更好

选择适合高分辨率显示的字体大小

允许用户调整字体大小

让用户控制web上的字体大小

设计容纳更大的字体

对用户进行测试

交互禁忌

偏离任务焦点

将实现暴露给用户

将用户界面的重点严格限定在任务上

为方便用户而不是开发人员进行设计

不必要的限制

软件给用户强加武断的或不必要的限制将违背用户自然直观感觉

令人混淆的概念

要求不必要的步骤

向用户索取不必要的数据

变体A：我们忘记了请在此告诉我们

变体B：不必要的问题

变体C：要求可选数据

变体D：要求重复登陆到某一会话中

不要求用户重复地输入数据

只要求实际需要的数据

以当前事务为中心

不要将任何数据设为"必需的"，除非没有它无法继续工作

不要求有些客户没有的数据，这会迫使他们虚构数据或者导致客户流失

当用户提供信息时，要尽可能多地从这些信息推导出其他信息

向用户索要随机数

使用各种时间间隔设定种子

只给用户提供他们需要的控件

游戏软件不会向用户要求随机种子

无意义的选择

变体A：没有区别

变体B：用户不知道

变体C：答案显然

变体D：错误的选择

如果选择没有区别，就不要提供选择

如果用户不理解问题，就不要问这些问题

如果有显而易见的选项，就选择它

不要提供错误的选择

增加用户的记忆负担

很难记住的id

变体A：分配的、不可更改的密码

变体B：不合理的密码约束

变体C：无效的安全问题

不会增加用户记忆负担的安全措施知道原则

让用户自己设计他们的用户名、密码和PIN码

不要在密码或PIN码上强加武断的、不必要的约束

允许用户更改他们的密码和PIN码

当用户忘记密码或PIN码时，提供了一种获取或重置密码的方式

如果使用密码问题，则提供一个好的选择，并提供"其他"选项，以便用户可以指定他们自己的问题

长的说明信息消失过快

当用户执行详细说明时，他们应该一直显示

提供一个向导

让说明一直显示

封装外来功能

不必要或效果不佳的标记模式

某个人用绘图程序编制图例

某个人正在打印一个web网页，但是页面打印处于横线模式

在一个股票投资站点上某个人创建了一个股票订单并保存它，想过一会儿再提交，但是却发现已经自动提交了

什么是模式，为什么它们会发生问题

软件具有模式，在不同条件下用户操作会有不同的效果

有模式的GUI

害处较小的模式：模型式对话框

父模型式

应用模型式

模式或系统模型式

模式设置可能是无害的，特别是当用户从不更改它们的时候

命名不当的模式

模式有3种方式影响软件的易用性

它们需要用户记住当前模式

它们导致用户犯模式错误

它们将用户的操作限制为在当前模式下有效的操作

通过去掉模式设置来消除模式

将双击操作设置为向下钻取，对于向上钻取，设置一个back后退按钮

将双击操作设置为向下钻取，将shift+双击操作设置为向上钻取

最大限度地减小模式型对话框的使用和影响

无模式：大多数情况下

父模式：必要的时候

应用模式型：偶尔

模式型或系统模式型：几乎不使用

避免对用户操作的强制性序列或临时性限制

模式很难避免

模式的优点

简洁控制

为用户提供了更多指导

安全性

识别异常操作

模式的缺点

预先计划模式设置

设置模式

记忆当前模式

从模式错误中恢复

受软件的控制

使模式指示器难以忽略

夺走用户的控制权

自动重排的显示

变体A：如何令用户烦恼：重排它们的数据

变体B：移动控件

自动移动的窗口

变形的光标

跳动的选项卡

动态菜单

屏幕属于用户

保持惯性

看到并理解变更

可以继续工作

使用户陷于困境的对话框

变体A：没有"取消"

变体B：所有路径都是错误的

变体C：所需的按钮是禁用的

变体D：不清楚的选择

变体E：没有选择

取消按钮无法取消操作

对话框允许用户查看和设置命令选项和对象属性，至少提供两个按钮

应用更改，关闭对话框，并继续执行命令

放弃任何已更改的设置并关闭对话框

变体A：对话框直接编辑应用程序数据

变体B：在选项卡之间切换将保存更改

变体C：向导有一些副作用，cancel按钮不能取消这些副作用

变体D：多层对话框

对话框显示的是应用程序设置的一个副本

选项卡、向导和多层对话框不能成为这种错误的借口

响应性禁忌

常见的响应性禁忌

光标跟不上用户

屏幕上的按钮相应鼠标点击的时间太长，或者根本不响应

菜单、滑动条和滚动条的动作落后于用户操作，破坏了成功操作所需要的手眼动作配合

移动和调整带线啊哦的操作跟不上用户的动作，也没有提供临时的进度显示作为反馈

应用程序没有指示它真处于繁忙状态，而是忽略了用户的存在

当应用程序内部整理时经常不为用户提供响应

冗长的操作不显示进度条

冗长的操作不提供取消方式

应用程序浪费空闲时间，而当用户最终发出一个可预期的命令时，却又要花费很长时间才去执行

应用程序在挂起时不给出任何反馈，也不指明到底发生了什么事

web站点包含很大的图像和动画，只有超高速的因特网链接才能看到

web站点总是重新加载整个页面来相应一些小的编辑操作

响应性不好的原因

响应性的有关事实没有广为人知

用户界面设计人员在设计中很少考虑响应性

同步

延迟

程序员将响应性等同于性能

程序员将用户输入视为机器输入

开发人员使用简单的实现

GUI软件工具、组件和平台不完善

管理者雇佣缺少必要技能的GUI程序员

避免响应性错误：设计原则

响应性不等同于性能

处理资源经常是有限的

用户界面是实时接口

任务对延迟的要求各异，软件不必立即做所有的事情

软件不必按照任务请求的顺序完成工作

软件不必执行所有请求的任务

用户是人而不是计算机程序

避免响应性错误：技巧

及时反馈

立即确认用户的输入

提供忙指示器

为冗长的操作显示进度指示器

显示剩余的工作

显示总体进度

对于百分比的完成，从1%开始，而不是0%

同理，100%要短暂

显示平滑的、线性的进度，而不要显示不规则的、突然变化的进度

使用人们熟悉的精度，而不是计算机的精度

首先显示重要信息

模拟的高负荷计算

在web上提供及时反馈

尽量减少图片的尺寸和数量

提供快速显示的缩略图或概览图，提供只在必要时显示细节的方式

将大量数据分解为较小的部分，并提供在各个部分之间导航的方式

使用层叠样式表来设计和布局页面，而不使用描述性的HTML、框架或表格

在条件允许时使用内置的浏览器组件，而不使用HTML来构造它们

将applet和脚本下载到浏览器，使用Ajax方法

以受限的方式使用浏览器端的动画

并行问题解决方案

延迟非关键任务

超前工作

低负荷时段提前主备对高概率请求的响应

队列优化

重排队列，不按照输入顺序处理

清楚不再需要的任务

动态时间管理

监控时间队列，没在滞后于用户命令时调整策略

监控时间进度，降低工作的质量和数量以赶上进度

预测完成时间，决定如何执行任务

预测时间进度，协商任务质量或决定是否还需要执行此任务

应用程序必须可以声明对时间的要求

应用程序必须可以声明其质量要求

功能至少能够预测其完成时间，并对工作质量作出一些指示

必须有一个能够在时间要求内找到最高质量结果的协商协议

管理禁忌

错误的管理态度

认为用户界面是次要工作

变体A：认为i易用性对于市场成功的影响不大

变体B：认为用户界面只不过是"字体和颜色"

变体C：认为i用户可以适应所有的情况

变体D：合理化

变体E：将GUI工作分配给初级程序员

将开发拥有高质量用户界面的产品放在重要的位置上

易用性对于其在市场上能否成功具有重要的影响

用户界面是"深层次"的问题，而不仅仅是"字体"和颜色

用户可以适应不好的用户界面，但是寄希望于此是有勇无谋的表现

不应因为进度或预算约束而牺牲用户界面

经验很重要

对用户界面人员工作的误解

变体A：将GUI程序员等同于GUI设计人员

缺乏GUI设计经验

GUI设计受工具包制约

差的团队协作技巧

变体B：将图形设计人员等同于GUI设计人员

将工作分配给业务人员将得到业务软件

不重视测试和迭代设计的价值

变体A：敏捷开发/XP只停留在表面

变体B：认为好的实际人员不需要迭代

变体C："易用性测试对我们来说太奢侈了"

测试很昂贵

跳过测试将节省费用

变体D：没有留出时间修复易用性问题

错误的开发过程

无政府主义开发

无政府主义->不一致

无政府主义->更少的客户

变体A：没有设计

变体B：没有标准或指南

变体C：没有监督

UCD和敏捷/XP开发是兼容的

理解客户和用户需求

利用用户和其他任务领域专家的帮助

常测试

迭代设计

高质量的用户界面需要投资

培养程序员树立以客户为中心的设计原则

雇佣交互/用户界面设计人员和易用性测试人员

为程序员提供GUI和WEB指南书籍做参考

确保开发过程中遵守公司和行业的风格指南和标准

使用支持用户界面标准的GUI工具包和模板

将用户界面设计和修改纳入开发进度中

指定一位项目架构师，负责保证软件各个部分之间一致性

将软件显示的所有文本放到消息文件中

让技术作者和编辑检查软件中使用的所有文本消息和标签

进行易用性测试

根据易用性测试结果修改设计

团队中没有任务领域的专业知识

开发任务它们是任务领域的专家

低估用户的任务知识

很难获得任务领域的专业知识

用户的任务领域专业知识是一个重要的组成部分

客服用户参与的组织障碍

聘用专门的设计人员来设计复杂、专业化的应用程序

如果能找到的话就雇佣"双料专家"

使用拙劣的工具和构建块

程序员学习此工具是否容易

程序员使用它开发用户界面是否快捷方便

生成的用户界面是否容易维护

此工具是否符合组织的开发过程

此工具与团队中其他开发工具的兼容性如何

此工具是否可以在开发人员所使用的操作系统上运行

生成的GUI与后台软件及现有组件的兼容性如何

公司目前是否已有此工具

公司是否有部门使用过该工具

生成的GUI需要多少代码和计算机内存

程序员在以前的工作中是否使用过该工具

该工具的价格是多少

该工具的生产者是否对使用该工具的产品征收版税

此工具马努前在计算机行业是否流行或者被认为很时尚

使用该工具开发出的GUI与目标应用程序平台的标准的兼容性如何

使用该工具开发出的GUI与一般的GUI设计标准的兼容性如何

此工具是否能为程序员提供指导，使它们开发出符合实际标准和避免错误的GUI

此工具是否提供应用程序所需的所有GUI控件，或者允许程序员方便的创建它们

此工具是否孕育对外观细节进行细致调整，以便符合特定的公司或应用程序套件的外观

此工具是否在GUI控件和语义或后端组件之间有足够的交流，使得用户可以即使得到有关它们操作的准确的反馈信息

使用该工具包开发的GUI是否能有足够的响应性

使用该工具包开发的GUI是否可以容易地进行国际化和本地化

使用该工具包开发的GUI对于不同类型的用户的可访问性如何

为程序员提供最快的计算机

不要过快的升级程序员的计算机

在低俗计算机上进行测试

用低俗网络连接进行测试