如何做可用性测试,建立有效的设计验证

今天小编给大家带来的文章是如何做可用性测试,本篇文章作者将从搬运和自己总结这两个部分来阐述如何使用可用性测试,以此来验证自己的设计方案,并为大家建立有效的验证设计提供帮助,一起来看看吧!

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

WHAT: 可用性测试定义

如何做可用性测试,建立有效的设计验证

国际标准ISO 9241-11将可用性定义为“特定的用户在特定的使用情景下,有效、有效率、满意的使用产品达到特定的目标”【ISO9241-11. Ergonomic requirements for office work with visual display terminals (VDT's) – Part 11: Guidance on usability[S]. International Standards Organization,1998.】。

ISO 9241-11将可用性概括为三方面:有效性(effectiveness),用户使用系统完成各种任务所达到的精度(accuracy)和完整性(completeness);效率(efficiency),用户按照精度和完整度完成任务所耗费的资源,资源包括智力、体力、时间、材料或经济资源;满意度(satisfaction),用户使用该系统的主观反应,描述了使用产品的舒适度和认可程度。每次测试之后程序设计师都能够对软件加以改进。

如何做可用性测试,建立有效的设计验证

WHEN: 可用性测试什么时候用

适用于产品的不同周期:

如何做可用性测试,建立有效的设计验证

WHY: 可用性测试解决了什么问题?

通过对有效性、效率、满意度来查看用户的反应,主要是为了寻找用户痛点,产品缺点,继续改进!不是让你白测试的!!

是让你画个表),记下来到底还需要改进哪些痛点,排个优先级,快速迭代改改改!才能让你的产品更牛逼!

每次测试之后程序设计师都能够对软件加以改进。

个人总结:为了验证当前的设计方案,

(1)记录下用户反馈的修改的那些痛点

(2)然后将问题进行优先级排序,给予解决方案的建议。

  • 产品体验上是否存在问题?
  • 期望的设计目的是否能达成?是否满足了用户的期望?
  • 了解用户的行为习惯,了解用户的认知,找到某些问题的原因?
  • 用户是否会满意?

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

WHAT: 用什么做可用性测试?

纸面原型、原型图、高保真原型图设计稿、竞争对手产品,都可以(只要有流畅路径即可)

如何做可用性测试,建立有效的设计验证

那体验五要素里,适用范围是哪几个:

后三层,表现层、框架层、结构层。

如何做可用性测试,建立有效的设计验证

几个人?

2种:

(1)形成式:小样本5-7人,发现问题为主,不能做定量对比

(2)总结式:大样本,30人以上,定量的评估,可以做对比评估

但是对于我们快速迭代的互联网中,节奏快。

所以,互联网公司经常使用的是第一种,形成式,小样本,以发现问题为主的可用性测试。

第一种的特点是:快速、简易、紧密

说明:根据尼尔森的研究,5个可用性测试参与者就可以发现80%以上的问题

如何做可用性测试,建立有效的设计验证

可用性测试具体实施:

老习惯,本人是个讲究多元化方法论的人,我觉得纸上得来终觉浅,绝知此事要躬行

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

如何做可用性测试,建立有效的设计验证

总结:可用性测试就是为了验证当前的设计方案。

我做可用性测试,主要就是自己先去列一些测试目标,比如用户在操作流程会不会有一些卡顿,目前的交互是不是和用户理解的有出入,等等。在可用性测试中,一次一个用户,去观察用户试用一些东西(不管是原型,还是一些关于新设计方案的草图),去完成一些典型的任务,通过观察用户的行为,你可以检测到那些让用户混淆和倍感挫折的地方,并修复。

以下是我在做每个步骤时候的重点:

(1)用户招募筛选很重要:

测试人员筛选也很重要,直接影响结果,忠实用户有时候没用,数据会有问题,声音比较大的老用户可以用。

用那些新用户(吐槽比较大的…)他们的吐槽或许比较有价值!老用户会有一些惯性思维和习惯 反而有时候不可取!比较满意的老客户没多大用。

1-3月的新用户最好,太久了反而不好。

可以想象一下 6个月前你买咖啡的场景你还记得吗?反之1个礼拜内买咖啡的人,反馈的问题更真实。

所以最近一段时间购买的人,反馈的问题就是可信的。

这个时间可以这样写,注册半年左右且最近几个月频繁购买的用户

(2)整理表格的满意度这里:

非常高兴 高兴 不高兴 非常讨厌 大概四种表情去表示一下。

用户更多是情绪的表现比较直接 用户非专业人士 不会说:这个可见性 /易读性… 他们只会高兴 不高兴 。

(3)用户数据从哪里来:

一般都是运营部门的人去找IT部门负责人去要这个数据

(4)关于是否用用户的手机:

初步发布,没有正式发布(并且通过内部测试的产品!灰度上线的产品 )可以用客户自己的手机 这个情况是产品并不是那种保密产品。

若是保密产品,只能用公司测试机。

(5)预测试很重要:

移动可用性测试受到设备、环境、任务等多因素影响,进行预测试可帮助我们发现测试计划,及前期准备中可能存在的问题,从而保证正式测试的顺利进行。

自己人先走查一遍流程是否能跑的通,免得浪费不必要的时间,并且修好发现的问题。

(6)不要提示用户,用户测试任务的时候,不可以提示。

除非是这个功模块弄完了 提示去做另外一个不一样的模块

(7)然后将问题进行优先级排序,给予解决方案的建议。

那个问题转换成设计 (一个按钮 一个banner 或者一个布局排版的改变…)就是测试的价值点了。

这个是问题优先级是最后开发整改的时候一起协商排出来的。

本文由 新媒体之家 作者: 应谋鬼计 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论