启发式评估(Heuristic Evaluation)

启发性评估(Heuristic Evaluation)的好处：

1.在用户测试前获取同行意见非常有价值因为这样一来那些可以自动检测出的东西就不必浪费时间让用户试用了你希望的是把注意力集中在有价值的用户测试资源上集中在人们不易察觉的方面.

2.同行审查提供的大量定性反馈在重新设计你的应用前也十分有价值 因为这能够告诉你原来设计的应用总有哪几部分可以保留 以及哪些部分存在的问题较多 需要重新设计.

3.有时候你知道有一些问题而你需要数据来说服别的小组成员来做出改变 同行审查是一种好办法 尤其是当它被结构化时 可以给予你所需要的反馈 可以带来你所需要的改变.

4.这类结构化的同行审查在发布软件前也十分有价值因为它帮助你为整个设计做最后一次打磨 磨平所有粗糙的边缘 与大多数评估模式相同 围绕一个明确的目标展开审查非常有用 即便你最终看到的完全出乎意料.

关于启发式评估：二十年前 由雅各布·尼尔森(Jakob Nielsen)及其同事创造启发式评估的目标是找出设计中的可用性问题。

基本思路：“先独立再协作”

1.是你需要为一组人 通常是设计小组的其余成员或者外部的设计专家
2.提供一组启发法或基本原则 他们会借此找寻你设计中存在的问题每位人员都会先独立完成这一试验, 也就是说他们将利用你的设计来进行不同任务从而发现其中的漏洞 你会发现 不同的评估者会发现不同的问题
注： 那么 你会用到哪些原则？ 尼尔森的十个启发法、 你可以根据自己的需要对其进行扩充 因此 如果你有特定的设计目标把它们列入原则清单；现有的竞争分析 设定了的设计目标 ；你在你的或别人的设计中发现了闪光处 可以列入启发法清单.

3.接下来直到最后他们才会相互交流沟通 这一过程的最后 他们会回到一起谈论各自的发现 这种“先独立 再协作”的方法 能帮助你在拥有众多评估者时汲取“群众的智慧”

关于要多少名评估员：

从成本效益的角度来看超过某一数值后也就失去了意义 那这条曲线的最高点在哪呢？ 它当然取决于你试验的用户界面 取决于你花多少钱聘请评估员 整个时长等各种因素 雅各布·尼尔森对于这类用户界面和启发性评估的经验法则 告诉我们三到五位评估员就是最佳组合。
（详情查看Heuristic Evaluation: How-To: Article by Jakob Nielsen）

关于启发式评估和用户测试：

优点：1.启发式评估更快
一位评估员只需要大概一两小时 而让用户进行测试的机制会慢一些 还不算上可能不得不建立软件所花费的时间 

2.启发式评估的结果能够预先解释因为评估员会直接将问题和需要解决的事情呈现给你，这样一来也省去了从可用性测试中推断问题和解决方案的麻烦

�缺点：专家审查一遍你的系统 会导致在现实中不太可能发生的误报的产生
 这种情况的确存在 因此 用户测试从定义上看会更准确一些

总而言之 我认为交替使用不同方法很有必要 所有你们将在这门课上学到的用于获取反馈的技术都很有价值 而通过交替使用各种技术 你通常能够各取所长 就好比通过用户评估和用户测试你会发现不同问题 ，而通过在初始的设计阶段 开展启发式评估或类似方法 可以避免耗费后来可能获得的真实用户。

具体步骤：

1.要做的第一件事就是让你的评估员了解最新情况让他们了解你软件背后的故事 ，总之是了解各种可能需要的必要知识， 并告知他们将要进行评估的场景
2.可以进入评估阶段,人们开始审查用户界面

当评估员审查你的界面时 列出一个具体的问题清单很有必要 并且还根据启发式设计法解释这些问题 你一定不希望人们的反应是“我不喜欢”为了最大限度地说服设计组成员接受这些结果 你可以把这些结论分类列出这样它们才能被高效处理 分类清单还能够避免重复记录同一问题 如果有个页面每个视图都有 你不会想要按试图重复列出这个点 你只想要列出一次并一次解决。
3.每个人都会分派到一个威胁性评估 你首先需要分别进行这个评估 之后你再把人们集中起来进行群组威胁性评估并制作一份综合报告.
4.在评估员审查过界面后他们可以独自为自己发现的问题进行重要级别排序.

评估员会用到的严重性测量法需要结合以下几方面： 需要结合频率、影响 以及他们发现的问题的说服力;利用数值在0和4之间变动0代表“综合考虑后评估员认为这不是可用性问题”数值上升表示问题越来越接近灾难性。

所以在这里你看到的是他列出了问题 并给了一个严重性评级 和给出了该问题违背的启发法然后具体对问题进行了描述 最后 在所有评估员审查完界面后列出了问题 并结合严重性和重要性进行了分级 然后你再和设计组分享报告 这是个讨论用户界面中的普遍问题和定性反馈的好机会 这给了你一个审查每个项目的机会 同时还能就解决问题的方法提出改善建议在汇报阶段 这对于开发组而言 估计解决一个问题可能花费的努力很有价值 举个例子 如果有个问题在需要处理的严重性范围 但并不太严重 或许是措辞的问题 并且很容易修复就像在告诉你“快去修复它”反过来 也可能碰上灾难级别的问题需要花更多的功夫去修复 但其严重性级别会促使你去修复它 也会遇到一些问题 其重要性和成本相比起来 使得它并不值得立即处理 这个汇报阶段也是对未来设计点子的一次头脑风暴尤其是当所有设计参与者都在一起时 这样的话 关于用户界面存在的一切问题都能清楚地存。