陈颂光
全栈工程师,能够独立开发从解释器到网站和桌面/移动端应用的各类软件。
关注我的 GitHub

理解可用性

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

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

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

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

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

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

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

关键词 可用性 方法论