用户体验测试ppt课件

《用户体验测试ppt课件》由会员分享，可在线阅读，更多相关《用户体验测试ppt课件（46页珍藏版）》请在金锄头文库上搜索。

1、 用户体验测试 上 可用性工程用户体验测试的研究方法 你遇到过哪些可用性问题 讲座脉络 什么是可用性传统的可用性测试游戏中可用性测试的应用可用性测试方法论一次完整的可用性测试 可用性可玩性定位 Hard 可用性名言 不能凭想象和猜测用户总是对的用户不总是对的用户不是设计人员设计人员不是用户少就是多帮助并不能帮助可用性工程是一个过程 BACK 传统的可用性测试 可用性测试的目的可用性测试的对象可用性的要素 可用性测试目的 形成性评估目的是为了改进设计 公司产品改进总结性评估目的在于评定整体质量 竞争性分析 代理评估 BACK 可用性测试对象 可用性测试的对象是界面对于游戏是整个客户端表现 BAC

2、K 可用性测试的五大要素 可学习性效率可记忆性错误主观满意度 BACK 可学习性 自解释能力指引帮助的设计效果遵守习惯设定的情况 效率 用户操作的高效 不是系统资源占用 BACK 可学习性和效率的侧重 BACK 可记忆性 系统应该容易记忆那些不是频繁使用的用户可以不用重头学习 BACK 错误 包括程序的bug和游戏设计的缺陷低的错误率错误的应急处理人性化的错误恢复指引 BACK 主观满意度 最终的可用性属性对于游戏特别重要的属性原理上 问卷方式 SUMI BACK 游戏和应用软件的异同 相同点归根结底都是软件上手都需要一个过程一般都提供帮助 不同点游戏首先是好玩 而应用软件是功能游戏鼓励一定的

3、挑战性 而应用软件希望完全没有挑战性游戏鼓励创新 应用软件鼓励传承和兼容 游戏中的可用性测试 游戏界面的可用性测试游戏流程的可用性测试帮助测试确定玩家是否按照策划的预期去玩了解玩家的想法定位问题 可用性测试方法及其评估 常见测试方法介绍可靠性和有效性可用性评价标准 BACK 两个主要的可用性方法 绩效度量法完成预先规定的测试任务收集数据进行分析评价 统计上的尺度和预先设定的对比边做边说法用户使用系统的同时大声的说出他们的想法听取用户的描述观察他们的行为评价 确定用户对设定的误解 两种方法的对比 其他的可用性测试方法 经验性评估法观察法记录回顾法引导法 BACK 可靠性和有效性 可靠性用户个体的

4、巨大的差异解决方法 统计学上消除有效性测试方法是否真正有效 BACK 休息休息 开始一次可用性测试 可用性专家们总结的几个事实测试方案谁适合引导用户测试的伦理性方面的考虑来试试吧一些可用性测试的技巧观察者的构成测试结果的处理 BACK 可用性专家们总结的几个事实 如果想做一个好的游戏 一定要用户测试 测试 一个 用户会比不做测试好一倍在项目中 早点测试一个用户好过最后测试50个用户测试的关键不是证明什么反驳什么测试是一个迭代的过程 BACK 测试方案 1 测试目的具体的测试目的2 测试什么时间什么地点举行3 测试预期使用多少时间4 测试用设备 设备状态需要哪些设备计算机要达到什么要求 性能要求

5、 环境要求 软件要求 5 测试工作人员召集人引导者观察者 测试方案 6 目标用户目标用户数量目标用户怎么找 特征 7 测试任务测试任务 引导者手册 标准问卷8 测试任务评价标准观察者提纲9 测试用户允许的辅助手段手册上网查找引导者可以在什么状态下给何种程度的提示 BACK 谁适合引导 耐心冷静有同情心善于倾听天性公正的人其实绝大多数人都可以 BACK 用户测试的伦理性方面的考虑 为什么要考虑 拿人来测试的敏感性短期看尊重用户保持测试气氛良好有利于测试效果尊重用户有利我们建立用户库 用户测试的伦理性方面的考虑 测试之前 在用户来到前准备好所有的强调测试的对象是系统而不是用户告知用户系统是新的 可

6、能存在问题让用户知道他们可以随时停止测试解释所有使用的录音录像设备等监控设施告诉用户测试结束数据将会保密在开始之前回答用户提出的所有问题鼓励用户放开表现 告诉他我们不怕批评 用户测试的伦理性方面的考虑 测试过程中 让用户尽早体验到成功一次给用户一个测试任务在测试房间那保持轻松的气氛避免被干扰不要以任何方式表现出对用户不耐烦不允许用户的上司来观看测试如果测试令人不愉快 请停止测试 用户测试的伦理性方面的考虑 测试之后 向用户说明是他们帮助发现改进的地方千万不能以可以区分出具体用户的方式来报告测试结果只有在用户同意的情况下 才能在可用性小组之外公开录像带 BACK 来试试吧 需要一个引导者一个用户

7、 没有用过Foxmail的其他人都是观察者测试任务使用Foxmail 建立一个叫做 周报 的新邮箱设置过滤器 过滤所有收到的标题中含有 周报 的邮件放到周报文件夹 192 168 23 155 一些可用性测试的技巧 几个经典的提问你下一步想干什么你预期这样干的结果是什么为什么xx没有引起你的注意 尽量让用户在选择任务的时候说点什么什么时候打断用户用户完成一个任务用户绝望了用户勉强应付 却不知所云 BACK 观察者的构成 观察者不是越多越好也不是越少越好 观察者的构成 产品经理 很显然 他们的到场 哪怕10分钟 会给整个工程提升受重视程度 显示高层的重视 提高大家的积极性 策划 需要策划参与 特

8、别是直接设计的策划话题 策划是否该和玩家直接沟通 观察者的构成 美术 程序等相关方 如果他们愿意来参加也是很好的 毕竟可用性方面很多实现也是在他们 主观能动 之下有较多的影响力 QC 用户体验工程师 毋庸质疑QC发现问题的能力 保证枯燥测试进行中有几个忠实可靠的记录员 独立评审员非本项目组的独立评审员 可以从全新的角度来看问题 最好有一定的可用性经验 BACK 多少样本量合适 经验性标准定性分析2 5人定量分析 同质化用户 6人科学的可置信分析JamesR LewisSampleSizesforUsabilityTests 测试任务 测试任务代表最终使用的状况覆盖最重要的部分可以来自预测试和Q

9、C等的建议可以来自数值分析 测试任务设计技巧 测试任务应该大小适中详细描述测试任务达成的结果测试任务不应该轻佻测试任务前后的难度应该逐步增加 测试结果的处理1 立即回顾测试结果每轮测试后 你应该尽快让开发团队回顾每个人的观察 决定接下来该如何处理 第一 给问题分类 回顾大家看到的问题 决定那些问题需要修正 第二 解决问题 找到这些问题的方法 测试结果的处理2 提交一份必要的报告 归档跟进发现的问题是否被真正修正 是否被放入改进计划表修正之后的结果进行迭代 新设计有没有有效修正这个问题 有没有引入新的问题 几个需要注意的原则 忽略 Kayak 问题抵制添加的冲动不要太看重人们对新功能的要求别把孩

10、子也泼出去千万不要相信只要怎么样就可以不会存在这个问题的神话 我们只相信用户反馈 我们可以挽救吗 1 总是先考虑优化2 关注细节 对于分析 必须是清晰的 详细的 到点的 3 优化后 必须校验4 如果问题很深入 咬紧牙关挺过去5 永远不会太晚去怀疑前提假设 BACK 尝试一下 基于现在研究的游戏 对游戏的新手阶段进行一次可用性测试 发现新手阶段存在的可用性问题 获得用户关于新手阶段的主观满意度 样本量控制在3 6人 需要提交测试方案 测试任务 问卷设计 总结报告 要求二人组队一周内完成 参考资料 蒋维POPO jw china E mail jiangwei chapter1 2 4 6 8 2004 JakobNielsen UsabilityEnginnerringchapter9 10 July 2005 SteveKrug Don tMakeMeThink2nd游戏可用性评估纬度以及标准