如何区分可用性问题的优先级

通常一个可用性测试能反馈超过100个可用性问题。那么如何将所有这些问题分级，使得开发团队能开始做那些最重要的事情?以我的经验，通过3个问题我们就能有效地为所有问题的优先级分成：低、中、高、关键。

用消防龙头喝水

进行一个可用性测试通常被比喻成用消防龙头喝水：你会被来自用户的反馈数据和问题冲垮。虽然你能试图利用自己的判断来决定问题的优先级，但当开发人员来挑战你的优先级观点时你将如何应对?例如他会问到：“为什么这个问题的优先级是‘关键’?我觉得最多是‘中级’吧。”

利用一个标准流程来定义优先级，能让你始终将看待问题的标准保持一致。这也意味着你能提供给任何需要检查你工作的人一个显而易见的评判标准。

事实上，仅仅需要问3个问题，我们就能区分任何可用性问题的优先级。

这个问题会导致red route吗?

Red routes，经常的或关键的任务。在定义上指系统所必须要要提供的重要功能。例如，如果某个你新设计组件的“开/关”按钮不能使用了，那么所有你的用户都将不能正常使用此功能。因为red routes问题涉及所有用户，因此它的优先级较高。

这个问题很难被用户自己解决吗?

一些可用性问题属于项目障碍物：用户自己无法解决它们。例如，如果一个重要的控制功能被隐藏在一个对话框或一个右键点击菜单里，那么这就意味着这项功能对于某些用户来说是不存在的。另外，有些可用性问题很容易有变通方案。所以，那些很难被解决的问题通常优先级更高，因为它们对用户投诉率有较大的影响。

这个问题持续出现吗?

持续性问题常常会突然发生，并因此影响用户完成任务时间及满意度，这显然属更严重的一类问题。一个持续性问题的例子就是网站的链接没有下划线。这意味着用户只能采用类似“扫雷式”的方式浏览页面。这个问题就属持续存在的，因为即使用户知道了解决方案他们仍然不得不去面对这些问题。请记住“持续性”是指问题反复地出现在各种界面上，用户总是在不同的屏幕或页面上遇到这些相同的问题。

我们能把这三个问题通过下面的流程图表现，并帮助你指定优先等级。

如何定义严重度等级?

关键级：这一级的问题会让一些用户不能完成他们的任务。请务必立即修复它们。

高级：这类问题极大地降低一些用户完成某些常用任务的效率并促使他们找到一种零时性的解决方案。请尽可能快的修复它们。

中级：这类问题会使一些用户有挫败感或愤怒情绪，但通常不会影响任务的完成。通常在下一个周期的正常升级中改进它们。

低级：这类通常是质量问题，例如一些外观显示问题或拼写错误。注意：虽然这些通常是彼此无关的小问题，但太多“低”级的问题也会导致信任感的负面影响，并由此危害您的品牌。

进入论坛参与讨论：http://www.missyuan.com/viewthread.php?tid=426636