可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。 它是UGC21理念的一种很漂亮的实践，在目的明确的前提下，简单介绍一下主要过程。 首先要招募测试用户。招募测试用户的主要原则是，这些用户要能尽可能地代表将来真实的用户，比如说，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。 然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。 接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来。 测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉。另外，如果用户在测试的过程中没有完全把思考的过程说出来，此时也可以询问他们当时的想法，询问他们为什么做出那些操作。 最后是研究和分析：在可用性测试结束之后，组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得我们可以根据项目进度来选择哪些优先处理。 可用性测试的常见问题与对策 和用户访谈、调查问卷一样，可用性测试也有其特别需要注意的问题。 第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。 其实，可用性测试在产品的各个阶段都可以做。在尚无任何成型的产品时，可以拿竞争对手的产品给用户做；在产品只有纸面原型的时候，可以拿着手绘的产品，加上纸笔给用户做；在产品只有页面Demo的时候，可以拿Demo给用户做；更多的时候，在产品已经可以运行以后，可以拿真实的产品给用户做。不同阶段不同做法，从中都能发现相应的问题。 第二，总觉得可用性测试很专业，所以干脆不做。 可用性测试，听着很专业，但收益又无法量化，所以对很多老板来说，不太愿意在这个上面投入资源，经常因为项目时间过紧被略过。我们知道，可用性测试通常来说做5个左右的用户才可以发现大部分的共性问题，前前后后的准备也耗时不少，但只做一个用户，并且简化步骤，也比不做要好。 对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试，表现为：一个同事，半个小时，在我的座位上，简单的几个任务，比如“将XXX用户的有效期增加一年”，“将YYY公司的状态设置为冻结”，“查询ZZZ公司的员工数”等。结果发现了十几个问题，效率很高。 第三，明确是测试产品，而不是测试用户。 可用性测试要邀请用户来做测试人员，我们在开始之前，应当明确地告诉用户，这个测试的目的是发现软件产品中的问题，而不是要测试用户是否有能力来很好地使用软件。所以，不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。 第四，测试过程中，组织者该做的和不该做的。 刚开始的时候，可以告知用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。 可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作，等等。 做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。如果真觉得用户错了，那也是你找错人了，不是这个人错了。 结束之后，如有可能应该送个小礼品，当然在邀请的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结，并且发给用户，一方面让用户感到他做了一件有意义的事，另一方面也是表示感谢，建立长期和谐的“用户参与产品设计”的氛围。最重要的，这份总结要用于指导产品改进，这才是可用性测试的根本目的。 产品改版的一次冒险 每一个优秀的产品（Gmail、豆瓣（douban.com）、开心网（kaixin001.com）也许是），都是靠着不断的升级、优化、改版才逐渐获得认可的。改版的初衷都是为了产品升级，更好地服务用户，但改版在客观上会挑战用户现有的习惯，所以必须慎之又慎。可用性测试就是一种很合适的方法，来保证产品改版的安全性。对于一个产品经理来说，如何在合适的时机推动一次合理的改版，是一大考验，本节回忆2007年我发起的一次产品改版――网店版从1.0升级到2.0，当时的可用性测试做得太晚，想想真是后怕。 这次改版在页面风格上有极大的变化，网店版1.0的时候，考虑到我们的目标用户全部是淘宝的大卖家，所以沿用了淘宝网“我的淘宝”的页面风格，之后的几个月，随着产品的发展，我们发现在1.0的页面框架下，很多功能设计起来都要瞻前顾后，所以决定颠覆性地把导航菜单从左侧移到上方，释放页面空间，并且改变了很多交互、视觉的细节。 整个过程几乎完全凭借我们的喜好改进，直到上线前几天，才叫了几个用户来做可用性测试，而这时候其实我们已经知道没时间改了，只是想听用户说一声“Yes”来增强自己的信心，如果这时候用户说“No”，绝对是一个灾难。 好在参加测试的用户对我们说了“Yes”，上线后数据分析的答案也是“Yes”，我们才没有因为缺乏经验而造成太多损失。在这之后，我再也不敢这么晚才做可用性测试，联想一下淘宝网“我的淘宝”曾经做过的改版、2007年底豆瓣为了庆祝注册用户过100万的改版、2009年百度贴吧的改版，都因为用户的反对声音太大不得已道歉、改回去，我们真的很幸运。 不好的过程，还算OK的结果，让我事后去恶补了不少常识，对于改版，除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的。 比如先从部分次级页面改起，像“我的淘宝”历时多年的改版； 再如新旧版本并存一段时间，并允许用户自由选择，比如2007年的雅虎邮箱和新浪邮箱改版； 三如小面积试验，选择一小批测试用户放出新版本，监测效果，做用户调研，比如Gmail在发布某些新功能的时候； 四如傍上一个用户已经习惯的风格，比如网店版的前身“高级店铺”升级到网店版1.0的时候，讨论了很多方案，最终还是决定模仿“我的淘宝”的页面风格。 总之，对于改版，对于升级，我们要把“暴力革命”变成温柔和谐的“和平演变”。