在进行走廊可用性测试时,你们中的大多数人是否使您的应用程序完全或接近完全功能?还是您只是确保链接或流链正确?或者你只是在纸上画画然后继续?
我想尽早在原型上进行测试,并试图找到一个很好的平衡点。但同时也担心一些非功能部件实际上可能无法给出具有代表性的结果。
谢谢。
在进行走廊可用性测试时,你们中的大多数人是否使您的应用程序完全或接近完全功能?还是您只是确保链接或流链正确?或者你只是在纸上画画然后继续?
我想尽早在原型上进行测试,并试图找到一个很好的平衡点。但同时也担心一些非功能部件实际上可能无法给出具有代表性的结果。
谢谢。
需要记住的几件事:
因此,如果用户可以看到您有兴趣测试的 UI 部分并以真实的方式与他们进行交互(例如,单击按钮和链接),您应该能够收集有用的数据。如果某些链接是死胡同,那没关系,只要用户有某种方式可以恢复并继续。基本上,对于原型,“正确”的路径应该可以工作,但如果不正确的路径不起作用也没关系(只要有一种相当快速的方法可以回到正确的路径上)。如果您提出正确的问题,即使是静态故事板(UI 的非功能图)也可以为您提供一些信息,例如,“如果您想查看您的购物车,您会在此屏幕上做什么?”)。
可用性测试,走廊或其他,只需要你需要测试的功能。在大多数可用性测试中,您应该使用特定的设计问题来回答和开发您的原型,使其能够回答这些问题。例如,如果您需要测试用户是否理解您对表格排序顺序的指示,您只需要一张表格的纸质图片,显示排序指示(表格内容模糊)并询问他们表格是如何排序的. 如果您需要测试 IA,您所需要的只是一堆网页,除了标题之外是空白的,它们通过导航菜单链接。
您只需要与您给用户的任务相关的页面。如果您只是测试 IA,那么您只需要规范路径上的页面。如果您还在测试错误恢复,那么您需要离开规范路径的页面以及完整的导航控件。如果您还测试错误检测,那么您也需要页面上的内容。
您还可以在更容易的情况下模拟功能。例如,在测试用户是否能够弄清楚如何获得所需的排序顺序时,当用户单击一个无法对表格进行排序的控件时,您可以说:“好吧,这样做会得到这个”,然后您用鼠标选择一个以新排序顺序显示表格的书签。
在走廊测试中,如果用户超出了保真度,您可以简单地说:“我还没有完成那部分。让我们回到 A,然后从那里继续。” 当然,您应该注意,用户在您为他们准备的任务中犯了错误。当我预先告诉他们这是一个不完整的原型时,我没有遇到用户抱怨非功能性功能的任何问题,我们目前仅测试 UI 的功能 x、y 和 z。
对于低保真原型,我经常称它们为“模型”或“图纸”给用户,而不是“原型”来表示低功能。您可以为缺失的内容添加明显的占位符(例如,“Blah, blah, blah...”、“TODO:关于此处的产品图片。”)。如果用户对保真度范围之外的内容发表评论(例如,“这个符号应该是红色的,以便更加醒目”),只需注意它,并说该主题正在开发中(例如,“谢谢。我们还没有开始工作还没有颜色。我们现在只是想弄清楚如何组织网站。”)。
使用有限保真原型进行可用性测试对于迭代设计对于大多数项目来说是可行的确实是必要的。否则,你会浪费太多的工作来开发必须重做的事情。
我建议进行几轮可用性测试。首先在纸上,也许稍后在屏幕上,通常在整个应用程序生命周期中(采用敏捷方法)。
对于纸质原型有一个很好的论据。当用户看到一个屏幕,即使是有限的功能,他们可能会犹豫是否建议更改,因为它看起来“完成”。
毫无疑问,将所有内容写在纸上并非易事,但这就是我要开始的地方。可能只从应用程序的一两个部分开始。并确保有良好的人际交往能力和/或解释能力的人在那里引导用户完成它。让第二个人在手边做笔记。尝试提出开放式问题等。
对于走廊测试,我会测试没有实现的功能。
针对在白板或纸上完成的设计进行测试。你会惊讶于你在这些最小的模型中发现了多少。而且它们的制造成本非常低!
功能原型供以后使用。如果你给你的可用性主题一个功能界面,他们就不太可能首先质疑你是否实现了正确的功能集。
我会让 UI 功能化,让用户真正可以玩它,它会比静态图像好得多。人们可以告诉你他们在 UI 上是否感觉舒服。
我会确保 UI 中的所有内容都能正常工作,或者至少将您带到一个清晰、明确的消息,指出该功能尚未实现。
向客户展示原型并预先声明功能 X 无法正常工作通常会被忽略。他们会试用原型,点击功能 X 并愤愤不平地回复“功能 X 不起作用!这确实需要在最终版本中起作用!为什么不起作用?”。客户对产品感到困惑和不满意,这让您自己感到沮丧,因为它掩盖了积极的反馈。此外,你告诉他们这行不通,为什么他们不能用他们的想象力来设想它在最终版本中的工作方式?
让它发挥作用,无论是粗略版本、虚拟数据,还是简单的消息“现在将显示按字母顺序排序的结果”。