经验分享丨启发式评估使用的7大法则

不知道你是否经常遇到这样的问题：

• 设计方案出来后再用户测试前，希望发现一些潜在的问题。
• 产品马上就要上线了，能否快速检验下有没有什么问题。
• 刚入门的新手设计师的设计方案如何验证并且快速优化。

今天本文将介绍工作中经常用到的评估产品的方法——启发式评估。通过它应用的7大注意事项详细的阐述我对该评估方式的理解。

01 什么是启发式评估

1990年尼尔森博士提出的启发式评估指的是安排一组评估人员检查界面，判断其是否与公认的可用性原则相匹配，属于一种简易、通用的可用性测试评估法。

启发式评估主要依靠资深工作经验以及知识储备的评估者（最好非设计师本人或者与当前产品相关的项目中人员，避免陷入知识的陷阱）在可用性原则的基础上对设计好的界面进行评估，试图发现问题以规避。

它由于测试成本低且测试过程较为快速，在团队内部就可以完成该过程，因此也被成为“经济评估法”。

02 启发式评估使用的注意事项

2.1 启发式评估的使用不是万能的

启发式评估在产品设计和开发的任何阶段都适用，不局限于某个特点的时间段或者产品。只不过在原型阶段发现问题的话，修改成本最低，因为此时产品投入资源较少、风险最低。

虽然它有这么多优点，但是由于它不涉及真实的用户测试和用户行为分析，缺乏较为理性的数据支撑，在结果上受测试者的主观影响较大。

那么我们在什么样的情况下使用启发式评估呢？

（1）资源不足

当团队规模比较小，但我们最近想对产品做体验优化，这时候我们可以组织几名设计师一起参与对老产品的启发式评估，去发现需要改版产品的体验问题。

（2）经验不足

当作为一个小白刚入团队的时候，在做完手头项目后对已完成的设计稿可能并没有太大把握，需要检验方案的合理性，这时候可以找团队内较为资深的设计师帮忙，确保设计目标的完成度。

（3）时间紧迫

团队新来一个产品经理，提了一个看似不那么靠谱的需求，这时候作为经验丰富的设计老司机为了避免踩坑，需要快速验证一下产品需求的合理性，避免重复造轮子。

2.2 明确定义评估范围

启发式评估前需要对此次的评估范围做一个界定，是评估整个产品还是产品中的某一块，大多时候我们的评估范围仅仅局限于某一个功能或者某功能下面单独页面的某个模块，局部的评估可以让我们更加专注产品的体验。

我们需要把测试任务划分为多个不同的用户使用场景，这样评审专家就可以站在用户体验的角度，通过完成涉及范围内的任务，发现可用性问题。

2.3 选择合适数量的评估专家

并不是越多数量的评审专家越好，这涉及用人成本以及测试时间的成本。评审结果我们不能仅凭专家的数量堆砌，要靠专家的质量。

根据2012年尼尔森博士的试验证明，只需要5个人就可以发现85%的可用性问题，因为再多的人并不会带来更多问题的曝光率。真正重要的问题都已经被包含，对于普通的版本迭代基本上已经满足。

2.4 确保专家对评估指标熟悉

找专家过来前可以先召开评估的启动会，分享我们要实现的产品指标，以便他们在评估过程中熟悉产品，知道要做什么。

评估指标通常包含3个部分：整体性指标、项目指标以及流程性或者页面性指标。

（1）整体性指标

基于产品总体的整体性指标，主要针对一致性方面的指标。例如整体的视觉风格是否统一。交互逻辑是否统一。文案是统一。不同版本的延续性是否统一等；

（2）项目指标

针对具体项目的特定指标，是指除了通用性或者流程性指标之外，针对具体项目的特殊指标，这需要根据具体的项目去设定，做到评估标准的灵活调整。

（3）流程性或者页面性指标

页面体验中整个流程或者基于每个页面和步骤本身的评估。例如页面内信息的可识别性。页面内信息与真实场景是否一致，是否具有可理解性。用户是否可以进行正确操作。用户是否可以自由的选择操作方式允许用户出错等。

2.5 确保启发式评估原则与当前产品相关

提到原则很多同学第一印象就是尼尔森10原则，这个原则里面的预防错误原则、一致性与标准化原则、系统状态可用性原则等似乎成为了设计通用的准则，那么事实真的如此么？

假设我们现在做一个校园网络后台管理系统，针对该产品，我们首先应该关注什么维度呢？

首先应该是系统运行的稳定性，再者网络安全性我也很关注，其次是系统反应速度得快。那么作为对视觉有点要求的人，系统展示的样子是不是也不能太丑，否则会用不习惯。当然从专业的角度肯定还有其他更贴合产品的维度作为评判标准。

评判产品的标准很多，我们要有所取舍。虽然通用性标准在使用上肯定没有什么问题，但是如果我们站在更符合用户体验目标的角度去分析会不会更加合适。

2.6 建立合适的评估标准系统

启发式评估是一个发现问题的系统，建立可用性问题的评分系统可以帮我我们评定专家发现问题的严重程度。作为评估最后的输出，涉及了事后处理的优先级。根据问题对系统操作造成的影响，我们可以将可用性问题分为以下4个等级：

（1）轻微问题（1级）

不易察觉，视觉表现问题，改起来较为容易，有额外的时间可以修改，优化后可以提升用户体验细节。

（2）一般问题（2级）

可改可不改，偶然产生的可用性问题。它的存在会影响产品性能，但是不影响用户任务的完成，予以一般的优先级。

（3）中等问题（3级）

因为该问题会让产品学习以及操作体验变得困难，明显的增加产品流程中的跳出率，应该予以足够高的优先级。

（4）严重问题（4级）

显而易见的问题，它的存在会极大的降低产品的可用性，予以最高的优先级，需要立即解决。