可用性测试

　　刚刚从公司的培训课程中学到了"Usability Test"，没想到这么快就用到了实践中，虽然这次的可用性测试不是很正式的从公司外部请用户来做，也没有用单面透视玻璃对用户行为作“暗访”，但同样达到了一定的效果，找出了产品中的一些问题。

　　今天的测试是请用户按照产品的文档完成产品的安装和一个Kernel模块的安装。在写那份文档的时候，我已经自以为很充分的考虑了各种情况，为不同的用户，不同的场境进行了描述，原以为问题不会太大，没想到测试的结果很让我惊讶。

　　用户根本不看文档。如果作为一个有经验的用户，也许在拿到软件包时就是自信的打入./configure && make && make install来完成安装。原以为这次用户在我们强调了文档的情况下用户会看文档，结果用户还是没有看，只有在遇到问题时才会想到文档。准备了 README和INSTALL两个文档，原以为用户会看INSTALL，没想到用户总是喜欢挑短的README看，有详细步骤的INSTALL就不愿意看。
　　当用户发现做不下去要看文档时，我们发现用户只喜欢看文档中列出的命令，而对于命令前后的解释性文字一率是视而不见。但用户有时又无法分辩到底他 看到的是句子还是命令。如果文档中列出的命令用户不熟悉，或者看不懂，他操作起来会很没有信心。用户有时无法区分"INSTALL"文件和"make install"这条命令中的install有什么区别。
　　用户无法看到文档中的重点，当大篇的文字出现在屏幕上时，用户无法找到文章中的重点，三位测试人员不约而同的对文档中对他们完全没有用处的一段文字表现出极大的“兴趣”。
　　用户不看屏幕的提示，屏幕用大写字母打出WARNING时，用户仍然不加思索的回答yes，继续有危险的步骤。
　　用户记不住自己做过的事情和屏幕上的信息，仅管文档提醒用户要记住一行提示，用户仍然不会去记它。
　　如果不在文档开始的地方提醒用户可以把文档打印出来看，用户想不到把文档打印出来放在手边。
　　用户对终端上出现的彩色的字符比较敏感，如果把上面那用户看不到的大写WARNING改成闪动的红色字符也许就很容易引起他们的注意。
　　如果用户在努力很久后，完成了安装过程，但产品却没有正常工作，用户会非常沮丧。
　　当用户第一次失败时，他会认为是自己的错误，如果连续两次失败，他会对产品失去信心。
　　如果用户的相关经验可以指导他直接完成任务，事情会很顺利。如果他的经验无法让他直接得到正确的结果，他完成任务的效率会比没有经验的更差。
　　用户如果不熟悉命令行，让他做命令行的操作会非常痛苦，给他命令依样画葫芦也没用。
　　用户希望文档可以步骤更清楚，而不一定要列出太多的信息。用户希望有Wizard形式的安装过程来代替文档。
　　其实当我列出这些条条来后，反而感觉不是那么惊讶了。这些不都是我们平时在用软件时的一些习惯吗？只不过怎么在做软件时真正把用户的这些体验设 计进去，真正做到以用户体验为中心的设计，这才是真正很难做到的。程序员总是在写程序时把程序的思路放进产品，而很难把用户的体验放进去。

　　实话说，我一直觉得自己在做程序时是很注重用户体验的，但经历今天的可用性测试才发觉，可用性和良好的用户体验存在于产品的每一个角落。以前我 总是太Focus在一些细节的地方，精确到每一个快捷键的设计、图片一个像素的位移这些很细微的角落，有时却忽视了整体上的可用性。

　　同时，可用性的实现，尤其是一些细节上的东西，往往会跟产品的开发周期和Schedule形成相互的制约，怎么在这种相互的制约下达到一个最好的平衡，也是一个要在实践中反复体会的话题。

原文转自：http://www.ltesting.net