新产品的第一次可用性测试
当你梦想中的产品终于以一种可见可感受的形态出现的时候，你是不是就可松口气给自己放一个大假了呢？毕竟从用户调研到最终确定视觉方案，这条路跌跌撞撞走过来已经耗费了太多的心力。
但是且慢！事情还远远没有结束，你现在所处的，是产品设计过程中最容易节外生枝的阶段——实施阶段，你现在要关注的，是如何让参与实施的每一个环节都按照你设计好的方向进行。所以你还是先拿凉水冲冲脸，接着进行下一步工作吧。
在真正进入实施之前，你要做的事情之一就是进行一次可用性测试，以了解用户对这个新产品的反应，同时发现一些你所忽略的、使用上的问题。
在之前的设计过程中，我们完成了各种各样的可交付的文档，现在是检验你的准备工作是否完善的时候了。
首先，我们完成了用户调研，并基于所了解的用户分类设计了几个人物角色。那么，你现在要做的，是根据人物角色的属性，找一定数量（通常是每种人物角色找5～7个）的用户过来进行产品的可用性测试和简单的访谈，以了解不同类型的用户在使用这个新产品时，有可能产生的障碍和疑问。
一说到可用性测试，有人脑海里总会浮现出一面单向透明的镜子，摄像机、价格昂贵的眼动仪等等高级设备。如果你还这么想，你已经落伍了，可用性测试早就跳楼大减价，变成一种再平常不过的UCD方法了。你要做的，除了找对合适的用户以外，再做这两件事就好：
1、完成高保真原型。
你在交互设计阶段完成了线框图，也就是我们常说的低保真原型（别告诉我你没有做），而前不久，你们刚刚确定了一套大家都满意的视觉方案。那么现在，你可以和UI Coding、视觉设计师一起，把这两样东西结合起来，做一套最完整的高保原型。
最好不要拿低保真原型给用户做测试。虽然UCD方法并不排斥低保真原型（甚至纸面原型）的可用性测试，但是这会大大增加用户认知和理解的负担，也从一定程度上加大了你和用户沟通的成本，你会发现你总在解释：“这个地方将来可能是这样、这样、这样……”，而测试结论也因而大大地打了折扣。
也不要等产品开发完成以后才找用户做测试。这个道理大家都知道，我就不啰嗦了。总之，高保真原型是开发成本最低，时间最快的产物（当然，这建立在你的前期工作准备得够完善的基础之上），也是进行可用性测试的最佳产物。
2、设定测试任务。
传统意义上的可用性测试，是观察用户使用产品的、最自然的状态。换句话说，就是把用户扔进可用性实验室，然后你藏到一边去偷看用户怎么折腾你的宝贝产品的全过程。如果Web产品的可用性测试你还这么做，你会发现你的用户总是在漫无目的地随手乱点。你希望用户在打开注册界面时的第一反应是输入用户名和密码，他却鼠标轻轻一点从导航就离开了这个页面。你应该因为这个结论而去掉注册界面的导航吗？显然不是。
被召募过来参加可用性测试的用户，尽管有可能是你的老用户，但他们测试时的心理状态和期望值，与他们平时使用你的产品时完全不一样。用户会揣摹你的心思：这帮产品人员想让我测试什么呢？你想让他在详细信息页面看到“注册”时去点击它，他却认为你想让他在这个页面发表一个评论，结果就是你暗暗咬着牙祈祷他早点发现注册按钮，他却在满头大汗地切换输入法。
你要怎么做才能避免这个情况呢？
之前，我们针对每一个人物角色的目标完成了任务分解，这其中包括任务的重要程度和优先级别。而参与测试的用户，是按照人物角色的属性来召募的。顺理成章地，就应该让这些用户试着在你的新产品上完成他们这类用户最主要、优先级最高的任务，这样你才可能发现他们在完成任务的过程中有可能出现的问题。
你的测试计划可以像这样：
－ 用户类型：刘贝贝（关注细节的浏览型用户）
－ 测试产品：新版详情页Beta1.2.07高保真原型
－ 测试目的：了解用户对新版详情页的适应时间和主要操作
－ 测试任务：
1.查看详细信息（任务编号A001）；
2.分享（任务编号A002）；
3.评论（任务编号A015）。
很简单吧？做Web产品的可用性测试，你只需要做三件事：
－ 找到合适的用户
－ 准备好高保真原型
－ 确定要测试的任务
如果你还有时间和资金，也可以准备下面这些：
－ 一个录制屏幕的软件
－ 录音笔
最后，也是最重要的，你需要准备一双敏锐的眼睛。辅助记录的工具固然重要，但是再强大的工具都无法代替你的思考。你最了解你的产品，你经历了整个设计过程，所以你最清楚用户在哪个地方和你的设计的差距最大。睁大眼睛去观察用户的行为吧，看到有疑问的地方一定要第一时间提出来：“你在找什么？”，事后再询问恐怕谁也不记得当时是什么情形。唯一需要注意的是，别问“为什么这么做”，只问“正在做什么”。
最后（一不小心说了两个“最后”，原谅我的啰嗦），在下结论的时候，尽量保持客观、中立的语气：“用户在搜索时没有选择下拉菜单的选项，输入关键词后直接回车。”而不应该这么总结：“用户不习惯在在搜索时点击下拉菜单。”或“用户没有注意到搜索中的下拉菜单。”除非这是用户自己说出来的话。
9月 26th, 2007 at 17:30
沙发！ 这个思路很可观，瞎糊弄的产品谁心里都没底。
9月 27th, 2007 at 9:34
呵呵,和我目前做的工作是一样的
9月 27th, 2007 at 9:35
“如果Web产品的可用性测试你还这么做，你会发现你的用户总是在漫无目的地随手乱点”
实践中感触到了～ 我是尽量引导受测从A001、002这样做下去，不过会发现有时受测自己触发了B003或者把A007穿插其中了～@_@
9月 27th, 2007 at 11:11
“可用性测试早就跳楼大减价”
哈哈，有意思！
想请教下angela,我怎么确定一个产品已经可以去找用户来测试了呢?“高保真”产品和发布产品的区别在于哪呢？相比之下哪些会简陋下，来达到文中所说“开发成本最低，时间最快的产物”
还有，如果测试发现了一些问题，我们修改之后，有没有必要继续找人测试？
是不是每个产品（功能）都有必要进行测试，怎么判断这个必要性？
期待分享下经验！
9月 27th, 2007 at 17:05
其实我觉得最关键的是用户样本选择的科学性，这个是个大问题啊
9月 28th, 2007 at 15:39
有道理，我犯了忌讳“在下结论的时候，尽量保持客观、中立的语气”，中立是应该，但是我必须要增加一些辅助的语气词，不然开发就不重视这个问题，唉～
9月 29th, 2007 at 15:37
to tony：发现的问题要先收集起来，看看是什么原因造成的问题，是否具有典型性，然后才决定是否修改。改完之后可以先请公司内部不知情的同事来做一下测试（出于时间和成本的考虑），尽量找符合目标用户特征的同事。不是每个功能都要测试的，哪个功能是重要功能做产品设计的人应该很清楚。用户并不知道他要的是什么功能。
9月 29th, 2007 at 15:38
再补充一句：所以我们才需要做用户细分，按照用户群的比例和重要级别去选择样本。
10月 1st, 2007 at 23:40
同意楼上的，样本的选择，对于整个过程是相当重要的！
努力练就一双敏锐的眼睛！
10月 7th, 2007 at 15:20
写的很有道理 不过有一点不是很理解 测试计划中的测试任务 这个是需要产品设计者事先提出给用户的 还是让用户自己摸索的?
10月 7th, 2007 at 22:37
是设计者安排好，事先告知用户的。
10月 16th, 2007 at 22:16
尊敬而可爱的angela，请问：
1 请问“新产品的第一次可用性测试”这个产品是 互联网产品 吗？
2 你的低保真原型的线框图是 用什么软件做 的；
3 “一套大家都满意的视觉方案”是 用什么软件做 的；
谢谢！！
10月 19th, 2007 at 18:25
可爱的葵花（MM？）：1、别的我不知道，我只做互联网产品，所以可能有点局限性，对不住了；2、低保真原型有时用HTML，有时用PPT，有时用Axure（现在还不太熟）；3、视觉方案一开始是图片，用什么做图片……我只用过Photoshop。
10月 24th, 2007 at 16:45
[…] 新产品的第一次可用性测试 - 以用户为中心的设计 Annotated 你需要准备一双敏锐的眼睛 睁大眼睛去观察用户的行为吧，看到有疑问的地方一定要第一时间提出来：“你在找什么？”，事后再询问恐怕谁也不记得当时是什么情形。唯一需要注意的是，别问“为什么这么做”，只问“正在做什么”。 在下结论的时候，尽量保持客观、中立的语气： […]
10月 24th, 2007 at 16:59
[…] 新产品的第一次可用性测试 - 以用户为中心的设计 Annotated […]
12月 27th, 2007 at 1:17
[…] (0709a)产品设计的评估和测试：新产品的第一次可用性测试 […]
3月 5th, 2008 at 17:14
[…] 看Angela的新产品的第一次可用性测试，总结其中的 […]
3月 22nd, 2008 at 21:23
一说到可用性测试，有人脑海里总会浮现出一面单向透明的镜子，摄像机、价格昂贵的眼动仪等等高级设备。如果你还这么想，你已经落伍了，可用性测试早就跳楼大减价，变成一种再平常不过的UCD方法了。
顶一下，有条件上没条件创造条件也要上。
7月 21st, 2008 at 10:53
请问：做了测试后的反馈文档应该以什么标准写？要写些什么要素？你有没有什么格式化的文档能分享下吗？
2月 4th, 2009 at 17:05
大致的流程总是这样的
不过有案例最好
11月 15th, 2011 at 12:37
受益匪浅啊