首都机场的吸烟室里并不像其他机场那样放几个固定的打火机，而是点烟器，和车载点烟器基本是一样的：先按下加热，加热好后，它会自动弹起，拔出来，里面的电阻丝已经是红红的了，就可以点烟了。
上图为车载点烟器，与首都机场的点烟器一样，加热过程中只是被按下去了，未显示进度，也未能形象的表现出“正在加热”的含义。
我走到点烟器的近前，按下，让它加热，然后等待，等了一会儿还不见动静，不知是仍在加热还是出了故障。吸烟室里很多人，感觉自己被别人看着，不会用这玩意儿很尴尬，干脆不等它弹起就直接拔出来看个究竟，原来真的是还没完全加热好，还好，勉强能用，对在烟上，使劲抽了两下，算是点着了烟。
如果这个点烟器在加热过程中能有更明确的提示会更好，比如：加热中有一个小红灯在不断闪烁，更完美的方案是能真正的显示出加热的进度…
腾讯新大厦很漂亮，但很多同事都会对着电梯挠头。
按了电梯门旁边的下箭头按钮之后，你只能看到向下的按钮是亮的，即，电梯知道你要下楼。而不知道电梯当前走到哪里了，无法预估电梯到来的时间。因此，大家只能期盼的望着电梯门，并且挠头。电梯门前散落下不少挠掉的长发、短发、直发、卷发、头发茬儿（那是我挠掉的）…
系统当前的状况看似与使用没有直接联系，但用户却可以通过了解系统当前状况预估电梯到达的时间，从而决策，是悲情的去爬楼梯还是继续等待。
如上的两个经历，使我回想起公司">校园招聘时交互设计的一道笔试题：
这个界面有啥问题？
一个很明显的问题是：缺少终止操作的按钮。不能停，只能等。
以上三个例子都是关于处于运动、变化中的系统。这样一个系统到底需要具备哪些要素才不会出上面那种种问题呢？
以下是关于变化中的系统所需包含的要素：
要素1-当前进度(描述当前状态)
对状态的描述有笼统和精确两种层次。点烟器加热过程中有个闪烁的小红灯是一种笼统的描述，说明系统当前正在工作中，类似于windows系统的沙漏光标。当前下载到了54%是精确的描述，不仅说明系统正在工作，并且表明具体的进度，让用户有可能预估剩余的时间。
要素2-系统最终将达到的结果(描述当前状态)
对于电梯，最终的结果是电梯到来；对于下载界面，最终是下载完成。对最终到达结果的描述并不见得是一条单独的信息，能让用户认知到即可。
要素3-辅助用户预估完成时间的信息-进度变化的速度等(描述当前状态)
下载大文件用的下载软件，一个下载任务通常要若干小时才能完成，进度相对缓慢，只根据进度的变化，用户并不能很好的预估最终完成还需要多久，当前下载速度之类的信息可以辅助预估。
要素4-终止操作（提供操作）
终止掉当前正在变化的状态，恢复到变化开始之前的状态。
要素5-其他操作（提供操作）
在当前变化状态下，除“终止”操作之外的其他操作。 例如，最小化、隐藏至后台运行、降低运行速度…
前三点是描述系统当前的状态，后两点是提供操作。
这几类要素并不见得一定要有，总结出这些要素的价值在于：避免因考虑不周全而出现设计缺陷。你的系统没有更多的“其他操作”当然没必要特意搞一个出来填补“其他操作”这项的空白。
下面，让我们把注意力集中到软件、网站产品上来。
有了上面这些要素，设计一个变化中的系统，大概不会出太大的问题了。接下来的问题是：上面这些针对“变化中的系统”总结出来的要素，是不是可以更广的应用？推广到全人类？
让我们站远一些，来看看“变化中的系统”在整个软件产品这个大集合中的位置。
一个软件、网站，原本是由若干个稳定的系统组成的。比如：网络影集首页、单个相册列表页、照片详情页…用户不做操作，这些状态是不变的。通过用户的操作，一个网站从这个稳定的系统跳到另外一个稳定的系统：
在这些跳转过程中，有时，一个操作会产生一个相对复杂的行为，需要比较长的时间，比如：在一个网络相册中，添加照片，一个空相册要变成一个装好照片的相册，需要一个上传照片的过程，上传照片的过程就是一个“变化中的系统”，这个系统最终会自动达到上传完毕的稳定状态。
对稳定的系统也可以总结出“要素”以避免设计中的考虑不周：
要素1-描述当前状态
对系统当前状态的描述。
例如：收货确认，确认支付，登录…
要素2-操作
当前可进行的若干操作。
同样是“状态”和“操作”两类，但不需要再细化了。比起变化中的系统，稳定的系统简单不少，这也是为什么我们通常不会着力分析这样常规的页面，而更倾向于分析那些上传、下载界面的设计要素。
变化中的系统中，“要素2-系统最终将达到的结果”，在前面只着眼于变化中的系统时，这项要素显得并没多大价值。现在将变化中的系统和稳定的系统放在一起，来看整个产品，“系统最终将达到的结果”就有价值了。因为变化中的系统，只是一个中间过程，在相册列表页面上点了添加照片，用户的期望是最终看到照片添加到这个列表中，在上传照片页面漫长的等待中，需要告诉用户，这里耽误了半天时间，是为了让照片能添加进去。
综合上面的两类系统，可以用下面这张图整体示意一下：
以上的“稳定的系统”、“变化中的系统”都是从最开始的那几个例子发展开来的，是一个特定的视角，通过这个视角来分析设计。为的还是解决设计中可用性的问题，具体的说，是“操作前，结果可预知；操作后，操作可撤销。”的问题。
仔细琢磨你会发现，只是总结了系统整体的要素还不足够，要确保“可预知”“可撤销”还需要单独对操作进行分析，就是上图中那些按钮所代表的操作。单独对它们进行分析，总结出操作在设计时所需要的要素，与系统整体的要素结合在一起，才能比较好的保证“可预知”“可撤销”。关于操作的分析。
鉴于上面的这些文字读起来很是吃力，接下来关于操作操作的分析会读起来同样吃力，我想还是分成两篇，分开来说吧。
（以上的分析要特别感谢交互设计同行、中国人民的老朋友：justkiddings。）
在《首都机场的点烟器》中分析了一个软件系统所处的状态并且列举了不同的状态所需要的展示给用户的各类信息，我们先简单回顾一下：
要设计一个软件系统的操作，除了认清系统的状态以及对应的要素以外，还需要分析操作功能本身。
提供给用户这些功能按钮时，还需要同时告知用户哪些信息？
我们在日常的生活中，需要下决定的时候往往都会要知道什么呢？比如：当银行的业务员向我推荐他家的信用卡时，我需要了解哪些信息后才能下决定？
我大致会向业务员询问这些问题：
这是个啥？哦，信用卡，先花钱，回头再还的那种卡。
这个卡的额度是多少？我能从中先支出多少钱？哦，1W。
我要办了这个卡，要不要每年缴年费？
我要是到时间不还款，会对我造成哪些负面影响不？
我要是办了卡，一直放着不用，没关系吧？
……
你也可以设想你会问哪些问题，或许你问的具体问题和我问的不完全一样，这不要紧，至少我们问的问题大致都会是分成两类：
1.这是个什么？
2.如果我要办了卡，会给我带来哪些影响？
嗯，当用户面对一个操作，需要抉择是否要执行的时候，需要了解到的信息，可以分为上面这两类。
到这里，对于操作的设计似乎我们已经分析清楚了。嗯，应该说，如果是领导讲话用，说：“操作的设计首先需要交代清楚这个操作是什么，第二需要描述清楚操作将带来的后果。”这不仅够了，而且还足够显示出了发言者高度的概括归纳能力。但是要在实际的设计中能有指导意义，这样的分析还不够。
我们来把这两个要求再细化些：
对操作本身的解释
需要说明：这个操作是什么？干什么用的？能做到什么？
对于大多数操作，并不需要进一步的解释，“删除”功能是干啥的？不用再解释了吧。“发表”，也懂吧。“关闭”，明白吧~“电池标尺重新设置”这个可就不见得谁都明白了。是的，有少数操作本身包含有新概念，这就需要解释了。
操作将带来的后果
我们可以把这个要求细化成以下几点：
● 将付出的成本：时间成本、经济成本、对其他操作的干扰(是否模态)…
上传照片需要花时间；点击了确认支付就要掏钱了；执行了这个操作，其他功能就不能用了，直到这个操作执行完成。
● 将带来的损失：当前数据将会丢失。
要格式化C盘？C盘的数据将会被彻底删除，不可挽回。
● 对隐私的影响：您的好友是否会知道这个操作。
在Qzone中，送好友一个生日礼物，其他好友会不会知道？会不会知道具体是什么礼物？会不会看到具体的礼物卡片上的留言？知道与否将直接影响我的操作。
● 将不会引起哪些损失。
填写多页的表单页面，当前是第二页，退回去修改第一页的内容，当前页已经填写的内容将不会丢失。告诉用户，用户才敢退回去修改。
● 可能存在的风险。
给自己的Qzone挂上了很多装扮，导航、播放器、漂浮… 这将可能会使得某些地区的好友在网络高峰时期很难打开你的空间。用户在装扮的时候不见得能意识的到可能存在的潜在问题，但这些问题确实与他的操作相关。
当然，上面的这些总结也不见得够，甚至不见得对。检验操作的描述是否足够的标准是：用户是否能够没有疑惑的做决定。
软件系统状态的要素、操作的要素加在一起，对行为的设计需要具备些啥，就比较完整了：
总结出这些要素的目的并不是要每一个操作、系统都一定白纸黑字的都直接告诉给用户。如果不说用户也能知道，当然就不用说了。
来源：http://www.chouyu.com.cn/?p=314