可用性工程的笔记(13)

>我来写笔记

按有用程度 按页码先后 最新笔记

第123页

Kidult (向来欠读)

通常可以两户的可用性度量指标包括： - 用户完成规定任务所用时间； - 在限定时间内完成的任务数量（或完成大任务的比例）； - 正确的交互操作与所发生错误之间的比率； - 从错误中恢复所用的时间； - 用户出错的数量； - 随后导致的错误操作数量； - 用户用到的命令或其他功能的数量（或是所发出命令的绝对数量，或是所用不同命令与功能的数量）： - 用户从未用到的命令或其他功能的数量； - 在测试后交流中，用户能记住... (更多)

通常可以两户的可用性度量指标包括：
- 用户完成规定任务所用时间；
- 在限定时间内完成的任务数量（或完成大任务的比例）；
- 正确的交互操作与所发生错误之间的比率；
- 从错误中恢复所用的时间；
- 用户出错的数量；
- 随后导致的错误操作数量；
- 用户用到的命令或其他功能的数量（或是所发出命令的绝对数量，或是所用不同命令与功能的数量）：
- 用户从未用到的命令或其他功能的数量；
- 在测试后交流中，用户能记住的系统功能的数量；
- 使用手册或帮助系统的频度，以及使用时间；
- 手册或帮助系统有多少次解决了用户的问题；
- 用户在测试期间对系统肯定和批评的比率；
- 用户表达明显的挫折的次数；
- 表示喜欢用该系统而不喜欢用某个特定竞争产品的用户比例；
- 用户不得不试图解决某个无法解决的问题的次数；
采用高效策略的用户与使用低效策略的用户比例；
- 用户不与系统进行交互的“呆滞”时间：用户等待系统响应所造成的延迟，或是系统等待用户思考所造成的延迟；
- 用户注意力从真实人物被吸引到其他地方的次数。 (收起)

2012-06-03 21:23:23 回应

收藏
推荐
第77页

Kidult (向来欠读)

1.美观，精简的设计在屏幕上每增加一个额外的功能或信息，都意味着用户需要学习更多的东西，误解的可能性就会增加，用户从中查找所需的信息就会更困难。每当给系统添加一项功能，用户就需要多学习一些东西。颜色应当仅仅用于区分和强调的目的，而不要用于提供信息特别是提供量化信息。 Case1：在对一些有经验的公司电弧目录服务人员进行研究后发现，当屏幕显示信息只是半满时，找到显示在屏幕左上1/4区域的目标需要... (更多)

1.美观，精简的设计
在屏幕上每增加一个额外的功能或信息，都意味着用户需要学习更多的东西，误解的可能性就会增加，用户从中查找所需的信息就会更困难。每当给系统添加一项功能，用户就需要多学习一些东西。
颜色应当仅仅用于区分和强调的目的，而不要用于提供信息特别是提供量化信息。
Case1：在对一些有经验的公司电弧目录服务人员进行研究后发现，当屏幕显示信息只是半满时，找到显示在屏幕左上1/4区域的目标需要5.3秒，而当屏幕全满时需要6.2秒。
Case2：在某项研究中发现，用户使用某种电子表格进行公示输入的准备时间是2.9秒，另一种电子表格是4.6秒。第一种表格之所以快，因为它仅提供一种公式输入方法，用户不需要考虑采用哪一种方法。而在另一种表格中提供了多种输入方法，用户不得不花费更多的时间来选择方法。
2.使用用户的语言
3.将用户的记忆负担减到最小
识别而不是回忆：包括描述、提示、命令、操作等
4.一致性
5.通过有效的反馈信息提供显著的系统状态
- 0.1秒是让用户感觉到系统立即做出了响应的时间上限，此时除了显示结果外不需要其他反馈。 - 1.0秒是让用户思维不被中断的上限，但用户会感到延迟。 - 10秒是让用户注意力保持在对话过程中的上限。
超过10秒的操作考虑使用进度指示器。如果无法在10秒内完成任务，应当允许中断任务并取消操作。
6.清楚地标识退出
所有对话框和系统状态都应当有取消按钮或其他退出机制。用户界面设计中的一个基本法则是，无论如何改进用户界面，用户依然会犯错误，应当让用户尽可能方便地从错误中恢复。
7.方便快捷的使用
快捷键，提前输入，快速跳转的通道，默认值/操作，提供交互历史操作
8.协助用户认识，分析和改正错误
出错信息设计的四个简单原则：
- 不要使用难懂的代码
- 精炼准确，直指问题、原因和解决办法
- 提供建设性帮助
- 不要威胁或责备用户
9.预防出错
10.提供帮助和说明 (收起)

2012-06-03 08:54:45 回应

收藏
推荐
第48页

Kidult (向来欠读)

任务分析的输出通常包括一些列用户想用系统实现的事情（目标），实现这些目标所需的所有信息（前提条件），所需之行的所有步骤及其相互依赖关系，所需产生的各种输出和报告，用来判定这些结果的质量和可接受性的标准，以及用户在执行或准备执行任务是与其他人交流信息的通信需求。有时候解决某个问题，可能对于那些没有遇到该问题的用户来说，会是的界面更糟。需要对有多少用户也会遇到这个问题，又有多少用户受到到修改设计的... (更多)

任务分析的输出通常包括一些列用户想用系统实现的事情（目标），实现这些目标所需的所有信息（前提条件），所需之行的所有步骤及其相互依赖关系，所需产生的各种输出和报告，用来判定这些结果的质量和可接受性的标准，以及用户在执行或准备执行任务是与其他人交流信息的通信需求。
有时候解决某个问题，可能对于那些没有遇到该问题的用户来说，会是的界面更糟。需要对有多少用户也会遇到这个问题，又有多少用户受到到修改设计的不利影响进行分析。
Nielsen提到了记录设计方案选择的理由，这个应该考虑在以后工作中尝试。一来帮助自己和团队理清头绪，记录共识，也可以在合作中减少反复沟通、知会的成本。 (收起)

2012-06-01 21:11:13 回应

收藏
推荐
第6页

Kidult (向来欠读)

可用性警句 - 不能凭想象和猜测——以对用户及其任务的理解为基础 - 用户总是对的——用户的态度、观念和行为是自然的 - 用户并不总是对的——用户并不会准确表达需求 - 用户不是设计人员 - 设计人员不是用户 - 副总裁不是用户 - 少就是多 - 细节是重要的 - 帮助并不能帮助 - 可用性工程是一个过程 ========================== 简化可用性工程方法的基础是四种技术： - 用户和任务观察 - 剧情 - 简化自言自语 ... (更多)

可用性警句
- 不能凭想象和猜测——以对用户及其任务的理解为基础
- 用户总是对的——用户的态度、观念和行为是自然的
- 用户并不总是对的——用户并不会准确表达需求
- 用户不是设计人员
- 设计人员不是用户
- 副总裁不是用户
- 少就是多
- 细节是重要的
- 帮助并不能帮助
- 可用性工程是一个过程
==========================
简化可用性工程方法的基础是四种技术：
- 用户和任务观察
- 剧情
- 简化自言自语
- 经验性评估
==========================
有用性（usefulness）：系统能否用来达到某个想要的目标
- 实用性（utility）：系统的功能在原理上是否能够做所需要的事情
- 可用性（usability）：用户能否很好地使用系统的功能
1 可学习性（learnability）：描述特定熟练程度的常用方法，是说明用户必须能够成功完成某个特定任务。在分析可学习性时，不仅要度量用户需要花多长时间掌握整个系统，还应当度量需要花多长时间可以达到能够做些有用的事情的熟练程度。
2 效率（efficiency）：度量的典型方法，是确定关于技能水平的某种定义，寻找一些具有这种技能水平的有代表性的用户样本，度量这些用户执行某些典型测试任务所用的时间。
3 可记忆性（memorability）：一种度量方法是对于在特定时间段内没有使用系统的用户，进行测试，度量用户执行某些特定任务所用的时间；另一种方法是对用户进行记忆测试，在他们结束一个使用系统的过程后，让其解释各种命令的作用，或者说出完成某种功能的命令。
4 出错（errors）：通过用户执行某个特定任务时，统计不能实现预定目标的操作册数。
5 满意度（satisfaction）：一般用Likert量表或语义差异尺度给系统打分。
对可用性来说，两个最重要的问题是用户的任务以及他们的个体特征和差异。区分用户经验水平的三个主要方面：
-对计算机的了解；
-使用特定系统的技能；
-对任务领域的理解。 (收起)

2012-02-23 20:33:35 回应

收藏
推荐
第126页

may^^

回顾式测试辅导方法：培养熟练用户 (更多)

回顾式测试
辅导方法：培养熟练用户 (收起)

2012-01-11 20:23:14 回应

收藏
推荐
第125页

may^^

如果用户问：“我能这么做吗？”，实验人员不应该回答，但是可以用反问来让用户继续说话，“如果你这么做了你认为会有什么结果？” (更多)

如果用户问：“我能这么做吗？”，实验人员不应该回答，但是可以用反问来让用户继续说话，“如果你这么做了你认为会有什么结果？”
(收起)

2012-01-06 10:16:00 回应

收藏
推荐
第124页

may^^

Think Aloud：用户的评述中常常含有一些生动和明确的引证，把它们用在报告中，可以使报告更加生动和令人印象深刻。但与此同时，如果过分重视用户关于什么会造成麻烦、什么有帮助的说法的话，边做边说方法也会给可用性问题的原因造成假象。例如，观察中发现，用户在测试的第一部分忽视了对话框中的某个文本框。在他们最终发现该文本框后，可能会说如果它位于对话框的其他什么地方的话，他们就会立即看到。需要注意.. (更多)

Think Aloud：

用户的评述中常常含有一些生动和明确的引证，把它们用在报告中，可以使报告更加生动和令人印象深刻。

但与此同时，如果过分重视用户关于什么会造成麻烦、什么有帮助的说法的话，边做边说方法也会给可用性问题的原因造成假象。例如，观察中发现，用户在测试的第一部分忽视了对话框中的某个文本框。在他们最终发现该文本框后，可能会说如果它位于对话框的其他什么地方的话，他们就会立即看到。需要注意到是，不能依赖这样的陈述。在测试进行到这一部分时，如果用户忽视了关键对象，实验人员应该记下此时他们正在做什么。显示用户实际看着什么地方的数据，比有关用户自己声称的如果把文本框放在其他地方就会看到它，要可信得多。
Think Aloud可能提高绩效。 (收起)

2012-01-06 09:57:56 回应

收藏
推荐
第123页

may^^

用户不与系统进行交互的“呆滞”时间：用户等待系统响应所造成的延迟，系统等待用户思考所造成的延迟。 (更多)

用户不与系统进行交互的“呆滞”时间：用户等待系统响应所造成的延迟，系统等待用户思考所造成的延迟。

(收起)

2012-01-06 09:51:00 回应

收藏
推荐
第七章其他可用性评估方法

不读书没文化

7.1 观察法 7.2 问卷调查与访谈 7.3 焦点小组 7.4 记录实际使用情况（日志法）  与后续访谈结合使用 7.5 用户反馈 7.6 可用性方法的选择表可用性方法汇总方法生命周期阶段所需用户人数主要优点主要缺点经验性评估早期设计，方法设计过程的“内循环” 无能发现单个可用性问题，能发现熟练用户碰到的问题。没有涉及真实的用户，故无法再用户需求方面有“惊人发现”。绩效度量竞争性分析，最终测试至少... (更多)

7.1 观察法
7.2 问卷调查与访谈
7.3 焦点小组
7.4 记录实际使用情况（日志法）
 与后续访谈结合使用
7.5 用户反馈
7.6 可用性方法的选择
表可用性方法汇总
方法生命周期阶段所需用户人数主要优点主要缺点
经验性评估早期设计，方法设计过程的“内循环” 无能发现单个可用性问题，能发现熟练用户碰到的问题。没有涉及真实的用户，故无法再用户需求方面有“惊人发现”。
绩效度量竞争性分析，最终测试至少10人硬性数据，对结果容易比较。不能发现单个可用性问题。
边做边说反复设计，形成性评估 3~5人准确了解用户的错误想法，测试费用低。用户感到不自然，熟练用户很难用语言表述。
观察任务分析，后续研究 3人或以上生态有效性；发现用户的真实任务；建议系统功能与特征。很难约定安排，实验人员无法控制。
问卷调查任务分析，后续研究至少30人发现用户主观偏好，容易重复进行。需要进行问卷预答（避免出现误解）。
访谈任务分析，后续研究 5人灵活，可以深入了解用户观点和体验。耗时，难以进行分析、比较。
焦点小组任务分析，用户参与每组6~9人自发产生的结果，小组互动。分析起来困难，有效性低。
记录实际使用最终测试，后续研究至少20人可发现很常用（或不常用）的功能，可连续的采集数据。需要分析程序来处理大量数据。侵犯用户隐私。
用户反馈后续研究上百人跟踪用户需求和想法上的变化。需要专门部门来处理回复。
 可以性方法的组合 (收起)

2011-09-01 15:16:51 回应

收藏
推荐
第六章可用性测试

不读书没文化

 可靠性（置信区间）  有效性 1.1 测试目标和测试计划  测试计划  测试预算发现可用性问题（i）=N（1-（1-λ）i）  试点测试 1.2 招募测试用户  销售人员、特定用户  新手用户还是熟练用户  用户间还是用户内测试 1.3 选择实验人员 1.4 用人来进行测试的伦理问题 1.5 测试任务  选择测试任务的基本原则就是所选择的测试任务要尽可能的代表系统的最终使用；  应当把任务设.. (更多)

 可靠性（置信区间）
 有效性
1.1 测试目标和测试计划
 测试计划
 测试预算发现可用性问题（i）=N（1-（1-λ）i）
 试点测试
1.2 招募测试用户
 销售人员、特定用户
 新手用户还是熟练用户
 用户间还是用户内测试
1.3 选择实验人员
1.4 用人来进行测试的伦理问题
1.5 测试任务
 选择测试任务的基本原则就是所选择的测试任务要尽可能的代表系统的最终使用；
 应当把任务设计的比较小，这能能在有限的测试时间内完成，但任务也不能小到微不足道的程度；
 测试任务不要轻佻、滑稽或有冒犯；
 测试任务可以用来增强用户的信心。
1.6 测试的几个阶段
 准备
 介绍
 测试不交流；不评价；不提供帮助
 事后交流
1.7 绩效度量方法

可用性度量模型
通常可以量化的可用性指标包括：
 用户完成任务所有时间；
 在限定时间内完成任务数量（或完成任务的比例）；
 正确的交互操作与所发生错误之间的比率；
 从错误中恢复的时间；
 从虎出错的数量；
 随后导致的错误操作数量；
 用户用到的命令或其他功能的数量；
 用户从未用到的命令或其他功能的数量；
 用户从未用到的命令或其他功能的数量；
 在测试交流中，用户能记住的系统功能的数量；
 使用手册或帮助系统的频度，以及使用时间；
 手册或帮助系统有多少次解决了用户的问题；
 用户在测试期间对系统肯定和批评的比率；
 用户表达明显的挫折（或明显的欢喜）的次数；
 表示喜欢用该系统而不喜欢用某个特定竞争产品的用户的比例；
 用户不与系统进行交互的“呆滞”时间；
 用户注意力从正式任务被吸引到其他地方的次数。
6.8 边做边说法（出声思考）
优点：对使用过程中喜欢和不喜欢的地方发表评论
 协同交互方法：让两个测试用户同时使用一个系统；使用于儿童；容易找到大量用户，费用低廉时。
优点：比单一用户边做边说跟自然；
缺点：用户可能采用不同的学习和使用计算机的策略。
 回顾式测试：如果在测试期间录了像，就可以让用户温习录像的内容来收集额外的信息。
优点：在难以找到有代表性的测试用户时尤其重要；可以从每个测试用户那里获得更多的信息；
缺点：每个用户要用双倍的时间，不适合报酬高的用户，或没有太多时间的用户。
 辅导方法：实验人员引导用户在正确的方向上使用系统。
优点：面向用户群较小、很特殊或报酬很高时；还用与想用熟练用户进行测试但却没有找到任何熟练用户的情况。
6.9 可用性实验室
 需不需要录像
用处：首先找到可用性问题，然后回到录像中准确调查有多少用户存在这样的可用性问题，以及他们在每个问题上耽误的时间。
 没有摄像机的录像
 便携式可用性实验室
 可用性信息亭
(收起)

2011-08-30 18:26:16 回应

收藏
推荐

<前页 1 2 后页>

笔记是你写在书页留白边上的内容；是你阅读中的批注、摘抄及随感。

笔记必须是自己所写，不欢迎转载。摘抄原文的部分应该进行特殊标明。

>可用性工程