简单说一下它的优缺点：

启发式评估的其他特征（优点）：

这个时候，有的同学会质疑？尼尔森10大可用性原则都过去二十多年了，还适用于当下的产品设计吗？

评测人员数量确定

这只是个参考，我认为人数不是重点，重点是事情我们要去做，持续走查缺陷并推动解决，再好的评测方法也不是一次就可以解决所有问题的。

同时，根据缺陷对系统可用性所造成的影响，把可用性问题按照其严重性分为4个等级。这是对于发现问题严重性的定义描述，需要设计师在评测前学习掌握，因为个人差异对于问题严重程度的理解不同，我们需要统一标准。

以下是具体页面评测格式示例：

一个可用性缺陷就是用户界面中特定位置的某个特特征或设施，要通过某个特点问题或困难来加以描述，还要根据某些原理或依据说清楚为什么它是一个可用性问题。

体验评测结果量化：问题数量/问题严重等级

以B2B电商的下单流程为例：

发现一个可用性缺陷并不意味着必须处理它。至于纠正还是暂时搁置所发现的缺陷，这是一个技术性的管理问题，取决于缺陷的严重程度、纠正缺陷所需的费用及现有资源的多少等多方面因素。

六、总结

那些对产品有较大影响、极为复杂的可用性问题，估算其资源消耗可能比较困难，但对其他的可用性问题改进消耗的人力和工时还是可以粗略估算出来的。

归根结蒂，这是一个管理问题，即根据受影响范围、修改问题所需的资源、现有资源情况等因素，对是否以及何时着手解决已发现的可用性问题做出相应的决定。

经常有这样的情况，有些问题一直拖到后期才得以解决，有些则可以完全忽略。因此，这样的决策非常重要，是靠理性而不是随便做出来的。

发现问题并不意味着必须要改正这些问题，但是了解一下所有存在的问题总比忽视不管要好一些。

当体验问题收集上来后，根据体验问题评估标准，对其进行分级，并按照问题严重级别，分步推进：所有严重/致命的体验问题，直接转化为需求，提到项目侧优先解决。

一般和轻微问题，则由设计师以功能模块为单位，按照功能的重要性和问题的多少进行分类：（a）对于问题比较多的模块，设计师先设计解决方案，再推动到项目侧解决；(b) 对于问题比较少的模块，则等到日常需求迭代时，把遗留的体验问题纳入一起优化。通过这样三步走的方式，逐步推进所有体验问题的解决。