可用性评价

无论产品需求是否够完善、够明确，我们不都应忽视在设计中也要验证、求证。这不单指和PM之间或和上下级的关系。这里介绍“产品可用性评价”的几点拙见、希望设计师更加顺利、高质量的完成设计。我们不做单一执行者，以产品增长价值为目标！

你是否遇到过这些情况：

1、产品项目进度十分的紧张、设计师做完了设计稿立马拉着产品、技术、运营等相关人员进入评审环节，会议上大家各抒己见、挑出一大堆问题。

2、你的上游或者领导每天几次的查看你的设计成果、并指指点点，要求你改完了立马汇报。让你的设计陷入了无休止的修正。

3、你的公司根本不允许你做任何可用性测试、更不重视任何的用户数据，设计阶段几乎没有真实的用户参与过。

结果，团队花了很大的劲做完了、上线了，产品并没有得到明显的改善，甚至需要花费几个版本迭代去处理新的问题。

一、什么是可用性评价

那么这里出了什么问题，项目内的成员能力不足？一开始的需求是错误的？不见得。这里的问题可能出现在几个方面。最根本的需求问题这里就是不去展开说了，一方面是项目流程问题、你可以回想下你的团队是否在使用原始的瀑布流、整个项目的流程上下游脱节严重，完全靠会议解决问题。另一方面就是今天主要说的，是不是产品在做的过程中没有重视阶段性的评价、以及整个产品的设计阶段是没有真实用户参与过的。

在不考虑需求、流程的前提下、本次主要说能够更良好的设计产品的可用性评价。帮助设计师在整个项目流程中认知到我们可以做的更多、更好。那么我们首先来了解什么是“评价”。

评价——好比你是一个学生、你的能力需要通过成绩体现出来。如果公司只通过瀑布流中的评审作为交接点，好比是一次次的期末考试。即使是需求明确的前提下，我们没有机会去做阶段性的验证，所以我们需要课后测验、以及月考来不段打磨、修正。所以评价可以分为、期末考试类的“总结性评价”，和月考类的“阶段性评价”。

二、如何做评价

1、阶段性评价

实行阶段：

在设计中（未完全交付开发阶段）让用户、其他产品相关人员参与进来，或者是公司内基本符合用户条件的人参加

，而且这个过程是可以重复的。人数上每次安排3~5人即可（尼尔森认为一个人大概可以发现35%的问题）。

2、总结性评价

实行阶段：

设计前或设计后，也就是有专家评审参与的需求评审和设计评审，

3、评价的方法

3、1发声思考法

推荐使用“发声思考”发；让用户（此阶段可使用公司内部类“用户”的同事代替）把使用的过程中所想所感、及时的表达出来。因为这并不是在做可用性测试、所以我们没必要去使用有效性、效率这一套标准，直接记录下来整理即可。

3、2启发式评估

人员应限制在5人以内，且首要目的是在专业上提出改善建议，人员是几个人先分开评价，而不是开会讨论。而且需要主持人提供评价公认的评价原则，像尼尔森十大原则、IBM体验原则、或者综合整理的标准都可以。需选择产品设计相关的人员。

3、3用户测试

这里就是基本的可用性测试、数据分析方法。一对一访谈、眼动测试，这类过程也比较耗財耗力、一般需要2周的时间。

回顾上面所述，我们要在产品的设计过程中阶段评价结合总结评价。并尽可能的让用户参与（没有用户就上面所说的公司内类似实际用户的人）。 不要在以为这是浪费时间，因为产品在交付开发或者上线后，往往实际验证需要补的窟窿更多！