在产品迭代过程中红，用户测试必不可少，而其中需要注意的细节也很多，文章针对用户测试的一些流程以及相关的注意事项进行了总结梳理，希望对大家有所帮助。

用户测试大家必然不陌生，在产品迭代过程中，经常会需要做一些大大小小的用户测试，以此来帮助产品发现重要问题。但在实际情况中，我们往往是这样子的：时间不够用啊！要写测试方案，要招募用户，测试demo也还没拿到手，测试报告又急着要，怎么办？！

以下就是根据自己的经历和感受，梳理的整个用户测试过程，希望可以帮助用研新手能更加快速、顺畅地去执行操作，少踩坑，少让自己陷入不知所措的境地。在这里具体不涉及太多技巧类的东西，更多是顺了一下整个流程及其中可能需要注意的一些事项，供参考。

1、需求接受

需求很有可能是在线上接到的，并不是面对面交流传递的，并且还会遇到很多坑，例如需求本身不具体，或者自己理解有偏差，因此在接到需求后，更好和交互、产品等同事进行面对面的交流和沟通。

详细了解测试目的和关键点，确定用户配比。更好是让交互带着跑一下整个程序（半成品demo也好，交互稿也行），这样能在头脑中快速形成操作流程的认知，并把相应关键点对应上去。同时把大致的用户配比情况敲定一下，后续就可以直接招募用户了。

了解demo的完成进度，相应确定具体测试时间。交互、视觉等完成demo的时间具有太多不确定因素，因此我们需要及时了解整个demo的完成进度，在尽可能快的情况下保险安排测试时间，如果邀请的是外部用户，结果用户到了而demo还没出来，那也是够了。

2、方案撰写和确定

让交互稿帮助自己。在完成测试方案撰写的过程中demo还未诞生，具体程序细节记忆又很模糊，不好写测试方案，怎么办？不要慌，去看交互稿吧。

及时沟通。在方案撰写过程中，如果有一些疑问，例如在看交互稿的时候还不是很理解某个具体操作过程，或者自己对产品有疑问的也可以跟交互等沟通，因为自己会遇到的问题，很有可能在测试用用户也会遇到，这样子用户如果问到了，就可以相应作出解释。

核实确定方案。完成方案后，可以在公司沟通交流工具上和交互及产品等同事再确认一下，是否有什么地方遗漏或有不妥之处。

3、用户招募

这是一个大多数人都头疼的一个过程，希望看完了以下几点，可以稍微缓解一下大家的症状。

再次确定测试时间。方案定下来后，再跟交互确认测试时间，了解是否有变动和调整，尽量避免用户来了demo或者测试环境还不ok的情况。

撰写招募文案。需要把用户要求、测试日期和地点、报酬、大致的测试时长、用户需要在测试中做什么，以及报名方式等表达清楚。有以下几点可以注意一下，方便我们自己招募：

详细列出测试安排的时间段。例如10:30-11:15、13:30-14:15，让用户自己挑选合适的时间段，这样就不用事后再协调不同用户测试时间了；优先人力、信息管理、行政等岗位同事。尽量避免相关产品人员、设计岗等同事。 *** 简单的招募海报，并检查。可以事先将“海报”用word或者ppt做好，然后保存成图片格式，记得检查核实一下是否有错。因为在公司IM群上直接黏贴确实方便，但是其排版往往不利于阅读，导致用户会遗漏重要信息。而 *** 成图片格式，可以更好地去避免这个问题，同时还可以显得整个招募过程比较正式，突出了对用户的尊重，也能在一定程度上体现我们用研工作的规范性。

多渠道投放招募海报。内部用户可以尝试先在公司IM群组上招募，之前招募样本量比较小，因此很快可以招到，其他途径暂时未尝试，公司论坛应该也可以，不过隐约感觉效率会比较低。外部用户可以在朋友圈试试，效果还不错，大家都很热情帮忙转发，群众的力量大无穷。也可以相应去搜索一些 *** 群，加入并发布招募信息。另外还有一些社交论坛什么的，都可以尝试一下。 *** 很多，针对具体招募情况，大家就尽情发挥吧~

用户多了留到下次用。海报发出去后，有时也会出乎意料用户数量超过预期了，这是好事，不要担心，也不要急着拒绝，平和的跟对方说明情况，强调下次还会有测试，把用户相应信息了解一下做个记录，下次招募的时候可以直接先联系这几名用户。当然前提是你真的有下次测试需求，如果没有那还是老老实实说明情况。

确保自己和用户能彼此联系上。跟用户强调测试时间和地点，尤其是外部用户，如果招募和正式测试隔了几天，更好在测试前一天再通知一下。给出自己的联系 *** ，同时询问用户的联系 *** 。

之一个用户尽量安排公司内部同事。很多时候demo的完成情况会出现意外，到了测试时间demo还不能用，内部用户可以方便取消或者更换。另外，在之一次测试前谁都不确定用户会有什么反应，之一个测试是可以起到试水效果，而外部用户成本高，用来试水太奢侈。

4、测试准备

材料准备。需要准备的内容有：量表、报酬签收表、记录笔记本、录音笔、会议室借用，以及记录表格，如果是外部用户过来，相应准备一杯水，人家大老远过来也不容易。

测试内容准备。其实每次访谈用户自己都会挺紧张的，不知道用户是不是也很紧张（PS：好想当一回用户，体验一下被访的感觉）。为了消除这种紧张，同时也是为了更好的完成访谈，可以有尝试以下几点：

1）尽可能多的去了解所需测试的产品。有时候demo出来的晚，下午要测试，demo中午才出来，自己都没玩过，测试还怎么搞？之前也说了，那就使劲去看交互稿吧，虽然比不上实际操作来的真实，但是也能有不小帮助，但也要给自己留足熟悉demo的时间。

2）按照模块来列提纲。其实相当于组块策略，把同一个模块的问题放到一起更方便记忆，并且也在访谈中也方便自己和其他同事发现遗漏点。但模块不要太大，如果太大了就相应拆分一下。例如，在考拉新版测试的时候，有“首页”、“活动”、“购物车”等测试，但是光是首页内容也很多，作为一个模块还是太大了，可以拆分成“首页整体感知”、“商品详情”等几个方面来整理提纲。

3）根据任务演练提纲。有了提纲后，按照任务大致过一下所有列出来的问题，这个过程会打乱按照模块列好的提纲，有一次这样的排练，在测试的时候更不容易漏掉题目，而且也相当于模拟了一下测试，自己心里会更踏实一点，在实际测试过程中也能有更好的应对。

相关人员通知。通知交互和产品的同事具体测试时间和地点，邀请他们一起参与。不建议交互和产品只是后期测试查阅报告，如果他们参与到测试中，能更近距离和用户接触，并能更加深刻感受到产品存在的问题，也能更好的推动产品的改进。

5、正式测试

主持人需要注意的点：

划分我们和产品的关系。在测试之前跟用户说明清楚，我们并不是产品的设计者和开发者，我们只是受产品方委托来进行测试，以免用户不好意思当面如实评价产品。强调测试的是产品，而不是用户。要跟用户说明产品尚处于不完善阶段，因此邀请用户过来进行测试，帮助发现问题和改进产品设计，但请注意不是为了评价产品。注意访谈技巧。这个就不用多说了。尽可能深入的去挖掘用户的需求。不要停留在用户话述表面，更进一步去追问，用户为什么会这么说或这么问，例如，很多时候在测试中会碰到用户说“哦，原来这个按钮是xx功能，我还以为是xx功能“，这个时候可以再推进一步，了解用户为什么会这么认为。给其他在场的同时发言的机会。主持人如果觉得自己访谈的差不多了，可以询问一下记录者以及交互、产品等同事，了解他们是否还有问题需要补充。记得量表评分和报酬签收。长时间的测试和访谈后容易忘记量表评分和报酬签收，可以把这两份东西放在显眼的地方，另外可以让记录的同事打个招呼，帮忙提醒自己。

记录人员需要注意的点：

仔细观察用户行为并记录。记录不仅仅是用户的观点、想法等，更重要的是记录用户的实际行为。按照模块记录。记录者可以按照测试方案中的模块来相应记录用户的行为和言语表述。查漏补缺。主持人可能会遗漏一些点，记录者作为旁观者需要提醒主持人遗漏了什么，或者自己有什么新的内容需要补充。

6、测试结束

欢送用户。对用户表示感谢，并开门送一下用户，对于外部用户，更好能送到大楼外面可以看见出口的地方。

测试后及时讨论。这个是重点！在每一名用户测试后及时和交互、产品等同事快速过一下主要发现的问题点，这样做有以下优点：

有效达成共识，确定解决方案。刚访谈结束印象最深刻，因此能快速有效达成对主要问题的共识，并讨论确定相应的解决方案。体现敏捷优势。确定了一些比较严重的问题后，交互和产品的同事就可以相应去改进产品设计，做到了边测边改，加快迭代速度。帮助优化访谈提纲，和测试用户安排。有些问题在事先撰写方案的时候可能没涉及到，在讨论后可以补充进去，而有些问题确定后则不需要再测。另外，也可以通过讨论对事先安排的测试用户进行相应调整，例如增删用户，或者调整新老用户测试顺序等。事后帮助我们自己快速撰写方案。通过讨论确定了关键问题，并且，交互和产品的同事也相应清楚了，因此在最后可以快速形成报告。

再次感谢用户。所有用户测试结束后，可以花几分钟时间简单感谢一下用户。

7、报告撰写

针对不同大小项目的用户测试，在完成报告撰写过程中有两种具体方式：

小测试项目简单快速撰写报告。对于那些1-2天的小测试项目，由于在每次测试后都有讨论，已对主要问题达成共识，因此在报告撰写的时候就可以快速地将主要的问题和风险点呈现出来。

大测试项目每天总结并反馈主要问题。大的测试项目持续时间比较久，针对每天的测试及讨论，简单总结一下主要发现的问题，并反馈给相关人员，如果到了最后再总结，容易遗忘掉一些内容，并且这样子也方便自己最后撰写报告。

以上就是怎样撰写用户测试（针对用户测试的一些流程以及相关的注意事项进行了总结梳理）的相关内容了，更多精彩内容请关注科猫号SEO专员！