三思而后行不是好事;况且人无远见。
大家都在测试移动产品的可用性。
6月初,我用了一周左右的时间,完成了从电话邀请到可用性测试面试结果的反馈。
一开始突然让我做可用性测试,我的脚本朋友已经做了(不知道这个脚本提前准备了多久)。我想做的第一件事是给报名参加测试的客户打电话。所以我发现了电话列表选择的难题和一些电话邀约的方法。测试前的准备结束后(其实也不算认真细致,就是我和另一个交互的人做的测试),之后我们会开开心心的欢迎硬招的测试客户,然后名正言顺的按照现有的脚本进行整个测试过程,以后再做可用性测试分析。
这是我第一次申请并参加可用性测试。刚开始的时候,我对整个过程没有任何相关的知识,基础就是会跟着别人走。测试后我义愤填膺,赶紧买了Insight用户体验电池充电。现在回想起来,可以看到一周的工作,我收获了很多。以下是思考、学习和培训,期待大家一起交流和发展。
早期提前准备环节要充足1.测试脚本提前准备1)测试功能和日常任务
明确先考什么角色,优先考虑这个角色,可以参考必要性和服务质量。用一句话概括精英团队最想了解这个角色的什么。
然后设计方案,精心规划每天的任务,要典型、有效、可行。日常任务的语言设计方案要防止页面上已有的关键词出现,造成影响。应该估计实现目标所需的时间,以防止时间过长。在日常任务中间测试顺序,科学安排。
2)测试评估方法预设
达成目标的比率,他们犯了多少错误,他们能修正多少次,有多少人成功完成了他们的日常任务;
统计结果不适用实际时间等。,但只是相对标准值。比如达成目标的比率:
0不成功1用曲折的方式迟缓进行2偏慢进行3迅速进行2.征募客户提前准备1)选择规范
与你的测试目的相关,尽可能小的代表日常任务的整体目标受众。从网上的资料可以得出,A是否应用了商品B,手机上的机器设备应用的是Android还是iOS。
每个简单的测试保证招募至少5个测评人员(科研强调5个客户可以发现85%左右的问题,但实际上为什么可以问百度?有说法)。招聘时,招聘6~10个客户,避免部分客户的暂时失败。
2)招聘时间
第一,也要看计划的状态。如果安全地分发脚本和其他事项,并且只招募剩余的客户端,那么它将稳定而快速地进行。特别要注意对受邀客户的测试时间分配,一定要提前预估,避免客户到场后最后一次测试没有进行的尴尬。
3.测试全步骤提早分配周全测试前:
测试场所(尽可能复原客户应用商品的情景,且确保测试不会受到周边环境要素影响)客户招待(提前准备水)测试时:
参加工作人员(不必过少或经常拆换,给客户导致不舒适度)测试方式(随测随问,還是测试进行后再统一提出问题。这一与每日任务设计方案有关)手记纪录(即依据测试评价方法对客户测试状况开展纪录)视頻拍摄器材&视角(调节好,应用手机上对客户手臂实际 *** 作录视频时,防止內容录反方向)测试后:
剖析必须的內容(不一样测试指标值对最终剖析結果有什么关系)预估輸出成效(可用性测试汇报的內容)电話邀约的一些方法在收到一份按照“最近申请注册和未使用商品”的规范选取的电话清单后,简单拟定电话内容后,被动的“电话试听”就开始了。大家一定要在电话里说清楚客户是不是合格的测试客户,然后邀请合格的客户。
这意味着在通话开始时,每个人都需要了解一些与对方会计相关的个人问题。最后的结果是,打了一百个电话,大家都没有成功邀请到一个客户(周四周五电话邀请,测试时间是下周一到周三)。
一同参与电话邀约的朋友,在拨打时选择了各种方式挽回客户,包括“参与测试的机会难得,诚挚邀请您报名参加”、“测试时间短,大家感恩XX元”。幸运的是,最终通过这种方式成功邀请了三位客户(也有一些客户打算一直报名但行程不定)。
在这次电话邀请中,我学到了很多东西。
1.随着邀约对象的情况,放慢声音,给对方反思和提问的时间。
刚开始觉得邀客原曲太长,所以声音快,后来发现比较不利。电话那头的客户知道你的意思。之后,在整个通话过程中,当详细介绍完自己的真实身份后,会有停顿,给对方一个反应速度;接下来,放慢声音,确保对方能听懂你的意思。
2.邀请发言。
邀请客户的语言很重要。掌握在整个沟通过程中不侵犯被邀请客户的安全防线,让对方感到舒服或不舒服。这样做是最好的。另外,它还有一个目的,就是获取必要的信息内容,明确是否是整体目标客户。最终目的是想办法邀请整体目标客户。
3.坏了就坏了。对于无疑不是整体目标群体的人,不要说空,尽快打完电话,注意委婉。
4.人物角色理解,这里在电话里,我指的是企业的品牌形象。
电话一出,我就不单纯是邀请人了,我指的是公司的品牌形象,只不过我跟在线客服呈现的服务项目不一样。因此,当被邀请的客户了解到超出服务范围的问题时,我应该尽力给予协助或帮助指明解决问题的方法。或者在找到解决难题的方法的情况下,再次拨打客户电话。
5.提高防范意识,学会辨别。
不要在工作之外与被邀请的客户接触(前提是电话的目的不是联系客户),或者与客户保持距离。
测试全过程中清除影响按照准备好的测试自然环境和分布的测试流程,测试刚刚平稳开始。
我还在查询客户手臂录的视频,发现了一些难点:
录制视频不详细或正中间存有断块,即一部分用户满意度沒有搜集详细;手机上半途有电話打进,存有影响。此外,它表明demo可以在可用性测试的整个过程中产生少量的变化。【在这个场合,因为我热烈欢迎学习期间的交流】
测试后立即輸出汇报我根据视频录制的客户手臂实际 *** 作的视频进行了测试分析和问题总结。因为我对可用性测试分析知之甚少,收集的资料也没有详细描述,所以我感到很沮丧。最后,在《洞察用户体验》一书中,我学到了以下专业技能:
梳理汇报的方法:不必展现彻底负面信息的汇报;关心真正的群体;明确提出建设性意见;可用性测试报告应包括以下信息:
新项目概述:科学研究結果展现全过程的简略叙述:解开步骤的神密面具并为汇报的收货人出示有利于了解結果的关键情况测试自然环境和征募规范:清晰表述征募了哪些人及其怎样实际 *** 作重要发觉:汇总关键主题风格。提取引入客户的原句评定者档案资料:让汇报用户对测试者有形象化的体会最后,三思而后行并不是一件好事。
况且人无远见。
文章作者为@covershuang,未经批准严禁截取。
注:阅读相关网站基本建设方法的文章,请移至网站建设教程频道栏目。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)