对可用性问题进行严重性评估，可以把大多数资源分配到最严重的可用性问题上去，并且可以对这些问题是否需要额外的可用性努力进行粗略的估计。如果在♛一个界面中，严重🌞性评估表明，存在着几个灾难性的可用性问题，那么，放过它们显然是不合适的。但是如果一个系统，仅仅存在一些本质上可以被认为是装点门面的几个可用性问题时，我们通常会让其发布。

一个可用性问题的严重性是以下三个因素的组合：

频率（Frequency）：这个问题发生的频率如何，它是通常发生的还是很少发生的？

影响（Impact）：如果这个问题发生，它对用户带来了什么样的影响。用户克服它是困难还是容易？

持续性（Persistence）：这个问题的持ღ续性如何？这是否是一个一次性的问题？也就是说，一个用户一旦理解之后，就会克服它。还是说，这个问题非常难以理解，持续的给用户带来不便（bother，用户心理上感到不便）？

最后，我们当然需要去评估这个可用性问题的市场影响（Market Impact），因为ℱ某些可用性问题可以对一个产品的流行产生毁灭性的影响，即使它客观上来说是非常容易克服的。尽管严重性有着♔几个因素，通常情况下，需要把严重性的多个特征分数整合成一个单一的严重性分数，作为这个可用性问题的总的严重性，以便区分出优先级并进行决策。

以下0-4的等级量表可以用来评定可用性问题的严重性：

0-  我根本不认为这是一个可用性问题

1-  这仅仅是一个装饰门面的可用性问题：并不需要特别的处理，除非这个🌃项目🌞有额外的时间

2-  次要的（Minor）可用性问题：解决这个问题的优先级较低

3-  主要的（Major）可用性问题：解决这个问题是很重要的，优先级很高

4- &nb🥃sp;可用性灾难（Catastrophe）：解决这个问题是非常必要而且紧急的（Imperati💝ve），必须在产品发布之前解决它。

启发式评估中的严重性评级

在启发式评估过程中，当评估者更多的是在关注发现新的可用性问题时，要获得一个较好的严重性评估是比较困难的。同样的，每一个评估者仅仅会发现少量的可用性问题。因此，评估者仅仅只对他发现的可用性问题进行严重性评级是不够的。事实上，我们需要在每一个评估者独立发现可用性问题之后，然后将这些问题汇总，对每一个问题都需要进行合理的，详尽的描述，并配有相应的屏幕截图来进行说明，并用一个完整的列表列出所有的评估者发现的可用性问题，最后将这个完整的🔯列表发给每一个评估者，并附上一个问卷，要求他们对每一个问题进行严重性评级。对一个可用性问题的描述，可以由一个评估观察员（Evaluation Observer）在发现这个问题的评估者（一个或多个）对这个可用性问题的原始评论的基础上合成。或者，如果采用书面的评估报告的话，对汇总列表上的某个可用性问题的描述可以由发现了这个可用性问题的评估者的评估报告中，对这个问题描述合成而来。即使评估者在其独立的严重性评估过程中，没有发现某些可用性问题，这些对可用性问题的描述也可以方便每个评估者较容易的对各种问题进行评定。一般来说，评估者仅需要花30分钟的时间来完成其严重性评级。需要注意的是，每一个评估者必须独立的完成成他们的严重性评级。

大多数情况下，当评估者在考虑多种可用性问题的严重性时，他们并不允许实际接触系统。评估者通过再次访问部分实际的界面，而不是依靠他们的记忆或者对可用性问题的书面描述，很可能会获得一些额🌜外的领悟。同时，毫无疑问的，如果评估者被允许进一步的与系统交互，他们进行严重性评级的速度就会减慢。同样的，如果特定的计算机资源需要去运行一个原型系统，或者因为机密性的考虑，软件分配有限的话，排期问题也很难让每一个人在方便的时间与计算机进行交互。

我的经验告诉我，来自单一评估者的严重性评级太不可靠而难以被信任。当更多的评估者一起评估可用性问题的严重性时，严重性评级的平均数的质量快速上升。在大💫多数实际使用中，采用3个评估者的严重性💙评级的平均数，就已经令人满意了。