用户体验测试
用户体验测试
什么是可用性测试,
可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一
旁观察，聆听，做记录。
该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。
测试
可以是早期的纸上原型测试，也可以是后期成品的测试。
你能从可用性测试获得什么,
在每一轮的可用性测试中，你都应该先明确具体的测试问题和目标，针对这些目标进行测试。
举
例来说，项目刚刚起步，你可以对定量的指标(如时间，错误率和满意度)进行测试，为日后修改网
站提供参照。
再例如，如果你已经设定了可测量的可用性目标，你可以看看你的产品是否切合这些目
标。
对于一个典型的可用性测试，你可以:
找出该产品的任何的可用性问题
从测试参与者的表现收集定量数据
确定该产品的用户满意度
可用性测试和以用户为中心的设计的关系,
可用性测试是以用户为中心的设计的一个重要组成部分。
用户为本的设计过程本身就应该包括对
性能和偏好进行评价的一系列测试。
什么时候该做可用性测试,
尽早做，经常做。
可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。
问题越
早发现和弥补，所造成的损失就越低。
这些问题是找到并固定好，越昂贵的补丁程序。
随着项目的进
展，对设计主体进行改动会变得越来越困难和昂贵。
你测试的越多，并就相应测试进行改进，你就可
以更加确信你的网站没有偏轨，确信它是符合您的目标和用户的需要的。
迭代开发过程——开发原型，测试用户，分析结果，随之修改原型，然后再重复测试、分析、修
改周期——是开发一个成功的网站或软件的最好方式。
通过可用性测试你能学到什么,
通过一个典型的可用性测试，你可能找到这些问题的答案:
测试参与者能成功完成任务吗,
在成功完成的任务中，每项任务能做的多快,
在成功完成的任务中，每项任务要多少页(或者点击多少次)才能完成,
测试参与者的表现是否满足可用性目标,
测试参与者对网站的满意度如何,
做出什么改变才能确保更多用户能够完成地更顺利,
可能还有更具体的问题。
举例来说，如果这一轮测试主要关注的是搜索功能，你可能会关注这些
问题:
测试参与者会在页面上浏览还是直接使用搜索,
他们搜索时最常用的关键字是什么,
搜索框是否足够大，能呈现大部分的搜索关键字,它的位置是否合理,
搜索结果是否能引导用户的快速找到答案,
如果搜索结果恰好包含用户想要的答案，这些答案是否经常显示在第一页, 搜索是否能检测到拼写错误并帮助纠正,
可用性测试中你该注意什么,
必须牢记以下四点:
1. 你测试的是产品，而不是使用者。
2. 更多地依靠用户的表现，而不是他们的偏好。
3. 把你掌握的测试结果应用起来。
4. 基于真实的用户体验，找出问题的最佳解决方法。
1. 你测试的是产品，而不是使用者。
对一些用户而言， ;测试;有负面的涵义。
我们要努力确保他们不认为测试是针对他们。
我们要
让他们明白，他们正在帮助我们测试原型或网站。
事实上，我们可以不使用“测试”这个术语。
相反，
我们是邀请参加者为我们提供帮助， ;勇于尝试原型; 。
当用户难以完成任务时，我们应该改变网站，而不是改变用户。
同时我们还应该思考该网站能在
多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。
2. 更多地依靠用户的表现，而不是他们的偏好。
通过测试我们可以测量到用户的表现，以及他们的偏好。
用户的表现包括是否成功完成，所用时
间，产生的错误等等。
偏好包括用户自我报告的满意度和舒适度。
一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。
但
证据并不支持这一点。
事实上，用户的表现以及他们对产品的偏好并非一一对应。
一项研究发现，约
有百分之七十的用户同意表现和喜好有联系。
也就是说，他们在喜爱的网站上表现良好，在不喜欢的
网站上表现欠佳。
然而，还有相对比较大比例的人( 30 , )认为，用户的表现以及他们对产品的偏好并非一一
对应。
他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。
关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。
他们可能会把表现不佳归
结到自己，而不是网站。
或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的
感情。
或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。
基于
所有这些理由，我们建议你:更多地依靠用户的表现，而不是他们的偏好。
3. 把你掌握的测试结果应用起来。
可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的
时候，可用性测试还没有结束。
整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原
型进行修改。
4. 基于真实的用户体验，找出问题的最佳解决方法。
制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及
需要。
大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。
平衡各个方面
对大部分项目来说都是一个重大的挑战。
在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。
有研究表明，产品推
出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。
你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想
解决方法。
找不到最好的解决方法，用户就不能够顺畅地完成任务。
有证据表明，即使用户延长使用
时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。
你是否需要一个实验室做可用性测试,
用不着，无论使用正式的或非正式的设备你都可以做可用性测试。
使用任何类型的设备，你都可
以采用各种正式或非正式的方法。
使用下述任何一种设置，你都可以进行有效的可用性测试:
两室或三室的固定实验室，配备视听设备
会议室，用户的家或工作室，配备便携式录音设备
会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替
当用户在不同地点可以远程控制
因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。
不要说，“因为我
们没有一个可用性实验室，所以我们没法做可用性测试。
; 只要去做～在任何空间你都可以完成。
可用性测试需要多少人参与,
看情况。
一个典型的测试需要 8至 16 个人(每用户组)。
如果每个用户将花费一小时，就意味
着每个用户组的测试需要一到两个工作日。
当你的项目处在:
纸上原型或早期开发阶段
计划通过几轮测试整个开发
有相当一致的用户群
如果只要人帮忙找出严重问题，你可能只需要 4到 6 人。
如果您有不同的潜在用户群组(例如医生、病人、研究人员)，你需要所有这些群体的用户代表。
如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。
如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结
果。
对于诊断型的可用性测试，6至 8个用户通常是不足以揭露产品的大部分问题的。
如果在网站开发过程中你一直在做迭代(重复)的可用性测试，就会有许多用户参加其中一个或
另一个版本的网站测试。
因此，尽管每个可用性测试只有少于 10 名的测试参予者，但在网站推出前
你可能需要 15 到 30 人参加测试。
做可用性测试需要多少费用,
成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。
如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。
如果你
或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。
在对可用性测试进行预算时应该考虑这些因素:
计划所用的时间:确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试
场景。
招聘的花费:公司人员的时间，给招聘公司(通常是一个很好的选择)的花费，可用性专家需要
花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室
或便携式摄录设备的租金。
团队观察用户(进行测试)花费的时间
付给测试参与者的报酬或礼物
分析视听资料，查找存在的问题以及推荐解决办法所用的时间
和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。
记住，预算分析要包含多个可用性测试。
打造一个网站(或产品)的可用性是一个反复迭代的过
程。
你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。
现在，你知道可用性测试是怎么一回事了吧,
看了这些似乎明白了写什么.希望在以后工作中可以应用到.。