什么是认知演练
编辑认知演练法是一种可用性检查方法,用于识别交互系统中的可用性问题,重点关注新用户使用系统完成任务的难易程度。认知演练是特定于任务的,而启发式评估则采用整体观点来发现这种和其他可用性检查方法未发现的问题。该方法植根于这样一种观念,即用户通常更喜欢通过使用系统来完成任务来学习系统,而不是例如学习手册。该方法因其能够以低成本快速生成结果而备受赞誉,尤其是与可用性测试相比时,以及在编码甚至开始之前的设计阶段早期应用该方法的能力(可用性测试的一个共同特征)。
简介
认知演练从任务分析开始,该分析指定用户完成任务所需的步骤或动作的顺序,以及系统对这些动作的响应。然后,软件的设计人员和开发人员作为一个小组完成这些步骤,在每个步骤中问自己一组问题。在演练期间收集数据,然后编译潜在问题的报告。最后,重新设计软件以解决已识别的问题。
认知演练等方法的有效性很难在应用环境中衡量,因为在开发软件时进行受控实验的机会非常有限。通常,测量涉及比较通过应用不同方法发现的可用性问题的数量。然而,Gray和Salzman在他们1998年的戏剧性论文“损坏的商品”中对这些研究的有效性提出了质疑,证明了衡量可用性检查方法的有效性是多么困难。可用性社区的共识是认知演练方法在各种环境和应用程序中都能很好地工作。
简化的认知演练程序
编辑完成任务分析后,参与者进行演练:
- 定义演练的输入:可用性专家列出场景并通过解释完成任务所需的操作对所述场景进行分析。
- 识别用户
- 创建用于评估的示例任务
- 创建完成任务的动作序列
- 接口的实现
- 召集演练:
- 演练的目标是什么?
- 演练期间将做什么
- 演练期间不会做的事情
- 发布基本规则
- 一些共同的基本规则
- 没有设计
- 不为设计辩护
- 没有辩论的认知理论
- 可用性专家是会议的领导者
- 一些共同的基本规则
- 分配角色
- 呼吁服从领导
- 浏览每个任务的动作序列
- 参与者通过针对每个子任务问自己一组问题来执行演练。通常四个问题是
- 用户会尝试实现子任务的效果吗?例如,用户是否了解需要此子任务才能达到用户的目标
- 用户会注意到正确的操作可用吗?例如,按钮是否可见?
- 用户会明白,想要的子任务可以通过动作来实现吗?例如,右键是可见的,但用户不理解文本,因此不会点击它。
- 用户是否得到适当的反馈?执行操作后,用户会知道他们做了正确的事情吗?
- 通过回答每个子任务的问题,可用性问题将被注意到。
- 参与者通过针对每个子任务问自己一组问题来执行演练。通常四个问题是
- 记录任何重要信息
- 可学习性问题
- 设计思路和差距
- 任务分析问题
- 使用演练中学到的内容修改界面以改进问题。
CW方法没有考虑几个社会属性。只有可用性专家在认知演练过程中注意让团队为所有可能性做好准备,该方法才能成功。这往往会加强基本规则并避免准备不足的团队所带来的陷阱。
认知演练的常见缺点
编辑在教人们使用演练法时,Lewis&Rieman发现有两个常见的误解:
- 评估者自己不知道如何执行任务,因此他们在界面中跌跌撞撞地试图发现正确的操作顺序——然后他们评估跌跌撞撞的过程。(用户应识别并执行最佳动作序列。)
- 演练方法不会测试系统上的真实用户。演练通常会比您在单个测试会话中发现的单个xxx用户发现的问题多得多
抑制认知演练过程存在社会约束。这些包括时间压力、冗长的设计讨论和设计防御。当设计迭代发生在开发过程的后期时会造成时间压力,此时开发团队通常会感到实际实施规范的压力很大,并且可能认为他们没有时间正确评估它们。许多开发人员认为CW效率不高,因为他们花费的时间量和他们面临的时间压力。设计团队在CW期间而不是在制定结果之后花费时间尝试解决问题。评估时间花在重新设计上,这会抑制演练的有效性并导致冗长的设计讨论。多次,设计师可能会因为他们的作品甚至被评估而感到被冒犯。由于演练可能会导致他们已经面临在允许时间内完成的压力的项目上进行更多工作,因此设计师将在演练期间过度捍卫他们的设计。他们更有可能争论不休,并拒绝看似显而易见的变化。
内容由匿名用户提供,本内容不代表vibaike.com立场,内容投诉举报请联系vibaike.com客服。如若转载,请注明出处:https://vibaike.com/134012/