新年的第一篇翻译,关于原型的可用性测试。
可用性不可能随意地杜撰编造,它贯穿了整个产品设计过程,需要不断地被开发和提炼。如果你想要拥有最好的产品,你必须从原型设计起便开始考虑真实用户的使用场景。 制作原型已经是一项非常繁复的工作了,我们为什么还坚持在初期阶段把可用性测试纳入其中呢?这是因为,人们不喜欢难用的产品,除非你的原型是可用的。 毋庸置疑,你设计的产品是给真实的人所使用的,因此也应该在真实的用户身上进行测试。制作原型的目的就是试验测试,所以只有使用真实用户测试才有意义。 基于这些,下面让我们看看如何将可用性贯穿设计/制作原型过程,如何在原型设计前进行可用性测试,同时我们也提供了一些原型可用性测试的建议。 原型设计前的可用性测试可用性测试并非一定从原型开始——事实上,只要你手头已有一些资源,你就应该尽快开展可用性测试。在这个阶段,可用性测试虽然主要偏概念,但是能够帮助你确定原型的导航方式和信息结构。最常见的原型设计前可用性测试方法包括: 这种方法简单而明确,能够帮助你获得关于产品信息结构的用户偏好。将你产品的所有元素都写在卡片上,然后要求用户在已设定的类型下(“封闭式”)或是根据用户自身感受(“开放式”)进行卡片排序。 作为卡片分类法的“姊妹测试”,树形测试法能够评估现有信息结构的有效性。将你的网站/app简单基本化,把主要的信息结构呈现给用户,并要求用户点击以完成设定的任务。你需要记录用户是否选择了正确的路径,如果不是,需要记录干扰用户点击正确路径的原因。 有时候理解用户的最佳方法就是直接询问用户。这听起来很简单,然而要真正把握用户访谈中的微妙和策略仍是非常困难的。 越早解决问题总是好的,这些初步的测试能够确保在原型设计之前原型的概念是正确的。 正确的用户和正确的用户任务尽管可用性测试方法不尽相同,但是毋庸置疑的是,无论哪种方法都需要用户,大部分方法也都涉及到用户任务。鉴于用户和用户任务是所有可用性测试中最为关键的两个因素,下面我们将简要地解释如何完美处理这两个因素。 1. 招募用户 在建立典型用户角色之后,现在你应该对目标用户有一个清晰的认识,同时也能帮助你基于用户行为进行用户分群。事实上,你无须为用户的人口统计数据而纠结——最大的用户区别因素往往是用户是否了解他们所处的领域/行业、是否拥有经验,而非性别、年龄或是地理位置。 知道招募谁仅仅是第一步,更棘手的是如何寻找并成功招募到这些用户。Jeff Sauro提炼了如何找到用户测试的理想用户的7种最佳方法。 2. 确定用户任务 用户任务决定了用户在测试期间做什么,因此也决定了你究竟是在测试哪一个可用性因素。Ubuntu的可用性测试专家赵婷婷提出了在设计用户任务时需要注意的一些区别,主要包括了两大区别: a) 直接任务 vs 场景任务:直接任务是准确命令的(如,“在网站上搜索一份炭火烤鸡配方”),场景任务则是在一个特定场景下进行的(“你现在想为一些老朋友举办一场宴会,你需要一份炭火烤鸡配方”)。记住,通常情况下优先选择场景任务;只有当你在测试技术数据时,直接任务才比场景任务更胜一筹。 b) 封闭式任务 vs 开放式任务:封闭式任务明确定义了完成任务的标准;相比而言,开放式任务则允许用户以多种方式完成任务。封闭式任务一般用以测试特定的功能,开放式任务更适用于了解用户是怎么想的。例如,“这个周末你的朋友将举办一场生日派对,请找一个能容纳15人的派对场所”属于封闭式任务,“你听到你的同事们在讨论iWatch,你希望能够进一步地了解iWatch”则属于开放式任务。 原型可用性测试的一般性建议
第一个问题也是最常被问的问题是,可用性测试是否需要主持人。尽管无主持人的可用性测试的确拥有许多优势,对于原型测试,我们仍建议需要设置一名主持人。考虑到原型必然是“不完整”的,测试主持人不得不回答用户对界面的各种疑问。 可用性测试的另一个常见错误是当用户碰到困难时停止或者改变测试。记住,可用性测试的目的是为了发现并解决问题,因此用户碰到困难恰恰表明这是一次成功的测试。例如,如果用户在尚未在原型中开发的路径迷失,你可以询问他们“为什么选择这条路径”以及“你认为这条路径应该能实现什么”。针对失败的用户任务询问的后续问题可能能够获得比“完美地完成一次用户任务”更有价值的反馈。
不同的原型保真度
|
|
来自: rainforest007 > 《待分类》