可用性测试是一种测试方法，用于评估产品、系统或服务在用户使用过程中的易用性、用户体验和用户满意度。但是常规的可用性测试费用以及需要的条件比较苛刻，那如何低成本搭建可用性测试就成了一个比较难的问题。接下来分享一下我们团队如何建立简易可用性测试的。
实际工作中即使是有同理心基础的设计师，也因为不是实际使用用户不知道使用过程中到底出现了什么问题。根本原因就是不是每个人都像你一样，和你熟悉度一样，很多事情是项目成员觉得想当然的事情，但是对于用户而言并不是那么的“理所应当”。
做测试一定有效果的，哪怕是一个错误的用户做一次做比较糟糕的的测试也能发现现有产品的问题。每一场可用性测试都会对于产品的的优化以及项目组成员对于产品的认知逐步加深一步。做多次可用性测试之后，项目成员能够产生更多有价值的想法和看法。
这里有个常识性的误区：就是当把系统设计的很复杂之后，做测试的价值会有更大的价值。这个常识性的误区考虑的并不全面，再实际的项目运行之中时候，一旦产品或者是优化功能上线，修改时候就不是那么的容易。而且在用户养成固定的操作习惯之后是很难进行改变，如果强行并且频繁改变的话很有可能会引起用户的反感。
这里的反感涉及往小了说是表单或则是字段的位置，大到了一个功能模块都会产生巨大的影响，所以越早测试这种影响越能早发现/影响越小。
常规可用性测试是需要花时间和精力来进行精准用户目标。而简易可用性测试则不需要精准的使用用户，就是随便找一些人进行测试，如果经常进行测试可能比真实用户更有效果。
常规的可用性测试的目的是是需要尽可能的找到全部的问题，然后进行分类和需求的优先级排序。但是简易性可用性测试是为了找到最严重的问题，并且在下次测试前解决问题。
之前通过第三方请过1个农业生产方面的专家（6千/小时），如果没有到1个小时就按照比例进行计算（通常是在35多分钟到45分钟），一次最起码要付出3千多到4千多。而简易可用性测试只需要几百元或者一些纪念品就可以给测试的用户。
常规的选择时间是安排在每个月第一个周一的上午。
1）用户选择
①怎么筛选标准
理想情况下是邀请精准用户。
举个例子：男性，仓管，34-45岁，8-10年的系统使用经验，之前使用过这类的系统。
理想筛选标准一般是包含了：
上面讲的是理想情况下，但是在实际工作中因为要花的时间和精力十分的多，而且也很难找到如此精准的使用用户，那还有一种方式叫做：条件放宽。
换句话说就是就是去寻找到与目标用户类似的用户，这里其实会出现一个比较大的误区：非目标用户无法寻找到产品中的问题？但是这里你要进行思考一下，我们的用户出现了这个问题，是因为参与人员专业度不够导致的这个问题吗？
招募不是目标用户有2点好处：
②什么方式找到
找到用户的的方式有很多，主要是分为对内和对外：
请用户进行测试，别忘了准备100-200准备给测试用户，或者是准备一些纪念品，来表示尊重。
2）环境准备
通常是需要1个安静不被打扰的办公室或者是会议室，同时还需要共享软件，一般使用的是腾讯会议或者是飞书会议进行屏幕共享。另外一间办公室里由测试组员进行观察。复盘时候需要视频来复盘，是一个很好的依据。
3）测试人员
通常分为2种：
4）观察人员选择
人越多越好！！！
在做可用性测试的时候，让参与到的团队成员能有一个冲击感。他们都会改变对于用户行为的认知，摆脱以自我职业为中心的认知，这个时候会意识到我们不是“用户”。
我们作为设计师应该邀请所有跟项目有关的成员进入到测试环节，这里除了常规的成员：技术和产品外以及业务方，还需要邀请到决策层以及上层的主观进入到测试环节中（把决策层和主管拉进来也是为了后面能拉到更多的资源）。
小技巧：如果预算足够的，可以买一些零食，个人推荐巧克力和薯片还是不错的。
5）如何选择测试任务
测试任务取决于现有产品需要需要测试什么流程或者是功能，需要提前拆分功能的流程，就像是就设计剧本杀一样一关一关。将流程进行拆分，然后以卡片的方式在白板上进行展示，并给与所有成员进行讲解。
以一个常规的新建用户为例：
6）提前准备时间
一般从邀请用户到中期的测试流程，一般都要提前1周2周完成。大纲整理差不多1天2天时间就可以完成了。
1）欢迎（大概4分钟）
处于开始测试环节并且讲述测试的规则，让测试用户有个心理准备：
①台词部分
需要提前将准备的台词读出来，需要跟测试用户进行确认。
②安慰部分
这部分是很容易被忽略的部分，这里如果做不好的好的话容易得罪测试用户。这里需要声明3个点：
③情况说明
如果有录像或者是录音的存留必须要要跟测试用说明，不强求用户的测试，即使用户退出也应该给与一些补偿。
并跟用户签署授权/豁免协议。
2）提问（2分钟左右）
主要是询问几个与测试赞誉这相关的问题，主要是让测试用户放松一些还有了解一下时候有之类的产品的经验，以便于进入下一个阶段。
提问部分涉及到了3个注意点：
3）观光（3分钟左右）
提前打产品页面，让用户浏览即将要测试的页面，请参与者讲讲具体看到了什么，以及哪里看不懂的地方。视觉问题在这一步就可以检查出一部分的问题。
然后把操作设备的主动权交给测试者。
4）任务测试（大约35分钟）
这是本次测试的核心环节，主要是让测试用户操作指定的任务，并且通过用户一些的操作以及用户的发声找到产品中的问题。
在整个任务测试过程中，全程让测试者自己走完全程，作为主持人不要引导/影响到用户的判断与决策，在发出提问的时候避免掉会引导用户操作的的问题。除非测试这个时候已经停止操作以及处于绝望的时候，不要给与帮助与接下来步骤的引导。如果发现测流程多次出现测试的求助，则记录下来并且询问具体的原因，还要跟测试者沟通好如果主持人不在的场景下怎么处理？
测试流程中有2个要关注的的点：
5）探查（4分钟左右）
任务测试完了之后，有些场景下主持人或者是记录者需要补充询问道一些问题，还可以向观察室里面的成员搜集他们想问的问题询问到测试者。
6）结束（3分钟左右）
最后感谢测试者加入到测试当中，给予测试者之前承认的报酬（金钱或者是其他报酬），并恭敬地将测试者送出门。
交付物一般情况下是：
7）常见的遇到什么问题
常见的可以分成3种：
1）分类排序与问题评级
首先按照是职责区分：
然后讲每个问题进行分级：最严重的是P0，P3是最轻的，并进行任务的排期。
2）忽略“皮划艇”问题
先解释下什么是“皮划艇”，就是用户在短时间发生了错误之后，在没有任何帮助提示下就能修改过来的问题。就像皮划艇在水流中一样，有的时候水流冲击下会向左或者是向右偏离一下，但是能够快速调整回来，一般遇到这种问题直接忽略就好难免会发生的事情。
1）远程测试
这个使我们团队在疫情期间使用的一种可用性调研方式，测试用户不用来办公室进行测试，只要通过视屏共享就可以进行流程。这模式主要针对工作繁忙的用户，但是在疫情期间反而起了奇效。
2）无主持人的远程测试
就是在规定时间内让用户使用产品/任务流程过程中进行录制视频，从而让操作完成之后团队成员通过视频进行分析即可。
专栏作家
一只鸡腿，微信公众号：B端设计一只鸡腿，人人都是产品经理专栏作家。一个吃货的B端设计师。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
