第一次走到新的办公室，透过落地的巨大玻璃门，可以看到里面的会议室。许多人会习惯的去推门，同时脚步并没有停下来。结果“哐”的一声巨响，整个身子就撞了上去，鼻子贴到了玻璃上。原来，这扇门是只能拉而不能推的，这是每个人都会遇到的事情：只能拉的门去推，只能推的门去拉，或者直接一头撞进那种左右滑动的移门上去。这是Donald A。 Norman在一本很有趣的书，名字叫The Design of Everyday Things里描述关于门的例子。

　　这个时候，许多人常会自责“自己真不小心”。其实，傻的不是我们，而是门的设计师。因为这是会让人犯错误的设计，是易用性出了问题。易用性差的门，就像给我们设计的圈套，等着我们掉进去。所以，易用性是一门学问，软件易用性对于软件开发越来越重要，它常常是软件是否被广泛使用的决定性因素之一。比如 Windows的技术不比Unix先进但却更流行，其中一个因素是易用性做得很好，如界面友好、操作简便、丰富的帮助支持和外形靓丽。

　　一、软件开发中常见的易用性误区

　　人们对于软件易用性的重视程度越来越高，但软件易用性测试一直是一个很具挑战性的测试内容。目前很多易用性测试是通过用户反馈来完成的，例如在一定范围内散发试用版，然后等用户的反馈。但是这种方式投入较多，而且等待反馈需要的时间也很长，最重要的是测试效果也是强差人意。究其原因主要是对于软件易用性存在着诸多误解。

　　（1）忽视和误解了软件易用性概念

　　近年来，虽然在软件开发中GUI Design（图形化交互界面设计）以及易用性已经得到软件团队的普遍重视，但众多软件开发团队在该领域还处于起步阶段，甚至妄图用“美工”这一图形设计角色来解决软件产品中出现的各种诸如人机交互、界面设计以及易用性改善方面的问题，而这样的做法必然导致软件产品的不可用，其易用性则更加无从谈起。

　　易用性是用户体验的一个重要方面，但许多软件开发人员往往会沉溺于自己的思维习惯，而不管用户使用得是否顺畅。例如，在易用性方面缺乏考虑用户是谁、他们背景是什么、用户具备了哪些知识、用户想做什么或需要做什么、用户工作时的情境是什么状况等。实际上，易用性是一种以使用者为中心的设计概念，易用性的重点在于让软件产品能够符合使用者的习惯与需求，是希望让使用者在使用的过程中不会产生压力或感到挫折，希望使用者能有愉悦的心情并用最少的努力发挥最大的效能。

　　（2）混淆了有用性与易用性的区别

　　我们常搞混有用性和易用性的区别。普遍的情况是很多软件企业仍然对易用性熟视无睹，对真正改进客户满意度的途径不能理解。这些企业仅仅关注于软件产品功能的基本可用，而忽略了其易用性。事实上，易用性是软件产品的一个基本属性，标志着软件产品的可用程度和成熟度。

　　有用（Usefulness）这个概念可以进一步分为易用性和功能性。尽管这两个词是相关的，但它们却是不可以相互替换的。功能性是指产品完成任务的能力，产品被设计为能完成更多的任务，那么产品的功能性就越强。我们回顾一下，80年代末微软的MS_DOS版文字处理软件，该软件提供了很多很强的文字编辑功能，但是要求用户必须学习并记住很多神秘的按键才能完成任务。这样的软件可以说具有很高的功能性（提供给用户很多必要的功能），但易用性很低（用户必须花大量时间和精力去学习、使用它们）。

　　因此，如果给用户一个功能非常强大的程序，但却很难使用，那么用户将很可能会抵制它或者寻求其它替代物。所以，易用性测试是帮助开发人员确定用户能否容易地执行特定的任务，但是易用性测试并不能直接确定产品本身是否有价值或有功能。因此，要分清一件事物的两个方面，在分析的时候要避免将所有的问题都归结于易用性问题。

　　（3）没有正确理解发现、弄懂和效率

　　易用性有很多方面，包括发现、弄懂、效率等特征。发现是指涉及用户根据需求去查找软件产品的某项功能的难易程度，具体说就是用户找到某项功能需要花多长时间及用户在查找过程中会犯多少错误（如找错位置）。弄懂是指用户通过一个过程明白怎样使用某项已发现的功能，意思是说这个过程需要多长时间及用户学会这个功能会犯多少错误。效率则是指一个有经验的用户去使用某项功能需要多长时间。

　　（4）没有考虑应用的高效性和帮助指南

　　软件易用性还有一个，就是是否具有高效性和帮助指南。例如，是否有能加快速度的操作方法，例如快捷键，初级用户可以没有看到，但针对专业用户来说可以提高效率。因此，应该允许用户对常用的操作进行快捷设置，这样软件就能同时迎合无经验用户和经验丰富的用户的需要。最后，易用性还应该包括帮助指南，如帮助用户识别、诊断以及恢复错误。错误信息应该以简单的语言而非代码来表达，正确恰当地指出问题所在，并建设性地提供一个解决办法。