什么是可用性问题（Usability Problems）
相比视觉设计、产品经理等角色，交互设计师经常要面对很多琐碎世且实际的可用性问题。例如：筛选按钮找不到、在文本输入完成前就开始报错、操作提示不够明显……这些问题不一定都是设计问题，可能相当一部分是开发中的bug。本文主要针对设计相关的可用性问题。
问题类型≠重要程度
有些可用性问题看起来很小，实际上却至关重要。例如，“找不到反馈按钮”和“找不到注册按钮”，两者在性质上是一样的，但是前者对大部分用户来说都没什么影响，而后者却可以成为用户转化率的蔽障。
有些问题看起来很大，实际上却不对使用造成直接影响。例如，页面漏掉标题，用户如果不记得自己点了什么，就不知道自己在哪里。但是如果大部分用户都能记住自己的操作目标，那么这个问题虽然是个很低级的失误，重要程度却不是那么高。
问题多少≠设计质量
可用性问题多的设计，并不一定就是糟糕的设计。因为交互设计的首要任务是把控的是整体的使用体验（如：让用户以最愉快的体验和最少的步骤完成注册），而非细节操作（如：主要按钮要比次要按钮大多少才合适）。但是，如果一个交互设计方案不能规避重要的可用性问题，那么非常可惜，这个设计虽然很出色，却无法带来应有的价值。如果设计中出现很多低级问题（如：遗漏信息等），就说明这个方案做得不够仔细。
可用性问题少的设计，未必就是出色的设计。十年前的手机和今天的手机相比，可用性问题也许不相上下。而且由于十年前的手机功能较少，因此可能性问题说不定也相对较少。但是十年前的手机拿到今天来看，绝对跟“出色的交互设计”差之千里。究竟什么才是优秀的设计，这个问题也许需要另一篇文章才能说清，但是可用性问题的多少，绝对不再里面占据关键地位。不过，可用性问题少的设计，一定是使用起来较为顺畅的。
如何处理可用性问题
只有用正确的方法整理可用性问题，有先后顺序地解决它们，才能够确保设计的成功落地，不辜负一个出色的设计方案。处理可用性问题的方法很多，总的来说都包括两个步骤——评级和分类。
大名鼎鼎的尼尔森（Jakob Nielson）建议让至少三个以上的专家（如交互设计师）来将问题分类并评级；而有些面对面的用户测试方式，如Think Aloud，则鼓励让用户来评定问题等级。支持专家评级的派别认为让用户评级太过缺乏全局视角；支持用户评级的派别认为专家对设计太过了解反而不够理性。
我认为还是要以两到三个以上的专家评级为主，只将用户评级作为参考。因为如果纯粹让用户评级，可能出现用户对一些无关紧要的细节太过关注的状况。当然，这纯属个人建议。而对于问题分类，由于太过复杂，所以不可能交给用户。
评级
评级应该放在第一位，这样才能尽快将不重要的问题排后，聚焦关键问题，从而提高效率。评级的方式业界有很多种，下面列出的是较为主流的一些选择。我比较推崇第一种，原因是描述比较清晰，并且适用场景也比较广。
由于不同产品的使用目的可能相差很大，设计师可以以现有的评级方式为依据，创造适合自己产品的评级方式。
Jeff Rubin提出的：
4: 无法使用产品的某一部分 | Unusable: The user is not able to or will not want to use a particular part of the product because of the way that the product has been designed and implemented.
3: 难以完整使用产品的某一部分 | Severe: The user will probably use or attempt to use the product here, but will be severely limited in his or her ability to do so.
2: 大部分情况下能够使用，但需要付出较大努力 | Moderate: The user will be able to use the product in most cases, but will have to undertake some moderate effort in getting around the problem.
1: 偶尔发生且容易解决，或者问题并不在产品的主要功能上 | Irritant: The problem occurs only intermittently, can be circumvented easily, or is dependent on a standard that is outside the product's boundaries. Could also be a cosmetic problem.
尼尔森提出的：
0 = 我不认为这是可用性问题 | I don't agree that this is a usability problem at all
1 = 只是美化问题：除非有多余时间，否则不需要解决 | Cosmetic problem only: need not be fixed unless extra time is available on project
2 = 很小的可用性问题：解决的优先级较低 | Minor usability problem: fixing this should be given low priority
3 = 主要可用性问题：重要，需要优先解决 | Major usability problem: important to fix, so should be given high priority
4 = 关键可用性问题：在产品发布之前必须解决 | Usability catastrophe: imperative to fix this before product can be released
Dumas 和 Redish 提出的方法：
Level 1: 阻止任务的完成 | Prevents Task Completion
Level 2: 造成较大的延迟或挫折 | Creates significant delay and frustration
Level 3: 问题对可用性有较小的影响 | Problems have a minor effect on usability
Level 4: 微小且可能的改进点或建议 | Subtle and possible enhancements/suggestions
Molich 和 Jeffries 提出的：
1. 微小：稍微推迟 | Minor: delays user briefly.
2. 严重：虽然能完成任务，但是推迟较大 | Serious: delays user significantly but eventually allows them to complete the task.
3. 关键：阻止用户完成任务 | Catastrophic: prevents user from completing their task.
分类
问题分类的研究其实比评级的研究更多，但是对实际处理问题并没有很大的帮助。不过如果你需要评估一下差评的可用性维度，或者走查一下自己的设计缺陷，还是做一做问题分类还是有帮助的。
问题分类的可变性更高，所以建议不要完全依赖已有的分类标准。例如尼尔森的分类法里，就没有对于交互方式是否符合任务需求的类别，而这一类对目的性较强的产品非常重要。
尼尔森的分类法：
1. 系统状态可见
2. 系统与用户现实世界的匹配
3. 用户控制与自由
4. 一致性与标准化
5. 错误预防
6. 认知而不是记忆
7. 使用的灵活性与效率
8. 美观而精炼的设计
9. 帮助用户识别、诊断和修正错误
10. 帮助和文档
由于可用性问题很多，所以不需要每一个都整理得非常精确，而且很多问题的确是没法明确定义的。所以在多名专家进行整理时，可以平均大家的评分得出问题的最终评分。问题分类上如有不同意的意见，可以讨论表决定夺。
将所有问题汇总在一张表里，将分类和分级写上，按照优先级来解决问题。这样一来产品的体验提升就有了量化的方法。