1
启发式评估 Abstract - 是专家评估法的一种，也有被称作为经验性评估。简单来说，启发式评估是一种简易的可用性评估方法，使用一套相对简单、通用、有启发性的可用性原则，让几个评审人员根据专业知识和经验来进行评估，发现产品潜在的可用性问题
应用场景 - #1时间资源有限的情况下，快速发现可用性问题，降低风险及成本；#2版本变动不大的情况下，小成本检验；#3作为可用性测试的之前的准备
『产品马上就要进入开发/上线了，能否快速评估下有没有问题？』
评估者 + 评估原则 = 启发式评估
评估者 = 3-5人，有时也会简化 + 设计师、用户研究院 + 最好非设计者本人 + 同时具有可用性只是及设计知识更佳
评估原则 - 主要是提供一个框架，用以参考，但不要拘泥于这个框架
常用评估原则
优点 - 成本低，效率高，发现大多数可用性问题
缺点 - 不能代表真实的用户相对主观，发现问题过多，对评估人员综合素质要求比较高
流程
第一步 评估准备
评估准备-详解
例子
第二步 评估执行阶段
执行阶段-详情
第三步 结果分析
汇总讨论 - 报告总结 - 优化方案
报告距离
Nielson 经典10原则
#1 系统状态可见性 - 系统应该在适当的时间内做出适当的反馈，告知用户当前的系统状态
#2 系统与用户现实世界的匹配 - 设计应与现实生活中对相关产品的认知、经验、习惯等相符，以用户期望的方式表现出来，使用户可以利用已有的注视经验来执行操作任务
#3 用户控制和自由 - 用户经常在使用功能的时候发生误操作，这时需要一个明确的「紧急入口」来帮助他们从当时情境中回复过来。需要支持取消和重做
#4 一致性与标准化 - 同一产品内，产品架构导航、功能名称内容，信息的视觉呈现、操作行为交互方式等方面保持一致；使界面看上去熟悉且易于理解，使用户可以利用已有知识来执行新的操作结果，产品与通用的业界标准一致
#5 错误预防 - 在用户选择动作发生之前，就要防止用户容易混淆或者错误的选择
#6 让用户再认而非回忆 - 尽量减少用户需要记忆的事情和行动，提供可选项让用户再认信息
#7 具备灵活性且高效 - 为用户提供捷径。好的软件不但考虑到新用户的需求，也要考虑到熟练用户的需求，不但应对新用户简单易学，还要对熟练用户来说快捷、高效、尤其是可以很方便地使用频率较高的功能
#8 美观而简洁的设计 - 对话中不应该包含无关紧要的信息，设计需要简洁明了，不要包含不相关的或者不需要的内容，每个多余的信息都会分散用户对有用或者相关信息的注意力
#9 帮助用户认识、判断和修复错误 - 用简单明确的语言解释错误信息，精确的指出问题的原因并提出建设性的解决方案
#10 帮助和使用手册 - 提供帮助信息，帮助信息应当易于查找，聚焦于用户的使用任务，列出使用步骤，并且信息量不能过大
#1 系统状态可见性 延伸&栗子
#1 栗子
#1栗子
#1栗子
#1栗子
#1栗子
#1栗子
相关可用性问题
# 缺少必要的反馈，没有清晰的系统状态
#反馈不够持久，用户没有足够的时间注意到或理解
#反馈没有立即显示
#反馈不容易看到，或者不容易理解
#提供了不必要的反馈，使用户慢下来
#让用户误解的反馈
#2 系统与用户现实世界的匹配 延伸&栗子
#2栗子
#2栗子
#2栗子
#2栗子
相关可用性问题
# 使用了用户不熟悉的语言
# 系统的语言是以系统为中心，而不是用户为中心
# 任务流程和用户真实使用的流程不一致
# 系统结构不符合用户对真实世界的理解
# 系统使用的暗喻或比拟方法不容易理解
#3 用户控制和自由 延伸&栗子
#3栗子
#3栗子
#3栗子
相关可用性问题
# 在不可逆转的行动之前没有提供足够警告
# 没有在适当的时机提供取消的功能
# 取消功能呢不明显/很难找到
# 不支持撤销的功能
#4 一致性与标准化 延伸&栗子
#4栗子
#4栗子
相关可用性问题
# 界面元素外观、布局和分组不一致
# 界面元素的命名不一致
# 系统反馈信息的格式不一致
# 系统提供不一样的方法来操作相似的对象
# 表达含义不一致，例如在不同的地方红色代表不同的意义
# 设计标准和通用标准不一致
#5 防止错误 延伸&栗子
#5栗子
#5栗子
#5栗子
相关可用性问题
# 输入信息时，没有告诉用户的格式
# 缺少非语言暗示
# 界面上不同的物体太相似
# 没有对可能产生严重后果的操作，进行提示和确认
#6 再认而不是回忆 延伸&栗子
#6栗子
#6栗子
#6栗子
#6栗子
相关可用性问题
# 系统的使用过于复杂，用户不得不记忆复杂的命令
# 界面提供的信息不及时，用户不得不自己从系统的另一个部分找到相关的信息
# 图像或者符号难以理解，甚至误导用户
# 菜单，选择或者链接有太多的层次
#7 灵活高效的使用 延伸&栗子
#7栗子
#7栗子
相关可用性问题
# 系统缺少自动化，没有自动地执行下面的任务
# 系统没有提供应有的默认值
# 默认值不正确
# 使用系统需要太多的控制动作
# 系统没有提供捷径
#8 简洁而美观的设计 延伸&栗子
#8栗子
#8栗子
相关可用性问题
# 用户界面上的元素太大或太小
# 元素的颜色、形状或文字不适当、不容易识别
# 界面元素的移动太快，太慢，或不容易察觉
# 界面过于拥挤，界面元素密度分布不均匀
# 不同的元素太相似，按键或者链接看上去像一般的文字
#9 帮助用户认知、判断和修复错误 延伸&栗子
#9
#9
#9
相关可用性问题
# 用用户不容易理解的语言进行提示。如404错误
# 没有给出有效的建议
# 错误信息使用户感到迷惑
# 错误信息用词不当
#10 帮助文档和使用手册 延伸&栗子
#10
#10
#10
相关可用性问题
# 帮助信息&用户手册 不存在
# 帮助信息没有意义，或者使用户更加迷茫
2
可用性测试 - 通过观察有代表性的用户，完成产品的典型任务，从而找出可用性问题，并解决这些问题，目的是让产品用起来更容易。
产品测试闭环
可用性测试 在产品设计；产品测试&优化；产品发布；三个阶段都可以进行，而且越早进行越好
分为两种类型 ：形成式 - 小样本；发现问题为主；不能做定量对比；总结式 - 大样本，30人以上；定量的评估；可以做对比评估
可用性测试解决什么问题？
特点
可用性测试流程
流程总览
一般来说会进行很多轮，测试和优化是个不断迭代演进的过程
#1 准备阶段 - 输出物：测试方案，测试脚本
确定目标；测试方案；测试脚本；招募用户；材料工具；测试场地；预测试
测试方案
测试脚本
#1 锁定在主要的任务上；#2 从用户角度出发；#3 明确起点和终点（到达某个页面）；#4 场景化
招募用户
招募用户
材料准备
测试清单
预测试
#2 正式测试阶段- 输出物：测试记录，录像录音
测试参与人员
主持人测试前
主持人测试中
Tips：不正面回答用户设计上的问题，尝试反问，你对这样设计的思考是？
要点：用户是否独立完成任务；是否存在无效的操作或者不知所措；用户是否不满；
主持测试中
主持人测试后
记录员做什么
测试访谈记录
#3 结果分析阶段- 输出物：测试报告
结果分析：越及时越好，边测边总结
# 测试完一个用户，做一次小结；
# 测试结束当天写小结，与设计师当场讨论；
# 重要问题反馈后，再总结分析报告；
# 边测边改，边改边测。
借助贴纸进行整理分析
借助Excel整理，有利于存档
结果分析的核心步骤
评定优先级参考标准
撰写报告：总体如何-有哪些问题-严重程度如何-建议是什么
报告样例 PPT
报告样例 Excel（较快捷）
#4 优化阶段- 输出物：优化方案
把之前的可用性问题，整理做成问题追踪表
追踪表 样例
Tips 测试速度赶不上产品节奏怎么办？
敏捷测试：边测边改，本来要测8个用户，可以第一轮先测4个用户分析优化生成新方案，第二轮再测4名用户
提高测试效率：建立常用用户库，整理工具模版，测试流程报告等进行简化
简易DIY测试
3
问卷调查
适用阶段-需求挖掘阶段；交互设计阶段；正式发布以后；
问卷调查优缺点
问卷调查使用场景
问卷调研的流程
#1 确定目标
#2 设计调研方案
资料收集 - 抽样方法 - 投放方式
#3 问卷设计
#4 问卷测试
#5
#6数据分析
4
数据分析
数据分析流程闭环
网友评论