/home/wwwroot/west263zx/public_html/zx/wp-content/themes/dux/single.php 作为产品经理,我推荐你了解快速可用性测试-西部数码新闻资讯门户
新闻资讯门户
互联网、云计算领域最新资讯
首页 > 互联网 > 产品经理

产品经理作为产品经理,我推荐你了解快速可用性测试

这篇文章,希望整理一些东西,让大家对快速可用性测试(Guerrilla 可用性测试)有初步的了解。

作为产品经理,真的会、也的确是会遇到用户测试的各种问题,如何针对目标实施巧妙、灵活的用户研究,这一定让不少产品、设计师死了很多脑细胞。

可用性测试这个系列,从第一篇 Whatsapp 相关的可用性测试文章之后,到现在将近两个月的时间,我通过翻译、自己撰写,甚至是自己操作可用性测试,不能说是完全掌握,但入门应该是可以了。

这篇文章,希望整理一些东西,让大家对快速可用性测试(Guerrilla 可用性测试)有初步的了解。当然,如果可能的话,希望你能在工作中运用起来,并形成自己的方法。

什么是可用性测试?

从非严谨的角度来说,可用性测试大多是针对用户对产品“可用”和“好用”的测试,而较少的涉及“有用”的测试。我的理解是:“有用”大多是商业价值和市场研究的重点。

当然,如果你是市场研究院或者是战略计划制订者,使用快速可用性测试来达到目的也是可行的。这里有一些实例,能够帮助你了解可用性测试是什么:《6 个实例告诉你:可用性测试究竟是什么?

从严谨的角度来说——相对的,而且是我自己的理解——可用性测试涉及产品的各个环节,而且相关方了解可用性测试,并且有意而为之的话,会对各环节的相关方有一定的帮助。你可以从《如何激发益相关者开展可用性测试?》这篇文章,初步了解下利益相关方可用性测试。

可用性测试获得的大多是定性的结果,主要是针对用户任务过程中,使用、操作、体验产品的时候的动作、表达等,总结归纳出对产品的简介,从而为后续调整优化产品简历一定的数据基础。

可用性测试的技巧

可用性测试是一种非常流行的技术,或许产品经理、设计师、UX设计师在以各自的理解实践和运用着。它快速、低成本,而且能获得真实的用户反馈。快速可用性测试的实施要从其自身情况决定,但有一些简单实用的技巧能够确保测试产生更好的结果。

这包括:

  1. 确定目标;
  2. 注意偏见;
  3. 让参加者之情;
  4. 给予奖励;
  5. 保持真诚;
  6. 鼓励用户反馈中;
  7. 参与而不是主导;
  8. 随时记录;
  9. 有一个正式的反馈提取过程;
  10. 按时完成。

你可以阅读《有了这 10 个技巧,做好 Guerrilla 可用性测试不用愁》来详细了解以上这些技巧。

7 步可用性测试

在《Guerrilla 可用性测试:7 步 DIY 属于你的可用性测试方法》一文中描述了,在开始快速可用性测试前,需要和团队一起了解以下 3 个问题:

  • 可用性测试如何起作用?
  • 从哪去找合适的测试志愿者?
  • 什么时候开始测试?

接下来,你可以用这 7 步实施一次可用性测试:

  • 第一步:设计任务列表;
  • 第二步:定任务优先级;
  • 第三步:将任务设置在场景中;
  • 第四步:开始测试;
  • 第五步:发现问题;
  • 第六步:解决问题;
  • 第七步:再次测试、验证,形成常态。

如果你觉得实施过程中依旧存在一些问题,希望你能阅读下《如何像专家一样针对原型进行可用性测试?》。文章中,对原型前的可用性测试、招募用户、撰写任务描述、原型保真度等做了详细的讲解。

可用性测试任务描述

测试过程中任务描述(或者说测试脚本)也对测试有重要的影响,任务描述、尝尽设置的优劣,对测试有不可忽略的影响。如果任务不对,你做什么都是错的,当然可用性测试也不会收到什么有效的反馈。

在《Guerrilla 可用性测试:7 步 DIY 属于你的可用性测试方法》中,你应该对可用性测试的任务有了一定的了解,文中还举了几个什么是好、一般和不好的任务例子。而在如何把可用性测试的任务描述写的更好?中,比较详细清楚的介绍了如何写出更好的可用性测试任务描述,你不想了解下?

具体操作

在实施快速可用性测试的具体操作过程中,需要测试多少用户,才能满足测试的目的呢?

可用性研究中要测试多少个用户?》和《做可用性测试时,只需要5名用户参与测试就够了》两篇文章中对快速可用性测试用户数量做了阐述,精心设计可用性测试无疑是浪费资源,最佳的结果是测试用户不超过 5 个用户,在测试过程中尽可能多地采用小测试。

在早先的研究中,Tom Landauer 和我表明,在 n 个用户的可用性测试中发现的可用性问题的数量是:N (1-(1- L ) n )。

其中: N 是设计中可用性问题的总数,L 是测试单个用户时发现的可用性问题的比例。 L 的典型值为 31%,在我们研究的大量项目中取平均值。

绘制 L = 31% 的曲线得出以下结果:

曲线中,最引人注目的事实是:零用户给出的洞察数为零。

只要你从一个测试用户那里收集数据,洞察数就会出现,你已经学会了近三分之一的知识来了解设计的可用性——零和即便是一点点数据之间的差异是惊人的。

当你测试第二个用户时,你会发现这个人和第一个用户做了一些相同的事情,所以你掌握的东西有一些重叠,人们是完全不同的。所以从第二个用户那,也会有一些第一个用户那没有的新的东西出现,所以从第二个用户那也会增加一些新的洞察力,但不像第一个用户那么多。

第三个用户会做很多事情,这些事你已经从观察过的第一个用户或第二个用户那观察过了,甚至有些事情你已经看过两次了。此外,第三位用户当然也将产生少量新数据,这些数据仅是第三位用户产生的。

来自《做可用性测试时,只需要5名用户参与测试就够了》。

如果你想了解有关卡片分类测试以及定量研究测试的测试用户数量,推荐阅读以下两篇文章:

卡片分类法解析:究竟要测试多少用户?

定量研究:需要测试多少用户?

案例

整个系列中的最后一部分是案例,开始的时候我提及了 WhatsApp 的案例,后面我又补充了一些其他的案例,以加深对快速可用性测试的了解和运用。

案例主要有:

WhatsApp Web 端应用可用性测试

Guerilla 可用性测试案例之一:Airbnb 愿望清单功能

Guerilla 可用性测试案例之二:Dropbox 照片功能

快速可用性测试案例之三:Apple iCloud 照片共享功能》(自测并实施)

《快速可用性测试案例之四:Yelp 提升 Web 体验》

未经允许不得转载,或转载时需注明出处:西部数码新闻资讯门户 » 作为产品经理,我推荐你了解快速可用性测试
分享到:更多 ()

网友评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

中国领先的互联网域名及云服务提供商

为您提供域名,比特币,P2P,大数据,云计算,虚拟主机,域名交易最新资讯报道

域名注册云服务器