快速而肮脏的可用性测试技巧？
您最好的可用性测试技巧是什么？ 我需要快速& 便宜的。
What are your best usability testing tips?
I need quick & cheap.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
您最好的可用性测试技巧是什么？ 我需要快速& 便宜的。
What are your best usability testing tips?
I need quick & cheap.
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（8）
虽然针对网页设计，Steve Krug 的优秀“别让我思考：Web 可用性的常识性方法" 功能（至少在第二版中），题为“每天 10 美分的可用性测试”的精彩章节，我认为它适用于更广泛的平台。
本章专门讨论了在低预算（没有钱和/或没有时间）环境中快速而肮脏地完成的可用性测试，并说明了获得初步“感觉”的一些最重要的考虑因素。
我特别喜欢的一些观点是：
Joel Spolsky 因提倡“而闻名” 走廊可用性测试”，您可以抓住一些路过的用户并要求他们完成一些任务简单的任务。 部分受到“少数用户产生大部分结果”理念的启发，它也相对方便且便宜，并且可以经常进行。
While aimed at web design, Steve Krug's excellent "Don't Make Me Think: A Common Sense Approach To Web Usability" features (in the second edition, at least), a great chapter entitled "Usability Testing On 10 Cents A Day", which I think is applicable to a much wider range of platforms.
The chapter specifically deals with usability testing done quick and dirty, in a low-budget (no money and/or no time) environment, and illustrates some of the most important considerations for getting an initial "feel" of the thing.
Some of the points I like in particular are:
Joel Spolsky is known for advocating "hallway usability testing", where you grab a few passing users and ask them to complete some simple task. Partly inspired by the "a few users yield the bulk of the results" philosophy, it's also relatively convenient and inexpensive, and can be done every so often.
快速和便宜不会削减它。 您必须投资用户体验框架，首先为您的应用程序或网站定义明确的目标。 我知道这不是人们想听到的，但在多年来监督和观察大量用户测试之后，使用尼尔森的折扣可用性方法在大多数情况下是不够的。 当然，如果你的设计真的很糟糕并且犯了巨大的可用性错误，那么快速而肮脏的做法将会使系统中 80% 的垃圾被清除。 但是，如果你想要长期、优质的可用性和用户体验，你必须从一个好的设计团队开始。 我指的不是优秀的图形设计师，而是优秀的信息架构师、交互设计师、XHTML/CSS 编码员，甚至是 Web 分析专家，他们将确保您的网站/应用程序可以通过明确的目标和指标进行衡量。 我知道，这需要很多钱，但如果你认真对待你的业务（我相信我们大多数人都是如此），我们需要认清现实并预先投资，而不是试图找出整个过程中出了什么问题。事情是在线的。
Quick and cheap won't cut it. You have to invest in a user experience framework, starting with defining clear goals for your app or website. I know it's not what people want to hear, but after supervising and watching a lot of user testing over the years, using Nielsen's discount usability methods is just not enough in most cases. Sure, if your design really sucks and have made huge usability errors, quick and dirty will get 80% of the crud out of the system. But, if you want long-term, quality usability and user experience, you must start with a good design team. And I don't mean good graphic designers, but good Information Architects, interaction designers, XHTML/CSS coders, and even Web Analytics specialists who will make sure your site/app is measurable with clear goals and metrics. I know, it's a lot of $$$, but if you are serious with your business (as I am sure most of us are), we need to get real and invest upfront instead of trying to figure out what went wrong once the whole thing is online.
这里有一些很好的建议。
我在职业生涯早期犯的一个错误是将可用性测试变成了教学练习。 我会花大量时间解释如何使用该应用程序，而不是让用户弄清楚。 它教会了我很多关于我的应用程序是否易于使用或难以使用以及他们在尝试使用该应用程序时的困惑程度。
我做的一件事就是整理一个非常简单的场景，说明我希望用户做什么，然后让他们去做。 它没有分步说明（“单击 A 按钮，然后单击 B 按钮”），而是显示“创建新帐户”和“存款”等内容。 从那时起，用户可以“探索”我的应用程序，我可以看到它是多么容易使用。
无论如何，这相当便宜，而且对我很有启发。
Some good tips here.
One mistake I made earlier on in my career was turning the usability test into a teaching exercise. I'd spend a fair amount of time explaining how to use the app rather than letting the user figure that out. It taught me a lot about whether my applications were easy or hard to use by how puzzled they got trying to use the app.
One thing I did was put together a very simple scenario of what I wanted the user to do and then let them go do it. It didn't have step-by-step instruction ("click the A button, then click the B button") but instead it said things like "create a new account" and "make a deposit". From that, the user got to 'explore' my application and I got to see how easy it was to use.
Anyhow, that was pretty cheap and quite enlightening to me.
您必须观察人们使用您的应用程序。 如果您在一家规模合理的公司工作，请进行一些“走廊测试”。 把走过你家门的人拉进房间，然后说：‘你能在这个系统上运行一下下个月的工资单吗？ 应该只需要两分钟。
希望他们不会有任何问题，也不会对路过的人造成太大的影响。 解决任何问题或平滑任何不必要的复杂和重复的过程。 很多。
另外，请确保您知道什么是可用性以及如何实现它。 如果您还没有阅读过日常事物的设计。
You have to watch people use your application. If you work in a reasonable sized company, do some 'hallway testing'. Pull someone who is walking past your door into the room and say something like, 'Could you please run the payroll on this system for the next month? It should only take two minutes'.
Hopefully they won't have any problems and it shouldn't be too much of an imposition on the people walking past. Fix up any hiccups or smooth over any processes that are unnecessarily complex and repeat. A lot.
Also, make sure you know what usability is and how to achieve it. If you haven't already, check out The Design of Everyday Things.
请不懂技术且不熟悉它的人来使用它。
典型的非技术用户，年迈且心不在焉的少女阿姨。 在非黑客和极客的可用性讨论中被引用； 人们会看到对“蒂莉阿姨测试”的引用。蒂莉阿姨测试（在当今时代可能需要一个更好的名称，但这就是它所提到的）Ask someone non-techy and unfamiliar with it to use it.
The archetypal non-technical user, one's elderly and scatterbrained maiden aunt. Invoked in discussions of usability for people who are not hackers and geeks; one sees references to the “Aunt Tillie test”.The
Aunt Tilly Test(Probably needs a better name in today's day and age, but that's what it's referred to)我回答得很晚，但我正在考虑就一些想法提出类似的问题。 也许最好保留这个问题中的所有内容。
我想说的是：
不要向人们传授您的应用程序。 让他们有新的眼光。
要求他们做一些任务并使用 camstudio 等工具记录他们的操作http://camstudio.org/
测试结束后，让他们回答这么简单的问题。 这是我的清单：
您对这些想法有何看法？
I am answering very late but I was thinking about asking a similar questions about some ideas. Maybe it is better to keep everything in this question.
I would say that:
Do not teach people about your app. Let them have fresh eyes.
Ask them to make some tasks and record their actions with a tool like camstudio http://camstudio.org/
After the test, ask them to answer so simple questions. Here is my list:
What do you think about these ideas?
另一个需要研究的主题是可用性的启发式。 这可以为您提供需要遵循的一般提示。 这是另一个启发式的使用
Another topic to research is Heuristics for usability. This can give you general tips to follow. Here's another use of heuristics
如果您不知道从哪里开始，请从小处开始。 让朋友坐在你的电脑前。 说明您希望他们使用软件完成任务，并观察他们所做的一切。
当他们实际工作时保持沉默是有帮助的。 把一切都写下来。
“约翰在行动前花了 15 秒看着屏幕。他将鼠标悬停在顶部导航栏上，查看它是否包含弹出菜单。他首先点击了“关于我们”，尽管这不是他任务的核心。” 等。然后使用从中获得的知识来帮助您设计更复杂的测试。 对来自不同知识领域的不同用户进行测试。 更复杂的任务和更多的任务。
拍摄他们。 安装在显示器上的网络摄像头是捕捉他们眼睛移动位置的好方法。 录像机以 45 度角从他们的肩膀上方过来是捕捉概览的好方法。 如果你能同步两者的时间，那就加分了。 如果您无法完成这一切，请不要担心。 做你能做的事。
不要把你的测试当作你最后一次需要的测试，并且你想让它完美。 没有完美的。 唯一接近完美的就是多次迭代和多次重复。 只有当测试数量接近软件的实际用户数量时，您才能接近 100% 的置信度。 通常没有人能接近这个数字，但每个人都应该努力做到这一点。
在纳入您认为需要的改进后，不要忘记重新测试人员。 相同的人，不同的人，都可以。
做你能做的事。 不要哀叹你做不到的事。 只是哀叹你本来可以测试但没有测试的东西。
If you don't know where to begin, start small. Sit a friend down at your computer. Explain that you want them to accomplish a task using software, and watch everything they do.
It helps to remain silent while they are actually working. Write everything down.
"John spent 15 seconds looking at the screen before acting. He moused over the top nav to see if it contained popup menus. He first clicked "About Us" even though it wasn't central to his task."Etc.Then use the knowledge you gain from this to help you design more elaborate tests. Tests with different users from different knowledge realms. More elaborate tasks and more of them.
Film them. A web-cam mounted on the monitor is a good way to capture where their eyes are moving. A video recorder coming over their shoulder at 45 degrees is a good way to capture an overview. Bonus points if you can time-sync the two. Don't worry if you can't do it all. Do what you can do.
Don't plan your test as if it's the last one you'll ever need and you want to get it perfect. There is no perfect. The only thing approaching perfection is many iteration and much repetition. You can only approach 100% confidence as the number of tests approaches the number of actual users of your software. Usually nobody even gets close to this number, but everybody should be trying to.
And don't forget to re-test people after you incorporated the improvement you saw were needed. Same people, different people, either is ok.
Do what you can do. Don't lament what you can't do. Only lament what you could have tested but didn't.