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

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

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

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

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

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

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

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

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

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

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

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

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