理解可用性

一个优秀的软件不仅要有用户需要的功能，还要让用户能用上它，否则只是徒劳。正如对于混乱的代码应该重写成干净代码，而不是加上大段注释一样。用户界面也应力求容易使用，最好是看一下就知道怎么用，功能都放在找到的地方，每个操作均应有适当的反馈让用户知道后果（但反馈应当是非模态的以免妨碍用户工作），而不是加上厚厚的使用手册或使人打瞌睡的培训课程。

用户界面设计应该立足于用户的视角，而不是内部实现的便利。从微观上看，按任务面非主题组织界面通常更符合用户的心理模型。从微观上看，文字、焦点、提示、快捷键、配置、国际化、错误处理等都会影响用户体验。例如，不要给出用户无法理解或不知道如何处理的错误信息，而应协助用户恢复正常工作（特别是应尽可能保存用户数据，丢失用户大半天的工作成果会使他们很恼火的，不要仅因为表单有一项有问题就重置整个表单），不能让用户觉得都是自己的错，这样很不尊重用户。可见，用户界面设计需要统筹兼顾，决不只是简单地做点美化。

假设开发者是典型用户，那么应该尽早吃自己的狗食。如果开发者自己就觉得不好用，就更不能期望用户会喜欢它。开发者应不断精雕细琢以求让自己满意，开发者乐于使用它后才应考虑发布出去，为了赶时间发布劣质产品造成的恶劣影响是难以弥补的。

假设开发者不是典型用户，由于对用户的真实需求把握不好，做出来的界面往往不是用户想要的，这情况下用户更多地参与到开发过程就是有益的。在需求分析阶段，可以到用户那边考察（例如一周），详细了解他们的工作流程。在设计阶段，可以做几种用户界面原型征求用户意见，这就是所谓的a/b测试。在编码阶段，可以采用增量交付或定期演示的方法，让用户试用，根据用户的反馈进行调整，在征得用户同意后还可收集使用数据作仔细的分析。在维护阶段，投入日常使用后往往会暴露更多问题，这时应鼓励用户反馈，并持续改进可用性，这种负责任的态度有助建立和巩固声誉。

由于人并不是完全机械地工作的，用户有时会犯所谓的操作错误。一方面，在应该设计产品使用户不易犯错，事实上人为失误往往是糟糕的设计迫使的。假如你把某个危险操作（如格式化磁盘）的按钮放在某个常用操作（如新建文件夹）的按钮旁，那再多的警告也难保用户不按错。不能指望用户精确地按文档说明工作，在你写警告之前，先想一下能否在界面强制这一点。如果你要求用户点B之前必须点过A，你应该在用户点A之前禁用B或者干脆不显示B；如果你只允许输入为几个可能值之一，你就应该用单选框而不是文本框。Murphy定律：每当可能出错时，一定会出错。另一方面，应该设计产品限制人为失误的后果，适当的反馈可让用户较早发现错误以防进一步错误，操作应还尽可能做成可撒消的，进行不可撒销的操作前可能应该让用户双重确认。

一个高可用性的程序不是一蹴而就的，而是反复改进的结果，一点一滴积累出来。于是，当你做下一个产品时，很容易重复出现上一个产品解决过的可用性问题。为了避免重复你自己，方法仍旧是抽象，不妨把用户友好组件、撒销机制、配置等部分做成框架以便重用。

最后，推荐一下Donald Arthur Norman的《设计心理学》（The design of everyday things），颇有启发性。