怎样打造用户友好的软件

一个优秀的软件不仅要有用户需要的功能，还要让用户能用上它，否则只是徒劳。正如对于混乱的代码应该重写成干净代码，而不是加上大段注释一样。用户界面也应力求容易使用，最好是看一下就知道怎么用，而不是加上厚厚的使用手册或使人打瞌睡的培训课程。不要指责用户犯错，而要反思设计的不人性化。

可用性测试

由于开发者通常不是典型用户，对用户的真实需求的把握往往不准确，结果做出来的界面往往不是用户想要的。要避免这情况，就应该让用户更多地参与到开发过程。

在需求分析阶段，可以到用户那边考察（例如一周），详细了解他们的工作流程。同时可参考竞争对手的产品并挖掘其优缺点。
在设计阶段，可以做几种用户界面原型征求用户意见（a/b测试）。
在编码阶段，可以采用增量交付或定期演示的方法，让用户试用，根据用户的反馈进行调整，在征得用户同意后还可收集使用数据作仔细的分析（如发现用户找不到的功能、把用户卡住的功能、太慢的功能等等，还可以还原用户意图怎么使用功能）。
在维护阶段，投入日常使用后往往会暴露更多问题，这时应继续跟踪和鼓励用户反馈，并由此持续改进可用性，这种负责任的态度有助建立和巩固声誉。

经验准则

可用性测试固然重要，但也不能经常打扰用户。幸运的是，经历多年发展，已经总结出许多经验规则，可以在交付用户前就预见到潜在有可用性问题并加以修复。

通用准则

不容易出错。在应该设计产品使用户不易犯错，事实上人为失误往往是糟糕的设计迫使的。假如你把某个危险操作（如格式化磁盘）的按钮放在某个常用操作（如新建文件夹）的按钮旁，那再多的警告也难保用户不按错。不能指望用户精确地按文档说明工作，在你写警告之前，先想一下能否在界面强制这一点。如果你要求用户点B之前必须点过A，你应该在用户点A之前禁用B或者干脆不显示B；如果你只允许输入为几个可能值之一，你就应该用单选框而不是文本框。Murphy定律：每当可能出错时，一定会出错。
可撤销。操作应还尽可能做成可撒消的，这样不仅能限制人为失误的后果，而且有助用户通过实验学会正确的操作。例如应当在删除时把内容暂存到回收箱、在退出程序前记录状态。即使是发邮件一类的操作也可通过延迟发送来实现在一段时间内可撤销。
不要打扰用户。确认对话框就相当令人困扰，它们绝大多数是根本不应存在的，用户往往根本不知道意味着什么。应当把各种功能做成可撤销的，只有真的无法撒销的操作前才有理由要求双重确认。至于给出用户无法理解或不知道如何处理的错误信息的对话框就更没有意义。
做一件事需要的操作数越少越好。每一个步骤都会吓退一些用户，各种参数应该按照标准值或历史值设置默认值，而不是强迫用户选择不知怎么选的选项。即使真的需要多个步骤，也应让用户知道现在是第几个步骤，还有几个步骤。
用户的每个操作都应该有实时反馈。没有反馈的话用户不知道操作已经开始进行还是没有点到，然后往往会惊恐地重复操作。同时，适当的反馈可让用户较早发现错误以防进一步错误。
不要丢失用户数据。例如不要因为一个表单项有格式错误就要求用户重新填写整个表单，定时保存以免强行终止时丢失数据则可能是好的做法。
响应速度要足够快。尽可能让操作可在短时间内完成，耗时的（比如可能需要超过0.1秒的）计算不要在UI线程进行以避免界面无响应，而应该给予进度提示和中止方法。
避免不必要的改版。改版会带来重新学习的成本和无所适从。

对新手友好

熟练者一般比较注重能用。

首先，软件应当容易安装，否则在一开始就给用户挫败感的话他们可能会放弃。软件应该遵循标准的安装方式，例如在Windows下通常是双击安装包、在Linux发行版下是通过包管理器或者./configure&&make&&make install。如果真的需要其它步骤，必须清晰地告知具体安装方法，如在下载页上说明或在企图用标准方法安装时显示，面向有经验的Unix用户的话也可写在README文件。虽然打包通常比编写软件本身要简单得多，但我们看到很多软件在这方面强差人意，如经常遇到各种依赖问题没有自动解决，这是十分可惜的。

其次，功能应当是容易发现的，用户找不到的功能是没有用的。虽然现在有些软件把搜索作为主要操作方式，但不要忘记造成命令行难用的主要原因就在于新手一开始时根本不知道有哪些命令。因此，我们仍然建议在菜单栏展示所有当前可用的功能，并且以任务而非主题主导组织，用用户的语言去表述。通常来说，最常用的功能应该最容易发现。

对熟练者友好

熟练者一般比较注重好用，提高操作效率的途径有：

容许用户配置快捷键，熟练者一般都主要用键盘高效地操作
确保输入焦点落在期望的位置
支持宏，这样可协助用户消除许多重复性的工作

虽然移除不常用功能有利于让界面更干净，但仍然可能有一些用户依赖于它们，移除它们可能会让他们不满。因此，移除功能前宜先通过使用数据确认它真的很少用，再知会用户功能将被移除并同时提议替代方案，然后在一段时间后才真正移除。Java的稳健就是它成功的原因之一：绝大多数二十年前写的代码在最新的虚拟机上仍能运行。

对外地人友好

不同地区的人使用不同的语言、文字、时区、货币，在日期、时间、数字也有不同格式，甚至连图标在不同文化背景下也会有不同的含义。虽然很多人都会若干种外语，对外国文化也可能有点了解，但在熟练程度上始终难以与母语相比。强迫别人使用外语不仅不尊重别人，有时还会构成文化冒犯。因此，对外地人友好一般要保证界面有尽可能多语言的翻译，并留意排除软件中的各种隐含假设（如能否接受Unicode输入输出、能否右到左排版）。关于国际化与本地化的更多细节，请参考《让世界各地的用户都能用上你的软件》。

对残疾人友好

当用户界面设计师日益卖弄花巧的效果时，他们也正在失去越来越大的市场。超过2.85亿视觉障碍人士看不清你精美的的插图、超过3.6亿听觉障碍人士听不清你炫耀的音效、接近10亿活动障碍人士无法精确操作鼠标、还有难以计量的认知障碍人士不知道如何操作你的软件。对于网站来说，对残疾人友好通常也意味着对搜索引擎友好（有利SEO），对使用老旧或移动设备的人也是有益的。

为了形成一个印象，你可以尝试：

闭上眼睛使用屏幕朗读器如orca打开你的网页或软件，体验一下视觉障碍人士的感受
完全不用鼠标只用键盘操作你的网页或软件，体验一下活动障碍人士的感受
让老人或小孩使用你的网页看看他们有没有遇到困难，体验一下认知障碍人士的感受

下面以网页为例说明如何保证可访问性，但相同原则也适用于其它软件。

在MVC模型中，HTML用来表示内容、CSS用于控制样式、JavaScript用来控制交互，把它们用在正确用途有利辅助工具正确地向用户展现内容。特别地，应该总是用与语义最贴切的标签作为容器，如段落用p、标题用h1到h6、列表用ol或ul、按钮用button、页顶用header、页底用footor、导航用nav、正文部分用main、文章用article、边栏用aside，而不是滥用div、span甚至误导性标签后再以CSS或JavaScript控制样式，也不要使用非语义标签。这样屏幕朗读器才能知道内容的层次结构，从而让视觉障碍人士知道标题是什么，并且容许跳转。不要使用CSS呈现内容，另外注意屏幕朗读器可能仍然读出用CSS隐藏的内容。在必须使用JavaScript呈现内容时，必须确保屏幕阅读器能在适当时间提示给用户，既不能错过，也不能太频繁以致干扰用户。另外，小心Flash、Silverlight等插件。

虽然原则是简单，但要持之以恒地坚持这些原则才有用。以下是一个初步的检查清单：

针对视觉或听觉障碍人士：
- 如需使用表格，表头应用th而非td，同时宜加上caption
- 如需使用图片，应当在img标签的alt属性写上其文字描述，需要上下文信息时也可用放在title属性。这些信息可以被屏幕朗读器读出，从而帮助视觉障碍人士。纯装饰性图片可以让alt属性为空字符串以避免干扰视觉障碍人士（否则会读出图片URL），但它们最好用CSS而不是HTML显示。
- 如需使用表单，确保可以用Tab以合理顺序遍历所有需要填写的控件，而且每个控件前有带for属性的label标签告诉用户填写什么。
- 如需使用音频最好提供描述或字幕
- 如需使用视频最好通过video中<track kind="subtitles" src="字幕文件.vtt" srclang="en">之类提供字幕、注释、描述、场景等文本轨以帮助听觉或视觉障碍人士
- 选择不同颜色时宜选择有足够对比的颜色，否则色盲人士可能无法分辨。
- 绝对不要<meta name="viewport" content="user-scalable=no">之类禁止缩放，很多人要放大才能看清网页。
针对活动障碍人士：
- 保证所有操作可以纯键盘完成，包括媒体的控制
针对认知障碍人士：
- 文本应该不容易出现歧义，以帮助认知障碍人士
  - 避免太复杂的词语
  - 避免缩写，或至少在缩写首次出现前提供完整的
  - 避免多意的符号，如“-”可能表示“至”或“减去”，“/”可能表示“或”或“除以”
- 句子或段落不要太长或结构太复杂以帮助认知障碍人士
- 清晰地强调重点以帮助认知障碍人士
- 不容易出错，对于用户错误要提议解决方法
- 操作流程要尽可能短，并提示进度
- 网站应该有一致性，各页面布局相同以避免重复学习的需要，不宜频繁改版，与同类网站也应当相似
- 应当给予用户足够时间完成操作

如希望了解更多，可参考：

一些工具如WAVE可快速检测常见错误。

结语

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

用户界面设计最常见的错误在于把实现方式直接呈现给用户，而不是用户做事的方式。从程序实现角度，可能要区分输入和输出，但用户界面中能输出的地方也应该能够输入。

关键词可用性 web