从规划到执行，B端可用性测试怎么做？

　　作者对自己负责的B端可用性测试进行了复盘总结，阐述该如何和产品经理一起规划一次可用性测试。
　　可用性测试作为一种以真实用户的使用反映产品的技术，在企业应用中是非常常见的。在可用性测试正式发起前，需要衡量这个需求是否是真需求，是否能够通过可用性测试这种方式去实现。
　　首先要了解背景：也许是从某个渠道了解到用户反馈产品的某功能使用上体验不好，也许产品的某功能是处于一个即将更新迭代的周期内，产品经理想尝试通过可用性测试发现问题并进行相应的调整，不管原因是什么，重要的是要明确为什么要进行测试，以及测试能带来什么。
　　很可能某功能是受到吐槽的，甚至内部外部都有吐槽的声音，产品经理也已经了解到了一些略微具体的点，但是并不确定这些点是共性还是个性。并且此功能不止是用户用，也存在一些其他情况，所以依旧不清楚对于不同的用户群体会有怎么样的问题，在此情况下决定提出可用性测试的需求。
　　根据产品经理提出的需求，进行目标用户的选择，B端用研工作中用户难找是一个既定的实事，但是作为用研也要有自己的底线，尽量寻求真实的用户是底线。做一个《用户招募需求》给到产品经理，上面可以说明测试的目的、奖励及用户须符合的要求，并给产品经理预留出时间寻找合适的用户。此需求可能是用户以及其他一些人员使用，那就应该综合考虑不同的群体在使用的时候是否有什么不同，在测试的时候也需要有所侧重的进行询问。
　　产品经理就她所了解到的用户反馈的问题提出了几个主要想验证的点，在沟通后共同拟定了MVP的任务场景，当然任务场景中会包含需要验证的问题，也需要贴合用户实际的操作场景。
　　拟定好任务后，先把自己当作用户，按照任务的指引，自己走一遍流程，重点在：
　　发现任务过程中是否有不能达成的内容，例如还未开发完的功能，用户是不是会涉及到。
　　额外造成用户困惑的信息，例如一些非必填项，是否要给用户一些填写内容，用户很可能会在过程中询问你，是否需要填，这个时候如果去回答用户的问题，一会显得准备不充分，另外也会打乱用户的思路，如果决定了要给用户的任务中加上非必填的信息，那一定要是全体用户都加。如果不加，需要在任务测试之前，一定和用户说明，按照任务指示来做，其他没有涉及的不用去考虑，这也可能会限制用户的思维。
　　任务顺序的设置是否合理，例如任务中需要使用账号，那这个账号就不应该放在后面再去创建，以及账号创建后的一些限制，可能一些任务需要高等级或者权限，那新账号是否能够满足等内容。
　　最后，也需要衡量一下自己完成任务的时间和难度，是否会因为完成任务所需时间太长而造成用户的反感，如果是这样的话，本次测试任务是否需要再提炼。
　　如果在以上自己的初步验证过程中产生了任何疑问，立即找到产品经理或者负责此事的其他人员协商、沟通，说明理由，达成一致意见。
　　走完以上步骤后，基本可以进行预测试一环，预测试过程中完全把此预测试人员当作真实用户进行测试是有好处的，可以发现真正在实操的过程中可能出现什么问题，再进行调整修改。
　　之后就等待用户到位，约定好时间现场测试即可。
　　在测试现场的时候，用户以为我们去现场的由头可能和我们去测试的由头多多少少有些出入，因为在寻找客户的时候，很可能是通过我们的伙伴去寻找，伙伴也容易冠以“总部专家解决问题”的名义，所以我们要做好用户发问，甚至抱怨、斥责的心理准备。
　　往往用研人员对于产品的了解和把握更多的是针对于每一次的测试内容，而用户感到疑惑的点则更多更散，所以很可能用户提出的问题，用研人员是较难解决的，这种情况下有两个建议：
　　带上更为了解产品及使用的同事一起过去，有问题就先解决问题再进行测试；
　　遇到问题又不能解决的时候，和用户说明这些问题我们会先记录下，回到公司和同事一起给出解决方案
　　不管采取的是哪种方式，都要尽可能的解决好用户的问题。
　　复盘总结
　　接下来就可以正式进行测试了。在测试的执行、复盘、再执行的过程中，做出以下总结：
　　用户招募
　　虽然B端用户难招，但是要有原则底线，要力求真实的产品用户，不要委曲求全。企业中，尤其是小企业中，岗位名称和职责可能存在不匹配的情况，以最终的工作内容定义需要什么类型的用户更为恰当。
　　约定时间
　　去到客户现场要和客户约定好时间：往往都是在用户工作的时候去进行测试，所以要确认好对方有空的时间，避免影响用户的工作，切记不要迟到。
　　测试前
　　大概对用户要有所了解：岗位工作职责产品使用情况（频次、时长、常用功能等），这个可以在去到客户现场正式测试之前的暖场中进行。
　　一定要和用户说清楚测试的目的及原则：“本次产品体验目的是测试产品而不是测试用户的能力，所以如果在测试过程中有感到疑惑的地方请务必多做尝试”，就算用户在过程中有发问也要鼓励用户积极探索，尽量避免直接回答用户的问题。
　　测试中
　　基于客户的操作，结合本次测试的目的，多探求“为什么”进行这样的操作，这样的操作“以为”可以得到的结果是什么。
　　测试后
　　我习惯在测试结束后结合用户透露出来的一些使用习惯，进行一段并不局限于本次。
　　试的一些简单的访谈，例如去到门店会问一下客单价、成交量等问题，去到办公室可能会问一下工作业务流程等，询问用户在产品使用上有没有别的问题（很多情况下，用户在产品使用上都可能存在一些问题，如果先帮助用户解决一些问题，用户可能会更加配合完成本次测试）。
　　测试中全程录屏的资料整理
　　回来后会对录屏进行仔细查看，记录每一次用户的点击操作，再结合最小路径计算迷失度指标。
　　在回看录屏的过程中，能更客观的理解用户的表达，可能现场测试的时候对用户表达内容、情绪的理解只是冰山一角，更多的信息可能还藏匿在冰山之下，所以可以通过录屏资料多揣摩。
　　指标
　　完成度：把用户对于任务的完成度分为四个层次，独立完成尝试完成提示后完成和未完成，其中需要比较注意的是未完成的情况，究竟是用户没有完成还是更为严重的情况：用户以为完成了，实则没有完成，这种情况就更需要关注，这就意味着用户错了都不知道错在哪，如果以后回过头来找寻原因的时候更是无从下手。
　　迷失度：可以直观的用数值衡量用户在操作过程中对页面的理解。
　　情景后问卷和整体评估可用性问卷评分：对用户打分做出统计分析。
　　操作时间：计算完成任务的时间。
　　问题分析
　　结合问题的发生频次和影响程度（结合对任务的完成度和对用户情绪的影响给出的评估值）对发现的问题进行严重程度的分类（但是这并不代表最后解决问题的优先级）。
　　可用性问题的展示
　　可用性测试中，用研得到的是一手资料，也是和用户最接近的人，所以更应该针对用户发现的或者遇到的问题主动提供一些给产品经理、交互、视觉的建议。
　　问题的跟踪
　　问题的跟踪不仅是对自己工作的后续进行关注，也可以看看提出的问题及解决建议从不同岗位的出发点上有没有被采纳，并且也是对自己工作的一个反馈，得到反馈才知道以后怎么进行更好的配合。