文字大小:- +

简单经济的可用性测试 上手指南

2007年09月28日 下午 19:50
作者:Ami | 话题:

读过《Don’t Make Me Think》的人肯定记得,作者在其中提到了简单的可用性测试。不过用个摄像机什么的,似乎不太适合我们这边的情况,在国内的中小型企业,实际的尝试和运用中,还是需要不少变通的。今天就来谈谈我在实践中得出的一些经验。

如果:
你所在的公司刚开始推行UCD,一切都刚起步;
没有固定的人手,没有很多的资源,测试研究的时间和经济成本非常局限;
你看了不少有关的书和文章,但实际开始做的时候还是觉得有不少困惑

那么,希望这篇文章可以帮助你。


时间

测试的时机
理想地说,可用性测试尽早开始越好,也应该是产品开发的一环,可以有一个迭代的过程。但是对于初次的尝试来说,不一定能够做到:也许你的Boss不希望把“半成品”拿出来给人看,也许你们的开发进度紧迫插不进这样的时间,但是也不必放弃,晚测试总比不测试好,实在不行就把发现的问题放到下个版本去修改。亡羊补牢,为时未晚。
当你的同事和上司看到了可用性测试的价值后,你做测试也慢慢上手了,就能争取到加入开发环节的机会、迭代测试和开发的机会。或者你的产品频繁有少量改动的更新,这样子测试问题也不大。
你需要的,只是抽出下面提到的一些时间。

准备时间
测试前,你可能需要在一两周的工作时间穿插可用性测试的准备工作。若是刚开始在公司尝试可用性测试,你应该写一份简单的测试计划——告诉你的Boss你要做什么事情、也帮助自己规划做测试的一系列工作。
然后也许你需要申请一些资源,空间、硬件、人员协助等等~
Check一下这次要测试的功能,设计一下测试的任务。如果是第一次测试,心里过一下整个测试的过程,开始-测试时的引导-结束,有机会做次导测的话会让你更有信心。
还有就是招募受测。这个根据你招募的方法需要的时间不同,具体的招募请见下面的部分。

测试时间
准备好了,和受测也约好时间,就可以开始测试了。
你的受测很可能是上班族,这也就意味着测试会安排在非工作时间,比如晚上、周末。就算你很经济,用的是同事,也可能因为他们工作繁忙需要一起占用午休时间或者下班后多留一会儿。>_<真是辛苦,测试难免会需要你加班。而唯一的好处就是,如果你是在本职工作之余做这件事,对原先工作的进度影响就没那么大了。

分析&结果分享时间
测试结束之后,整理下你的记录(如果有条件录像的话,还要回看录像),分析归纳写一份测试报告,写下发现的问题,附上些截图或者关键录像片段。报告不必弄得很详细,目的是为了把测试发现的问题让同事了解。个人觉得比较好的是PPT,不必很多文字,可以现场讲解问题的具体情况和背后的原因、还可以大家一起讨论修改的方案。如果没时间做presentation,给同事看文档,写简单一些,挑重要的写。
如果你有录像而且有时间编辑,绝对推荐做一些这样的片段:一个受测反反复复就是找不到某个功能在哪里、或者多个受测都在同一个地方犯同样错误的重复片段——等他们坐立不安地看完,然后开发和设计就会主动说,这个,该改!嘿嘿,这时候我总是开心得窃笑~
根据公司的需要或者你的职能,可以针对发现的问题提一些大致的修改方案,或者组织相关人员讨论等等~记得要把测试的效果落到实处,哪怕只能在下个版本中去弥补那些问题。

谁来做可用性测试?
也许就是正在读本文的你。是关注用户体验的开发人员?设计师?或者PM?介于公司规模、产品特性,可能没有专职的可用性测试人员,最初尝试可用性测试,可能只是团队中的一员抽空来做这件事情。这是最经济的做法,不过记得,这个人要:

客观,不要因为是自己的产品在测试和分析的时候不自觉去袒护它;
有观察力和分析力,这样才能让测试起到成效;
与人沟通的能力,引导你的受测、在公司里争取尽可能的资源和协助。

关于人数,一人虽然辛苦些,但是就能完成。若两人搭档更好,尤其是测试时,可以一人引导、一人负责记录。

受测的招募
保密协议?测试费用?如果这些问题让你打退堂鼓了,不妨先请公司同事作为你的受测。不过记得不要请产品的开发或者测试人员啊,我不死心地试过一次,真的不合适>_<。你可以请和产品的设计开发无关的,比如行政部门的美眉、新来的同事、另外一个产品项目的成员等等,不单解决了费用和保密的问题,而且受测招募也很快捷,不过记得要和同事还有上司沟通好哦。

测试招募真正的用户当然最好了。这里有一些很经济的方法:

去问问客服,有没有一些可以来参加测试的用户?或者请他们在最近接触用户时邀请他们来参加测试;
你可以靠平时累积一些受测用户的资料,比如抽奖等推广活动等等,去问问相关的同事吧;
还有,就是发动同事们,大家把可以作为受测的亲朋好友们推荐给你~

关于受测的人数,根据测试的产品变化:只是增加几个功能的小版本,3~5人;全新的版本,可能5~8人,简单的可用性测试,控制在10人以下。关于这个,经典的理论:5个受测发现80%的可用性问题

地点

简单的房间即可
既然是说简单经济的、初次尝试的可用性测试,当然不会有单向玻璃之类高级的东西~你需要的只是一间不受打扰的房间,可以用产品的电脑。可以临时占用间会议室,有条件的话就找个固定的地方,建一个简易的Lab。我们公司的Lab,小小一间里摆着电脑桌和沙发茶几,平时不做测试的时候做小会议室、中午时候是休息室、有人面试时是接待室,超级多用哦~够经济实惠吧~

移动的lab
若你的产品可以单机运行,或者是个没什么带宽要求的互联网产品,那么还可以带上你的笔记本电脑,把受测请到一茶一坐之类可以上网的安静茶坊里,一样可以坐下来测试。请你的用户喝一杯茶/咖啡,就可以了解他使用产品的情况。这个方法,同样使用于做访谈。

可用性测试并不是件难事,用Angela的话说,可用性测试早就跳楼大减价啦~ 成本可以降低,门槛也可以降低,尝试一两次简单经济的可用性测试,会是在公司中推行UCD很好的起步。关键是去尝试、根据自己所在企业的情况灵活应变。同样的,你也可以尝试其他的一些方法,或是访谈、或只是在平时注意观察他人的使用、询问他们的意见。

合适的才是最好的,当你找到了适合的产品的方法和方式,一定能帮助你改善产品的用户体验。

转载请注明出自UCDChina.com,谢谢。

相关文章

评论(13)

  1. 有点意思,多谢

  2. 可用性测试可以根据具体的产品来实施,最简单的就是用专家评估的方法:做一个产品的可用性问题检测表,一名专业的可用性或UX人员在使用产品的过程中进行对照评分,得出修改意见。这应该是最廉价的了。对于一些刚开始推行UCD公司。可以由此慢慢展开。

  3. 我就想知道你费这么大劲得出的修改意见等,最后有百分之多少得到了真正的落实?

  4. 理论值是一百,实际的话就要具体问题具体分析了,哈哈

  5. @久装鳖即成鳌:对于大多数问题我们会有讨论,根据严重程度、开发进度等因素决定修改方案,统计一下的话——80%~90%吧

    @兔子(感觉像要对自己说话):感觉相比只有一个UX的评估,我觉得可用性测试的驱动力更大一些,更能落到实处

  6. 个人对引导用户这个人需要做什么比较感兴趣?还有如何有效地记录测试过程?

  7. 看了《Don’t Make Me Think》的,不过感觉我们现在的工作环境等等似乎离书中所说的相差甚远,我们如何将自己的工作很好的在这些问题中去合理实现,也很重要的!

  8. 刚看了一点那本书  确实很好  楼上的说和现实相距甚远 我可不觉得  其实有时候我们只要把这些理念深入大脑 在做设计时候已经是一种进步的理念  当你把这些理念传达给你的客户或者同事时 他们就会有一种被你引导的感觉  这样才有可能给他们一条明确的路线 让他们理解你的设计的思路  所以才不会说一些"我不喜欢某某颜色""我觉得红色更好"的话等等  我觉得无论最后他们相不相信这对我们来说都是一种进步  和思想的跨越(特别是你成功"攻克"了一位或者几位客户)

    我也是初学者 有些说不太准确 情见谅  我的师兄在迅雷 我想进QQ  所以现在再看这方面的书  很幸运看到了这么多而且好的网址和大侠  哈哈哈  幸运啊

  9. 我不太赞成利用业余时间来测试,最好正常工作。:) 我太死板了?谁都有家庭,上班还是要休息好,身体重要!老板应该拿出一定的时间来做必要的工作,无谓的加班是没办法的办法。

  10. 除了任务化的测试功能外,应该还有一个整体的测试比如导航等。指定一个可用性的规范也是必要的,因为有些可用性的问题并不能在任务测试中发现。

  11. 关于受测的人数,根据测试的产品变化:只是增加几个功能的小版本,3~5人;全新的版本,可能5~8人,简单的可用性测试,控制在10人以下。关于这个,经典的理论:5个受测发现80%的可用性问题

    ?哪个经典的理论啊?只记得启发式评估5个专家发现75%的可用性问题。

  12. 受教了,一直想实践可用性测试,但是我目前的工作不能提供给我这样的机会实践,学习。看了这篇文章,我知道自己可以怎么做了。

  13. […] 简单经济的可用性测试指南 http://ucdchina.com/blog/?p=319 […]

发表评论

您必须登录后才能发表评论。

UCD大社区 - 网址导航 - 书友会 - 讨论组