|
之前在《首都机场的点烟器》中分析了一个软件系统所处的状态并且列举了不同的状态所需要的展示给用户的各类信息，我们先简单回顾一下：
要设计一个软件系统的操作，除了认清系统的状态以及对应的要素以外，还需要分析操作功能本身。
提供给用户这些功能按钮时，还需要同时告知用户哪些信息？
我们在日常的生活中，需要下决定的时候往往都会要知道什么呢？比如：当银行的业务员向我推荐他家的信用卡时，我需要了解哪些信息后才能下决定？
我大致会向业务员询问这些问题：
这是个啥？哦，信用卡，先花钱，回头再还的那种卡。
这个卡的额度是多少？我能从中先支出多少钱？哦，1W。
我要办了这个卡，要不要每年缴年费？
我要是到时间不还款，会对我造成哪些负面影响不？
我要是办了卡，一直放着不用，没关系吧？
你也可以设想你会问哪些问题，或许你问的具体问题和我问的不完全一样，这不要紧，至少我们问的问题大致都会是分成两类：
1.这是个什么？
2.如果我要办了卡，会给我带来哪些影响？
嗯，当用户面对一个操作，需要抉择是否要执行的时候，需要了解到的信息，可以分为上面这两类。
到这里，对于操作的设计似乎我们已经分析清楚了。嗯，应该说，如果是领导讲话用，说：“操作的设计首先需要交代清楚这个操作是什么，第二需要描述清楚操作将带来的后果。”这不仅够了，而且还足够显示出了发言者高度的概括归纳能力。但是要在实际的设计中能有指导意义，这样的分析还不够。
我们来把这两个要求再细化些：
对操作本身的解释
需要说明：这个操作是什么？干什么用的？能做到什么？
对于大多数操作，并不需要进一步的解释，“删除”功能是干啥的？不用再解释了吧。“发表”，也懂吧。“关闭”，明白吧~“电池标尺重新设置”这个可就不见得谁都明白了。是的，有少数操作本身包含有新概念，这就需要解释了。
操作将带来的后果
我们可以把这个要求细化成以下几点：
- 将付出的成本：时间成本、经济成本、对其他操作的干扰(是否模态)…
上传照片需要花时间；点击了确认支付就要掏钱了；执行了这个操作，其他功能就不能用了，直到这个操作执行完成。
将带来的损失：当前数据将会丢失。
要格式化C盘？C盘的数据将会被彻底删除，不可挽回。
在Qzone中，送好友一个生日礼物，其他好友会不会知道？会不会知道具体是什么礼物？会不会看到具体的礼物卡片上的留言？知道与否将直接影响我的操作。
填写多页的表单页面，当前是第二页，退回去修改第一页的内容，当前页已经填写的内容将不会丢失。告诉用户，用户才敢退回去修改。
给自己的Qzone挂上了很多装扮，导航、播放器、漂浮… 这将可能会使得某些地区的好友在网络高峰时期很难打开你的空间。用户在装扮的时候不见得能意识的到可能存在的潜在问题，但这些问题确实与他的操作相关。
当然，上面的这些总结也不见得够，甚至不见得对。检验操作的描述是否足够的标准是：用户是否能够没有疑惑的做决定。
软件系统状态的要素、操作的要素加在一起，对行为的设计需要具备些啥，就比较完整了：
总结出这些要素的目的并不是要每一个操作、系统都一定白纸黑字的都直接告诉给用户。如果不说用户也能知道，当然就不用说了。
| 
