1. 易用性概述
易用性即把用户而非系统置于开发过程的中心。这种“以用户为中心进行设计”的概念,是指从设计过程的开始便把用户所关注的东西包含于其中,并规定用户应该是任何设计决定中最重要的因素。
- 易见 Easy to discover。藏得很深的功能就不容易被发现,无法使用。
 - 易学 Easy to learn。学起来容易。易于学习的设计着眼点是针对哪些不太经常完成的任务,因此用户可能会忘记怎么用。
 - 易用 Easy to use。熟练使用的时候可以更快的操作。易于使用的设计着眼点是促进持续的效率,这可能意味者在使用产品之前要经过一定的培训。
 
这三条本身其实是冲突的,需要进行平衡。
我们常常混淆有用性和易用性。
- 有用,这由产品的规划师负责保证。反面例子:比如一台机器很容易使用但并不解决实际问题。很多产品的失败,首先是有用性,也就是市场的失败,而非易用性的失败。
 - 易用,这由易用性工程师负责。比如一台机器有功能但用户不知道如何使用。
 
很明显地一个事实是,如果一个程序非常易用,但却没有什么功能,没有人会有理由去使用它。而如果给用户一个功能非常强大的程序,但却很难使用,那么用户将很可能会抵制它或者寻求其他替代物。分清了一件事物的这两个方面,在分析的时候会避免将所有的问题都归结于易用性问题。
- 可以较少技术支持和服务的成本。
 - 可以提高用户对软件的任何程度。
 - 可以提高产品的竞争力。
 
- 易用性不是随意添加的,易用性是系统设计的一部分。
 - 以用户为中心进行设计是获得良好易用性的最佳途径。
 
正如本文前面所描述的一样,易用性需求不是随意添加的,它是系统良好设计的一部分。因此在设计开始之前必须明确我们的易用性需求,然后才能在此基础上衍生出我们的验收标准。
例子 1.
描述:产品对于大多数用户来说易于学习,无需培训
验收标准:由用户等组成的测试小组中90%的人将在第一次使用该产品时就能成功地通过该产品完成机票订购的工作。
易用性需求应该是具体的、明确的和可以衡量的。比如:“用户友好”。很难找到对“用户友好”的度量标准,我们可以通过简单的提问后发现用户的真实所要。比如:“友好的用户交互界面”等等。
| 
 序号  | 
 易用性工作  | 
| 
 1  | 
 是否有明确的易用性验收标准或易用性目标  | 
| 
 2  | 
 是否在软件需求工作开端就考虑易用性需求  | 
| 
 3  | 
 是否遵循以用户为中心的设计理念  | 
| 
 4  | 
 是否有用户参与系统的测试  | 
| 
 5  | 
 是否将易用性标准作为软件验收的标准之一  | 
| 
 
  | 
 
  | 
| 
 序号  | 
 易用性需求  | 
 分类  | 
| 
 1  | 
 系统界面  | 
 
  | 
| 
 1.1  | 
 界面的一致性  | 
 易学、易用  | 
| 
 1.1.1  | 
 界面的风格是否一致  | 
 
  | 
| 
 1.1.2  | 
 相同的功能的入口和界面操作是否一致  | 
 
  | 
| 
 1.1.3  | 
 控件的使用与排列是否一致  | 
 
  | 
| 
 1.2  | 
 提示信息  | 
 易学  | 
| 
 1.2.1  | 
 菜单和按钮等是否具有提示信息  | 
 
  | 
| 
 1.2.2  | 
 必填项等需要明显说明的地方是否有提示信息  | 
 
  | 
| 
 1.2.3  | 
 提示信息是否一致  | 
 
  | 
| 
 1.3  | 
 界面的配置  | 
 易用  | 
| 
 1.3.1  | 
 是否可以隐藏不必要的信息  | 
 
  | 
| 
 1.3.2  | 
 是否可以更换软件的皮肤  | 
 
  | 
| 
 1.3.3  | 
 是否可以更换软件所使用的图标  | 
 
  | 
| 
 1.3.4  | 
 是否可以更改一些信息的名称  | 
 
  | 
| 
 1.3.5  | 
 是否可以追加一些信息  | 
 
  | 
| 
 1.4  | 
 功能排列  | 
 易学、易用  | 
| 
 1.4.1  | 
 常用功能是否放置在明显的位置  | 
 
  | 
| 
 1.4.2  | 
 不常用功能的摆放是否会干扰常用功能的使用  | 
 
  | 
| 
 1.4.3  | 
 用户能否快速的找到它所需要的功能  | 
 
  | 
| 
 1.4.4  | 
 功能摆放的位置是否符合用户的习惯  | 
 
  | 
| 
 2  | 
 系统功能  | 
 
  | 
| 
 2.1  | 
 安全性与数据完整性  | 
 易用  | 
| 
 2.1.1  | 
 系统是否具有一定的安全性  | 
 
  | 
| 
 2.1.2  | 
 系统是否具有操作日志  | 
 
  | 
| 
 2.1.3  | 
 数据损坏时是否具有修复功能  | 
 
  | 
| 
 2.1.4  | 
 数据是否具有定期保存及备份的功能  | 
 
  | 
| 
 2.1.5  | 
 网络软件是否支持数据的本地缓存  | 
 
  | 
| 
 2.2  | 
 错误操作的自动纠正  | 
 易用  | 
| 
 2.2.1  | 
 是否允许数据自动纠正  | 
 
  | 
| 
 2.2.2  | 
 是否禁止无效数据的输入  | 
 
  | 
| 
 2.2.3  | 
 是否具有明显的报警或提示  | 
 
  | 
| 
 2.3.1  | 
 是否允许用户定义不规则表格  | 
 
  | 
| 
 2.3.2  | 
 是否允许用户调整报表  | 
 
  | 
| 
 2.3.3  | 
 是否允许用户定义新的报表  | 
 
  | 
| 
 3  | 
 帮助系统  | 
 易学  | 
| 
 3.1  | 
 是否提供在线帮助  | 
 
  | 
| 
 3.2  | 
 是否提供用户手册  | 
 
  | 
| 
 3.3  | 
 是否提供实时帮助  | 
 
  | 
| 
 3.4  | 
 是否提供FAQ  | 
 
  | 
| 
 3.5  | 
 是否提供在线学习  | 
 
  | 
| 
 3.6  | 
 是否提供流程向导  | 
 
  | 
| 
 4  | 
 软件升级  | 
 易用  | 
| 
 4.1  | 
 是否是智能客户端  | 
 
  | 
| 
 4.2  | 
 升级时是否可以保证原有数据的完整性和继承性  | 
 
  | 
| 
 4.3  | 
 是否支持补丁方式  | 
 
  | 
| 
 5  | 
 系统安装  | 
 易用  | 
| 
 5.1  | 
 安装界面是否友好  | 
 
  | 
| 
 5.2  | 
 安装过程是否简单  | 
 
  | 
| 
 5.3  | 
 是否有很少的用户输入与设置  | 
 
  | 
| 
 5.4  | 
 安装后是否就可以使用  | 
 
  | 
| 
 
  | 
 
  | 
 
  | 
| 
 
  | 
 
  | 
 
  | 
- 设计工作是否符合易用性需要;
 - 需求工作是否符合易用性要求;
 - 是否满足易用性的描述和验收标准;
 - 是否能进行评价
 
- 王建硕.易用性的三条原则.
 - 软件设计中的易用性.
 - Suzanne Robertson, James Robertson.《掌握需求过程》.人民邮电出版社
 
                    
                
                
            
        
浙公网安备 33010602011771号