移动应用可用性测试的实践经验总结

　　如果你不大熟悉移动应用的可用性测试，没关系，这事儿没你想象的那么困难;不过移动应用与传统网站产品在可用性测试方面确实有一些关键的区别需要我们注意。

　　过去的几年当中，我(英文原文作者)为不少移动产品做过测试，从戒烟应用到移动版的车辆保险网站，其中既包括在实验室使用复杂设备进行的测试，也包括在各种实境化的条件下进行的非正式测试。在本文中，我将为各位分享一些经验心得，希望能帮诸位在实际工作中节约时间，提升效率。

1.关于纸质原型测试

　　我很喜欢Frank Lloyd Wright的一句话：“修改草稿只需要橡皮，修改实际产品则需要大锤”。在产品初期通过纸质原型与用户进行沟通是一件事半功倍的事情，不过如果待测产品的界面需要滚屏的话，应该怎样处理呢?

　　将一张包含若干屏界面元素的纸质原型一股脑展示给用户的话，很难达到良好的测试效果。可以试着用硬纸板制作一个手机模板，如下图所示，在屏幕上下两端各开一道缝隙，将长界面原型插入到模板当中。这样就可以模拟用户在实际设备上所看到的可视区域了。

2.屏幕录制软件的局限

　　用于智能移动设备的屏幕录制软件在可用性测试中是很有价值的，而且它们通常不会干扰用户的操作。不过苹果对这类应用的审查十分严格，例如Display Recorder这样的产品只有通过Cydia才可以使用，但我个人并不希望为了做测试而越狱。安卓当中倒是有一些可用的屏幕录制软件，不过其中的一些缺点也是蛮明显的：

　　屏幕录制软件无法记录手势操作，例如用户为了点击一个微小的按钮而连着点了十多次屏幕，或是在界面上进行滑动操作等等。

　　这类软件在性能和资源占用量等方面具有一定的局限性，很难支持连续一个小时以上的测试流程。

　　这类软件在一次录制过程中通常只能支持一个应用当中的行为记录。

　　必须使用安装了这类软件的测试机进行测试，灵活性有限。

　　这些软件通常无法与Morae一类的可用性测试工具整合使用，场外观察者不能看到即时的记录影像。

　　无法借助这类软件录制用户的面部表情或口头表述。

　　据我所知，有两款iOS应用可以比较好的解决其中的一部分问题。一个是UX Recorder，这款应用不仅可以记录屏幕上的各种行为，而且可以捕捉用户的手势(圆圈表示点击，箭头表示滑动扫屏等)，同时还能通过前置摄像头及麦克风记录用户的表情和语音。不过最大的问题在于，这个软件只能用来在浏览器中对移动网站进行测试，不能用在原生应用上。

　　另外一款应用是Magitest，在我看来比UX Recorder更有用些，它不仅可以记录界面行为、用户手势(目前只支持点击，我相信他们未来会支持更多手势操作)、用户表情及语音，最重要的是，Magitest提供了一个开发包，只要开发人员将相关代码加入待测产品的原型当中，我们就可以为原生应用进行测试了。

3.使用“雪橇”

　　除了使用屏幕录制软件记录用户行为之外，我们还可以采用一种更直接和有效的方案，即“雪橇”设备，也就是将智能手机或平板电脑放在一个挂着摄像头的支架上，供用户进行测试;这种设备的外形很像雪橇。

　　这种方式可以全面的记录用户的实际操作，无论是界面上发生的一切还是用户执行的手势操作都可以尽收眼底，而且雪橇上的外置摄像头可以直接与桌面设备上的测试、观察软件整合使用，譬如Morae，它可以同时支持两个摄像头输入，一个挂在雪橇上，一个用于记录用户的表情，使场外观察员能够即时的看到全部测试过程。

　　很多设计师都使用他们自制的雪橇设备进行测试，我自己也是如此。这其中有几点需要注意：

　　雪橇必须足够轻巧，使用户可以连同移动设备一起拿在手中进行测试。

　　不能让雪橇遮挡住设备屏幕，干扰用户测试。

　　雪橇的尺寸规格应该能够适应多种主流设备，便于用户通过自己的手机进行测试。最理想做法的是使雪橇外形和尺寸可调节。

　　雪橇的造型应该允许用户调转设备的屏幕方向。

　　雪橇整体应该足够稳固。

4.外置摄像头的选取

　　最初，我们在DIY的雪橇上使用了罗技的两款摄像头，C910和C615。这两款摄像头的影像质量不错，解析度很高，可以和Morae测试软件很好的整合使用。不过最大的弊病在于这两款摄像头的尺寸过大，而且C910要安装在雪橇上也不是很容易。

　　我们试过的另外一款摄像头是微软的Lifecam，分辨率有720p，可以和Morae整合，同时便于安装在雪橇上。不过弊端还是尺寸与重量的问题，另外其原生的录制软件也很难用。

　　除了传统的网络摄像头外，我们还尝试了IPevo的文档摄像头。它最让我们喜欢的地方在于足够轻巧，拥有很高的分辨率，可以和桌面软件良好的整合，而且本身就带有一个很灵活的塑料支架。不过缺点也很明显，它很难安装在雪橇上，而且每秒的帧数太低，毕竟它本是用于拍摄文档的。

　　我们最终选用的是Hue的高清网络摄像头，它很轻巧，分辨率不错，每秒帧数也足够，本身带有一个可调节的软管支架，可以直接与台式设备连接使用，另外可选的颜色也很多。不过为了避免用户的注意力被过多的吸引，我们还是选择了黑色的。

5.不该使用技术设备的时候

　　之前几点实践经验都是聚焦在技术方面的，不过在某些时候我们还是要提倡远离技术设备的(手机和平板除外)。前面提到了，我们最近测试了一款专为孕妇设计的戒烟应用，为此我们招募了一批已经生了小宝宝的年轻妈妈来参与测试。这次的情况比较敏感，我们需要到这些用户的家中进行测试，而不是请她们来实验室。

　　为了营造和谐融洽的氛围，使这些用户更愿意进行交流和表达，我尽量让整个测试过程显得轻松随意。其中一次测试甚至是在沙发上进行的，对方一手抱着她5个月大的孩子喂着奶，一手操作iPhone进行测试。这种情况下显然不适合使用任何影像设备进行录制，其他技术设备也很有可能在这种生活化的测试环境中造成干扰。

6.考虑使用情境

　　我们都知道移动情境对于应用设计的重要性，但这其中的重要程度也会根据不同类型的产品而存在差异。来自comScore的统计表明，人们使用移动互联网最为频繁的时候是早上和晚上8点之后，这些时候人们通常是在家中的。

　　我们需要认真考虑自己产品的目标用户通常是在怎样的情境中使用产品。举个例子，孕妇戒烟应用的很多目标用户都提到，她们平时主要是在独自呆在家中、手机就在手边的时候使用这款应用。而对于我们参与过的一个旅行类应用来说，目标用户则会更多的在真正的移动情境中使用产品。对于具体产品的使用情境的理解将有助于我们更有针对性的进行可用性测试。

7.模拟用户的使用情境和周边环境

　　在实验室中，我们通常都能得到稳定的无线网络连接，环境当中也不存在什么干扰因素，但是在实际生活中，这样的环境并不多。人们会在各种情境下使用应用，例如火车上、公交车上、排队过程中等等。在这些情境中，网络连接不会一直保持稳定，用户可能随时拿出设备使用产品，而交互流程也会随时会被打断。

　　保险界的一个客户曾经希望我们对用户在失去网络信号或离开当前会话的30分钟之后再继续操作时的心理预期进行研究。在可用性测试的过程中，我要求用户“设想一下你现在正在火车上使用这个产品，穿越隧道时没有网络信号了。” 然后我问他们在这种情况下他们希望产品在接下来应该怎样表现。通过这种简单的假设，我们可以在一定程度上使用户进入一种实际情境的模拟状态。

　　在我们测试戒烟应用的时候，有一部分用户提出希望来到我们的实验室来做测试。我们决定按照用户的要求来进行，不过为了使环境尽量贴近于“家”的感觉，我们决定直接在观察室的沙发上进行测试和交流，而不是使用到处都是设备的实验室。虽然这并非用户的实际使用环境，不过比起实验室来说，更接近于家庭环境的空间所带来的测试结果可以更有效。

8.使用用户自己的设备，发现更多问题

　　在我们测试移动版的车辆保险网站的时候，我们发现Galaxy和iPhone用户喜欢通过日期选择器的方式完成日期的输入，但是一位HTC的用户却在使用日期选择器输入年份的过程中遇到了很大麻烦。年份的选项太多，导致反应迟钝，用户在滑拨的时候一下子就将整个界面滚动起来。

　　在测试旅游计划应用的时候，我们让用户使用自己的设备进行操作，发现其网络连接和部分界面反应速度确实很慢。这类问题在使用我们的测试机进行测试的过程中是很难发现的，其中有些问题在发现之后确实是可以进行改善的。

总结

　　围绕移动设备进行的用户体验设计早已不是一小撮UX人所进行的小领域工作了，无论设计过程本身，还是诸如可用性测试这样的上下游相关工作环节，都需要我们投入更多的精力去思考和对待。

　　本文提到的这些经验都是从我个人的工作过程中总结归纳出来的，希望能为大家提供一些参考价值，少走些我所走过的弯路。