用户体验测试

测试方案
6.>目标用户 目标用户数量 目标用户怎么找（特征） 7.>测试任务 测试任务（引导者手册） 标准问卷 8.>测试任务评价标准 观察者提纲 9.>测试用户允许的辅助手段 手册 上网查找 引导者可以在什么状态下给何种程度的提示
BACK<<
谁适合引导
• • • • • • 耐心 冷静 有同情心 善于倾听 天性公正的人 其实绝大多数人都可以
BACK<<
可用性专家们总结的几个事实
• 如果想做一个好的游戏，一定要用户测试！ • 测试“一个”用户会比不做测试好一倍 • 在项目中，早点测试一个用户好过最后测 试50个用户 • 测试的关键不是证明什么反驳什么 • 测试是一个迭代的过程
BACK<<
测试方案
• 1.>测试目的 具体的测试目的 • 2.>测试什么时间什么地点举行 • 3.>测试预期使用多少时间 • 4.>测试用设备；设备状态 需要哪些设备 计算机要达到什么要求 （性能要求，环境要求，软件要求＝＝） • 5.>测试工作人员 召集人 引导者 观察者
用户测试的伦理性方面的考虑
测试过程中： • 让用户尽早体验到成功 • 一次给用户一个测试任务 • 在测试房间那保持轻松的气氛 • 避免被干扰 • 不要以任何方式表现出对用户不耐烦 • 不允许用户的上司来观看测试 • 如果测试令人不愉快，请停止测试
用户测试的伦理性方面的考虑
测试之后： • 向用户说明是他们帮助发现改进的地方 • 千万不能以可以区分出具体用户的方式来 报告测试结果 • 只有在用户同意的情况下，才能在可用性 小组之外公开录像带
BACK<<
传统的可用性测试
• 可用性测试的目的 • 可用性测试的对象 • 可用性的要素
可用性测试目的
• 形成性评估
– 目的是为了改进设计。 – 公司产品改进
• 总结性评估
– 目的在于评定整体质量。 – 竞争性分析、代理评估
BACK<<
可用性测试对象
• 可用性测试的对象是界面 • 对于游戏是整个客户端表现
游戏可用性评估纬度以及标准
http://www.usabilityfirst.com/
蒋维 POPO：jw_china@163.com E-mail：jiangwei@corp.netease.com
BACK<<
错误
• • • • 包括程序的bug和游戏设计的缺陷 低的错误率 错误的应急处理 人性化的错误恢复指引
BACK<<
主观满意度
• 最终的可用性属性 • 对于游戏特别重要的属性 • 原理上：问卷方式－>SUMI…
BACK<<
游戏和应用软件的异同
• 相同点
– – – – 归根结底都是软件 上手都需要一个过程 一般都提供帮助 …
• 不同点
– 游戏首先是好玩，而应用软件是功能 – 游戏鼓励一定的挑战性，而应用软件希望完全没有挑 战性 – 游戏鼓励创新，应用软件鼓励传承和兼容 –…
游戏中的可用性测试
• 游戏界面的可用性测试 • 游戏流程的可用性测试 • 帮助测试确定玩家是否按照策划的预期去 玩 • 了解玩家的想法定位问题
可用性测试方法及其评估
• 常见测试方法介绍 • 可靠性和有效性 • 可用性评价标准
BACK<<
两个主要的可用性方法
• 绩效度量法 完成预先规定的测试任务 收集数据进行分析 评价：统计上的尺度和预先设定的对比 • 边做边说法 用户使用系统的同时大声的说出他们的想法 听取用户的描述 观察他们的行为 评价：确定用户对设定的误解。 误解。 误解
其他的可用性测试方法
• • • • 经验性评估法 观察法 记录回顾法 引导法
BACK<<
可靠性和有效性
• 可靠性 用户个体的巨大的差异 解决方法：统计学上消除 • 有效性 测试方法是否真正有效
BACK<<
休息休息…
开始一次可用性测试
• • • • • • • • 可用性专家们总结的几个事实 测试方案 谁适合引导 用户测试的伦理性方面的考虑 来试试吧 一些可用性测试的技巧 观察者的构成 测试结果的处理
你下一步想干什么 你预期这样干的结果是什么 为什么xx没有引起你的注意...
• 尽量让用户在选择任务的时候说点什么 • 什么时候打断用户
用户完成一个任务 用户绝望了 用户勉强应付，Байду номын сангаас不知所云
BACK<<
观察者的构成
观察者不是越多越好也不是越少越好：
70％
?
观察者的构成
• 产品经理： 很显然，他们的到场（哪怕10分钟）会 给整个工程提升受重视程度，显示高层的 重视，提高大家的积极性。 • 策划： 需要策划参与，特别是直接设计的策划 话题：策划是否该和玩家直接沟通？
观察者的构成
• 美术，程序等相关方： 如果他们愿意来参加也是很好的，毕竟可用性 方面很多实现也是在他们“主观能动”之下有较 多的影响力。 • QC，用户体验工程师： 毋庸质疑QC发现问题的能力。保证枯燥测试 进行中有几个忠实可靠的记录员。 • 独立评审员 非本项目组的独立评审员，可以从全新的角度 来看问题，最好有一定的可用性经验。
我们可以挽救吗？
• 1.总是先考虑优化 • 2.关注细节（对于分析，必须是清晰的，详 细的，到点的） • 3.优化后，必须校验 • 4.如果问题很深入，咬紧牙关挺过去 • 5.永远不会太晚去怀疑前提假设
BACK<<
尝试一下
• 基于现在研究的游戏，对游戏的新手阶段 进行一次可用性测试。发现新手阶段存在 的可用性问题，获得用户关于新手阶段的 主观满意度。样本量控制在3～6人，需要 提交测试方案，测试任务，问卷设计，总 结报告。 • 要求
BACK<<
来试试吧
• 需要
– 一个引导者 – 一个用户－没有用过Foxmail的 – 其他人都是观察者
• 测试任务
– 使用Foxmail，建立一个叫做“周报”的新邮箱 – 设置过滤器，过滤所有收到的标题中含有“周 报”的邮件放到周报文件夹。192.168.23.155
一些可用性测试的技巧
几个经典的提问
两种方法的对比
测试 适用测 方法 试阶段 绩效 竞争性 度量 分析 法 总结性 评估 边说 反复设 边做 计 法 形成性 评估 需要测 试多少 人 >10人 优点 缺点
硬性的数据指 标 结果容易对比 便宜 准确了解用户 的想法 偶尔会有惊喜 发现
昂贵 不能发现单个可用性问题
2－5人
用户感决不自然 越熟练用户越不能表达清楚 用户过多意见干扰对用户的表 达意愿和表达能力十分依赖
BACK<<
可用性测试的五大要素
• • • • • 可学习性 效率 可记忆性 错误 主观满意度
BACK<<
可学习性
• 自解释能力 • 指引帮助的设计效果 • 遵守习惯设定的情况
效率
• 用户操作的高效，不是系统资源占用
BACK<<
可学习性和效率的侧重
BACK<<
可记忆性
• 系统应该容易记忆 • 那些不是频繁使用的用户可以不用重头学 习
BACK<<
用户测试的伦理性方面的考虑
为什么要考虑： • 拿人来测试的敏感性 • 短期看尊重用户保持测试气氛良好有利于 测试效果 • 尊重用户有利我们建立用户库
用户测试的伦理性方面的考虑
测试之前： • 在用户来到前准备好所有的 • 强调测试的对象是系统而不是用户 • 告知用户系统是新的，可能存在问题 • 让用户知道他们可以随时停止测试 • 解释所有使用的录音录像设备等监控设施 • 告诉用户测试结束数据将会保密 • 在开始之前回答用户提出的所有问题 • 鼓励用户放开表现，告诉他我们不怕批评
– 二人组队 – 一周内完成
参考资料
chapter1、2、4、6、8， 2004，Jakob Nielsen, Usability 、 、 、 、 ， ， Enginnerring chapter9、10，July-2005, Steve Krug， Don‘t Make Me 、 ， ， ‘ Think 2nd
BACK<<
多少样本量合适
• 经验性标准
– 定性分析 2～5人 – 定量分析，同质化用户>6人
• 科学的可置信分析
– James R. Lewis Sample Sizes for UsabilityTests
测试任务
• • • • 测试任务代表最终使用的状况 覆盖最重要的部分 可以来自预测试和QC等的建议 可以来自数值分析
测试任务设计技巧
• • • • 测试任务应该大小适中 详细描述测试任务达成的结果 测试任务不应该轻佻 测试任务前后的难度应该逐步增加
测试结果的处理1
• 立即回顾测试结果 每轮测试后，你应该尽快让开发团队回 顾每个人的观察，决定接下来该如何处理。 第一：给问题分类――回顾大家看到的 问题，决定那些问题需要修正。 第二：解决问题――找到这些问题的方 法。
用户体验测试（上）
可用性工程 用户体验测试的研究方法
你遇到过哪些可用性问题？
讲座脉络
• • • • • 什么是可用性 传统的可用性测试 游戏中可用性测试的应用 可用性测试方法论 一次完整的可用性测试
可用性可玩性定位
Hard
可用性名言
• • • • • • • • 不能凭想象和猜测 用户总是对的 用户不总是对的 用户不是设计人员 设计人员不是用户 少就是多 帮助并不能帮助 可用性工程是一个过程
测试结果的处理2
• 提交一份必要的报告，归档 • 跟进发现的问题是否被真正修正，是否被 放入改进计划表 • 修正之后的结果进行迭代，新设计有没有 有效修正这个问题，有没有引入新的问题
几个需要注意的原则
• • • • • 忽略“Kayak”问题 抵制添加的冲动 不要太看重人们对新功能的要求 别把孩子也泼出去 千万不要相信只要怎么样就可以不会存在 这个问题的神话，我们只相信用户反馈