在移动实习这段时间以来,在用户体验实践上却是长了不少见识,各种理论的应用,各种随机应变,总结出来的经验将在之后的博客中提及,现在先说一下我上到的很重要的一课:摆脱报告中的“学生气”。

  在校期间我所接触到的项目里,每一个阶段都会做总结,用PPT做报告演示,大概的流程是:立项原因??背景资料分析??需求分析??初步设计??设计深入??成果展示。这是很通用的模板,因为我所接触的项目都是与设计有关,因此,可以一成不变的套用上述流程。

  因为移动研究院的用户体验刚刚起步,所以在经验上面很不足,公司领导邀请了诺基亚的体验师过来指导我们进行测试,其中的过程先暂时不提及,在我们做后的结论时,她给我们展示了诺基亚的终测试报告,专业性与商业性给我们留下了深刻的印象。

  因为报告是公司的机密文件,因此不能copy出来,我以我所学到的知识归纳成以下几部分,如果有什么错误的地方,欢迎指正。

  首先,我们要明确做出来的报告是给谁看的,当然在公司里面,不可能是拿来做深入的学术研究,更在乎这份报告有没有价值。在我所接触到的领域里,可用性测试的报告是要提交给两种人:项目经理与设计师(如果是在小型企业,可能是同一个人)。他们的立足点不一样,所侧重的地方也不一样,所以我们呈交的报告方式也会不一样,要是走错了方向,这份报告做的再完美,对他们而言,也是没有意义的。

  拿我们做的一个测试为例,针对W-LAN用户或潜在用户进行的用户体验项目(省略测试内容),测试完毕后,我们整理完数据,做成报告提交,此时不用专门做成两份报告,只需要明确哪部分是项目经理关注的内容,哪部份是设计师需要参考的部分可以。那么在测试之前我们要分析委托方的需求,他们想通过测试得到什么,要分别列举,例如,项目经理比较关心其他平台上的W-LAN或者有相同功能的应用的优缺点,他们开发的应用有什么地方可以去突出,用户的需求是什么。设计师比较关心的是交互方面,他设计的交互方式用户是否能够接受,有没有用户误解的地方等等,因此无论是测试过程中或者是提交报告,明确委托方的意图很重要,交流很重要。

  其次,报告中不要过多的加入个人因素。作为用户体验师,本身也是一个用户,在测试之前,我们会全方面的了解要测试的产品,因此我们心中会有很多建议,而这种建议在用户测试时并没有体现出来,这是一种很正常的现象,因为体验师毕竟是专业的测试人员,是很苛刻的,而用户却是很宽容的,只要能达到目的,会觉得万岁(使用了太多容易产生挫败感的科技产品后一般人都会这样),所以体验师并不能代表真正的用户。在报告里,尽量用阐述事实的语气去表述测试的结果,可以引用用户在测试过程中的原话,这样显得报告更加的客观与正确。

  当然,体验师也可以发表民主的看法,这要特别的注明,不要混淆体验师和用户的观点,体验师是接近用户的人,因此他们的看法也是有一定道理的,这可以放在额外的一节中给设计师参考。

  再次,可用性测试出的问题等级要分明。在整理数据时,我们会列出问题的等级项,好用不同的颜色区分,让人一目了然,当然,好在列出问题后给出用户信息,为什么呢?这是程序的问题,当项目经理或者设计师拿到这个报告时,不会关心用户体验师做了那些工作,找了哪些人做测试,而是结果,那么看了结果后,当然想知道原因,这个时候给出用户信息,他们会知道是哪些用户犯的错。

  后,报告一定要对测试的优点作出肯定。测试当然是测缺点,这跟我们去医院看病是一个道理,医生肯定会说病人哪里不舒服,没有人去医院让医生说那里是完好的吧?当项目经理和设计师打开报告,满目的缺点扑面而来,可想而知,他们是有多沮丧,他们是抱着什么态度来看自己的项目。在给出缺点的同时,也要肯定这个项目的优点所在,不光是安慰人心,而是可以很快找出自己产品的优势在哪里,可以朝更好的方向发展。

  以上是我所感悟的几点了,时间有点久远,记得不是太清楚,这几点也只是报告技巧,那么步骤呢?视各公司而定,每个公司都有一套模板,都是经过很多的实践证明了符合公司发展的模板,我可以提供我认同的一套流程,不一定是好的,但是可以应用。

  阐述测试任务??任务的完成率??每个任务的出错点以及建议??总体的问题归纳??用户资料??满意度评估

  大致是这样的流程,每个项目的报告肯定会有点变化,随机应变,在做报告的时候只需要记住一点:除了自己没有人在乎体验师做了哪些工作,只需要让委托方在报告中能找到他们想要的部分好了。这与学校的流程有一点区别,当学生时,我们生怕自己的过程不被人重视,希望将自己做的所有工作都让人清楚,让观众清楚我们得出的结论是有经过理论论证过的。我想说,在企业里,这些当然是很必要的,但是这些只需要自己知道可以了,我们只需要将结果精彩的展现出来,在报告成功的同时,我们所做的工作过程也是被人认同的。