- 易见 Easy to discover。藏得很深的功能就不容易被发现,无法使用。
- 易学 Easy to learn。学起来容易。易于学习的设计着眼点是针对哪些不太经常完成的任务,因此用户可能会忘记怎么用。
- 易用 Easy to use。熟练使用的时候可以更快的操作。易于使用的设计着眼点是促进持续的效率,这可能意味者在使用产品之前要经过一定的培训。
- 有用,这由产品的规划师负责保证。反面例子:比如一台机器很容易使用但并不解决实际问题。很多产品的失败,首先是有用性,也就是市场的失败,而非易用性的失败。
- 易用,这由易用性工程师负责。比如一台机器有功能但用户不知道如何使用。
- 可以较少技术支持和服务的成本。
- 可以提高用户对软件的任何程度。
- 可以提高产品的竞争力。
- 易用性不是随意添加的,易用性是系统设计的一部分。
- 以用户为中心进行设计是获得良好易用性的最佳途径。
例子 1.
序号 | 易用性工作 |
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.《掌握需求过程》.人民邮电出版社