可用性测试：“ 如果你想知道某个东西是否容易使用，那么在一些人试图使用的时候观察他们，记录他们在哪里遇到问题。”
可用性测试可以用于平息争论——证明争论的问题根本没那么重要—>会发现更严重的问题
焦点小组： Say sth
可用性测试：Do sth
“你可以看到人们真正的使用情形，而不只是听他们的说法”
① 可用性测试应该贯穿在整个开发设计的过程中。
② 把测试当作一种开阔新体验： 并不是每个人都知道你所知道的，采用你的方式去使用产品。
“它提醒你人们有多么不一样，又有多么相像，带给你看待事物的新视角”
③ 哪怕用错误的用户测试一次，也可以让你发现一些问题。
④ 测试进行得越早越好。
“我们为什么没有早一点做”
一个网站一旦投入使用，改起来就不那么容易了：一部分用户将抵制任何变化
Case: 豆瓣的豆邮 电子绘本里的时间设定
任何在开始时就有助于防止错误的方法都很划算。
可以在设计网站之前，对同类网站进行可用性测试。
持续对团队产出的任何东西进行测试：草图、线框图、页面排版、界面原型、实际产品
⑤ 采用简易的可用性测试
Rocket Surgery Made Easy: The Do-it-Yourself Guide to Finding and Fixing Usability Problem by Steve Krug
“一个半天的测试，就能让你发现太多问题，一个月都修复不完”
不需要也不可能发现所有的问题——>把注意力集中在最严重且由足够资源去修复的问题上
一个月进行一次，每次3个用户（可以弱化样本代表性）
How to Recruit Participants for Usability Studies by Nielsen Norman
测试环境：
安静不被打扰的空间+ 一张桌子+2把椅子+一部电脑（连网）+鼠标+键盘+麦克风
+屏幕共享软件（Go To Meeting/WebEx）+屏幕录制软件（Camtasia）
主试（Facilitator）：耐心、冷静、有同理心、善于倾听、鼓励用户去尝试
⑥ 鼓励任何人来观看测试过程。
买点好吃的零食~
条件： 意见观察室+一台电脑（连网）+屏幕共享软件+大屏幕显示器/投影仪+外置麦克风
观察者需要写下3个最重要的可用性问题，然后进行分享
⑦ 测试任务的选择：根据被测试的产品进行设定。
60min内大约设计35min的测试任务执行
准备足够的任务： 有些人总是会完成得比你预期得要快。
⑧ 一个典型的1小时测试：
欢迎部分（4min）- 任务介绍
提问部分（2min）-了解被试背景
浏览主页（3min）-让被试浏览主页并告知看到了什么
任务测试（35min）-让被试专注执行一些列任务，同时说出当时的想法
在测试过程中，不要做任何事说任何话去影响被试。
问题探查（5min）-就测试过程向被试提问&代问观察室里的人想问的问题
结束部分（5min）-感谢并给予报酬
样例脚本1： Steve Krug’s usability test demo
样例脚本2：Advanced Common Sense - Rocket Surgery Made Easy
【典型问题】 可用性测试中最可能遇到的问题：
① 用户以为自己知道网页上的概念，实际上是错的理解。
② 用户找不到自己要的内容。 说明用户预测错误或者是用户用来描述目标的词汇与网站所采用的不同。
③ 页面内容太多，用户看不到目标内容。
减少页面整体干扰+突出目标内容
【如何决定修复哪些内容】
先修复最严重的问题(不要避重就轻)
每个人写3个问题，然后全部收集起来，根出现据频率排序以后选10个，然后对这10个进行严重程度的评估，再生成一份等级表格。
不需要对每个问题都进行完美修复，当修复到一个程度后即可移出该列表。
另外列出一些比较容易解决的问题
对问题的描述尽可能精简
不要太看重用户对于新功能的期待
对于用户二次尝试(初次受挫)的问题不必过于关注
