走廊可用性测试：有多少 UI 真正发挥了功能？
在进行走廊可用性测试时，大多数人会让您的应用程序完全或接近完全发挥作用吗？或者您只是确保链接或流程链正确吗？或者你只是在纸上画画然后就可以了？
我想尽早测试原型并试图找到一个良好的平衡点。但同时我担心一些非功能部件实际上可能无法给出有代表性的结果。
谢谢。
When doing hallway usability tests do most of you make your apps fully or near fully functional? Or do you just make sure the links or flow chain correctly? Or do you just draw on paper and go with that?
I'm would like to test early on a prototype and am trying to find a good balance. But at the same time am worried that some non functional parts might actually not give representative results.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
可用性测试，无论是走廊还是其他地方，只需要您需要测试的功能。在大多数可用性测试中，您应该要回答的具体设计问题并开发原型它可以回答这些问题。例如，如果您需要测试用户是否理解您对表格排序顺序的指示，您所需要的只是一张显示排序指示的表格的纸质图片（表格内容模糊），并询问他们表格是如何排序的。如果你需要测试IA，你所需要的只是一堆网页，除了通过导航菜单链接的标题之外，其他内容都是空的。
您只需要与您为用户提供的任务相关的页面。如果您只是测试IA，那么您只需要规范路径上的页面。如果您还在测试错误恢复，那么您需要脱离规范路径的页面以及完整的导航控件。如果您还在测试错误检测，那么您还需要页面上的内容。
您还可以在更容易的情况下模拟功能。例如，在测试用户是否能够弄清楚如何获得所需的排序顺序时，当用户单击用于对表进行排序的不起作用的控件时，您可以说，“好吧，这样做会得到这个”，然后您移动鼠标并选择一个以新排序顺序显示表格的书签。
在走廊测试中，如果用户突破保真度范围，您可以简单地说：“我还没有制作该部分。我们回到A，然后从那里继续。”当然，您应该注意到用户在您为他们安排的任务中犯了错误。当我预先告诉用户这是一个不完整的原型并且我们目前只测试 UI 的功能 x、y 和 z 时，我没有遇到任何用户抱怨非功能性功能的问题。
对于低保真度原型，我经常向用户称其为“模型”或“图纸”，而不是“原型”，以表明其功能性较低。您可以为缺失的内容添加明显的占位符（例如，“等等，等等，等等......”，“TODO：关于此处的产品图片。”）。如果用户对保真度范围之外的内容发表评论（例如，“这个符号应该是红色的，以便更加突出”），只需记下它，并说该主题正在开发中（例如，“谢谢。我们还没有开始工作”我们现在只是想弄清楚如何组织该网站。”）。
为了使迭代设计对大多数项目可行，使用有限保真度原型进行可用性测试确实是必要的。否则，您会浪费太多的工作来开发必须重做的事情。
Usability tests, hallway or otherwise, only need the functionality that you need to test. In most usability tests, you should go in with specific design questions to answer and develop your prototype to the point where it can answer those questions. For example, if you need to test if users understand your indication of the sort order for a table, all you need is a paper picture of the table showing the sort indication (with the table contents blurred) and ask them how the table is sorted. If you need to test the IA, all you need is a bunch of web pages, empty except for a title, that are linked through the navigation menus.
You only need the pages relevant for the tasks you give your users. If you’re just testing the IA, then you only need the pages on the normative path. If you are also testing error recovery, then you need the pages off the normative path along with the full navigation controls. If you are also testing error detection, then you need content on the pages as well.
You can also simulate functionality when that’s easier to do. For example, in testing if users can figure out how to get a desired sort order, when the user clicks on a non-functioning control for sorting the table, you can say, “Okay, doing that will get you this,” and you take the mouse and select a bookmark that shows the table in the new sort order.
In hallway testing, if users breach the fidelity envelope, you can simply say, “I haven’t made that part yet. Let’s go back to A, and continue from there.” Of course, you should note that the user made a wrong turn in the task you intended for them. I haven’t had any problems with users complaining about non-functional features when I tell them up front it’s an incomplete prototype and we’re only testing the UI for features x, y, and z at the moment.
For low fidelity prototypes, I often call them “mockups” or “drawings” to users rather than “prototypes” to indicate the low functionality. You can put obvious placeholders in for missing content (e.g., “Blah, blah, blah…”, “TODO: Picture of product about here.”). If a user comments on something outside the fidelity envelope (e.g., “This symbol should be red to stand out more”), simply note it, and say that topic is under development (e.g., “Thanks. We haven’t started work on the colors yet. We’re just trying to figure out how to organize the site right now.”).
Usability testing with limited-fidelity prototypes is really necessary for iterative design to be feasible for most projects. Otherwise, you waste too much work developing things that have to be redone.
需要记住的几件事：
因此，如果用户可以看到您有兴趣测试的 UI 部分，并以现实的方式与它们交互（例如，单击按钮和链接），您应该能够收集有用的数据。如果某些链接是死胡同，那也没关系，只要有某种方法可以让用户恢复并继续。基本上，对于原型，“正确”的路径应该有效，但如果不正确的路径不起作用也没关系（只要有一种相当快速的方法可以回到正确的路径）。如果您提出正确的问题，即使是静态故事板（UI 的非功能图）也可以为您提供一些信息，例如“如果您想查看购物车，您会在这个屏幕上做什么？”）。
A couple things to remember:
Therefore, if users can see the parts of your UI you are interested in testing and interact with them in a realistic way (e.g., click on buttons and links), you should be able to collect useful data. If some links are dead-ends, that's okay, as long as there's some way for users to recover and continue on. Basically, with prototypes, the "correct" path should work, but it's okay if incorrect paths don't (as long as there's a reasonably quick way to get back on the correct path). Even static storyboards (non-functioning drawings of a UI) can provide you with some information if you ask the right questions, e.g., "What would you do on this screen if you wanted to view your shopping cart?").
我建议进行几轮可用性测试。首先在纸上，也许稍后在屏幕上，通常在整个应用程序生命周期中（采用敏捷方法）。
对于纸质原型有一个很好的论据。当用户看到屏幕时，即使功能有限，他们也可能会犹豫是否建议更改，因为它看起来“已完成”。
毫无疑问，将所有内容都写在纸上并不是一件小事，但这就是我要开始的地方。可能只从应用程序的一两个部分开始。并确保有人具有良好的人际交往能力和/或解释能力来引导用户完成它。让第二个人在场记笔记。尝试提出开放式问题等。
I would suggest a couple rounds of usability testing. First on paper, perhaps later on screen, generally throughout the application lifecycle (take an Agile approach to it).
There is a good argument to be made for paper prototypes. When users see a screen, even limited functionality, they may be hesitant to suggest changes since it looks "done."
Make no mistake, it's not trivial to get it all down on paper, but that's where I would start. Probably start with just a section or two of the application. And make sure somebody with good people skills and/or explaining skills is there to walk the user through it. Have a second person on-hand to take notes. Try to ask open-ended questions, etc.
对于走廊测试，我将在不实现任何功能的情况下进行测试。
针对在白板或纸上完成的设计进行测试。您会惊讶地发现您在这些最小的模型中发现了这么多东西。而且它们的制作成本非常低廉！
功能原型稍后再说。如果您为可用性主体提供一个功能性界面，他们就不太可能质疑您是否首先实现了正确的功能集。
For a hallway test, I would test with NONE of the functionality implemented.
Test against designs done on a whiteboard or on paper. You'll be surprised at how much you find out in these minimal mockups. And they are very inexpensive to make!
Functional prototypes are for later. If you give your usability subject a functional interface, they are much less likely to question whether you've implemented the right set of features in the first place.
我会让UI具有功能性，这样用户就可以真正使用它，它会比静态图像好得多。人们可以告诉您他们对用户界面是否感到舒服。
I would make the UI functional, so that the user can really play with it, it will be much better than a static image. People can tell you whether they feel comfortable on the UI.
我会确保用户界面中的所有内容都能正常工作，或者至少向您显示一条清晰、明确的消息，指出该功能尚未实现。
向客户展示原型并预先声明功能 X 尚不可用的情况通常会被忽略。他们会尝试原型，点击功能 X 并愤怒地回复“功能 X 不起作用！这确实需要在最终版本中起作用！为什么不起作用？”。客户对产品感到困惑和不满意，这让你自己感到沮丧，因为它掩盖了积极的反馈。此外，你告诉他们这不起作用，为什么他们不能发挥想象力来设想它在最终版本中会如何工作？
让它发挥作用，无论是粗略的版本、虚拟数据，还是一条简单的消息“现在将显示按字母顺序排序的结果”。
I would make sure everything in the UI works, or at least takes you to a clear, unambiguous message pointing out that the feature isn't implemented yet.
Showing prototypes to clients with a disclaimer up front about how feature X doesn't work yet will usually be ignored. They'll try out the prototype, click on featuree X and indignantly reply "Feature X doesn't work! This really needs to work in the final version! Why doesn't it work?". The client is confused and unhappy about the product, and it's frustrating for yourself because it overshadows the positive feedback. Besides, you told them it didn't work, why can't they use their imagination to envision how it would work in the final version?
Make it work, be it with a rough version, dummy data, or even a simple message saying "would show results sorted alphabetically now".