“知己知彼，百战不殆”，这句话时常用在描述竞争对手上，而在微软，他们把大量的时间花在了解用户上，微软产品的用户或对手产品的用户，他们都了解。

微软针对不同场合制定了一系列研究用户的机制。这些研究包括对用户行为和该领域内产品的分析，以及开发期间的产品特性测试——换句话说，即可用性实验室分析。微软每年支出50万美元，就产品支持服务和客户满意度作市场研究。一个主要项目是每年一次的最终用户满意度测量调查，由一家外部调研公司为微软作的，旨在通过鉴别为了获得并保住一个客户什么是必要条件从而衡量客户的满意度。这项调查覆盖面超过1000个用户，按微软的和非微软用户粗略分成两组。对微软客户的问题是要分析他们对微软产品、微软公司以及微软产品支持的满意程度。在上述三方面都满意、并且一定购买和推荐微软产品的用户被定为“可靠”客户。

调查还就微软与其竞争对手及各自产品和支持服务作了满意度水平的比较。数据表明，产品设计与客户支持和对公司总体满意的程度相关。正由于此，为Macintosh设计的产品——它有个更为简易的界面可用——在客户满意程度上就比视窗产品更高，虽然产品用起来并无差异。微软产品开发部经理特瑞希·梅说：客户满意度在与什么产品及该产品是怎么设计的之间有相当大的关系。例如，我们做了些交叉型表格，结果显示，如果某人对产品满意，那他们将会对服务也非常满意。如果你有一个交互作用的用户界面，那你一般会对服务更满意了。这里有着一点光环影响效应。

建立起固定的可用性实验室测试的主意，源于1989年和1990年间微软正在开发Excel 3．0的时候。一些开发员已在用典型用户测试典型产品。但是做的并无规律，微软也没有实验室设备来分析和收集数据。微软员工在回忆实验室的起源时说：可用性实验室的小组是从很少几个人起步的。他们是个服务性组织，试图对每种产品都帮上忙。在某种程度上，那里是真正的突破。如果你回到5年前，当我们开始搞可用性组时，该组总是对开发组说：“10个人中有6个不会这么做。”而开发组则反驳：“你们从哪儿找了那6个傻瓜?”所以我们就逐步让开发员们也去可用性实验室观察并参与进去。然后我们做出了工具版。再后来我们有了这么个主意，就是在他们开发特性时，找来6个、8个或10个可用性实验人员，让开发员就在中间巡走，和用户谈谈什么是能用的，什么是不行的。结果这成了开发员们严谨对待的一件事。”你已经对那个特性进行可用性测试了吗?有什么发现和启发?”他们认识到了自己和用户想的就是不太一样。

克里斯——1989年至1990年间Excel的开发经理——对实验室的产生和普及也有类似追忆。他强调，即使微软最好的开发员，要使特性易于使用，光有自己的那些常识还远远不够。而且，微软的开发员们在去可用性实验室看到用户与特性“奋力斗争”的事实之前是不会认识到自己的局限性的，从那以后，使用实验室成了家常便饭：我不记得确切是在哪天了。但开始是发生在开发Excel3．0那段日子。碰巧有些开发员在看可用性测验。要不是亲眼所见，你肯定不以为然，并且会立即有无数想法涌入脑海。首先，你会马上想到人的因素，常常有毫无益处的看法——“嗯，如果他们不知道怎么用，可以查用户手册嘛”或“我的点子很棒；只是你找了10个笨蛋才导致可用性实验室里的运行失灵”——一旦你亲眼见到了。这类观念便都不会产生了。

它是让你的产品更好些的有效途径。显然你能使产品更棒。人们经常认为凭借常识或聪明就能搞设计了。但是人们对软件作反应的方法复杂之极。我们最好的设计员，我想对任何人也都一样，只能做到60％是正确的。然后还需要第二次通过。在首次通过实验室测试后，正确率可达80％，到第三次通过时，已经能达到90％了。

要达到“60％正确”，指的是微软采用的衡量实验室结果的简单测量标准：没有参阅用户手册，第一次就正确完成了工作的人数；或者人们在首次试用就能正确无误的完成任务比重。举个例子，一个开发员可能让一些测试员输入一段课文，然后随便查找一个词，并用另一个单词予以自动替换，这个工作会涉及到“查找并替换”特性的好几个步骤。

为了减少成本，微软各项目一般会集中那些能一起运行的特性，同时进行测试，并且他们力图避免在实验室对特性的运行超过两次。像Excel和Word这些组，还尽量把实验室工作限制到每周两个半日集中处理，每次测试大约3个特性。然后实验室人员组会把报告送往开发员和程序经理处。被分配到某个特性组工作的程序经理，要和实验室工作组一起负责安排测试进度。梅普尔斯尽量也将实验室成本包括进来，把工作组限制在35人左右，实验大约有五六次。虽然梅普尔斯承认存在着创造多元化设施以供不同设计组利用的这种压力，可微软还是坚持只有一个中心实验室。

PSS的数据表明，实验室在使产品易于使用和易于支持方面收效显著。实际上，彼得斯把卖出的每“盒”产品的客户电话数减半之功归于了可用性实验室，他说：“没有人会很高兴打电话以获得产品支持。所以这是个两边受益结局的例证。你能做得这么好，以使他们用不着打电话，你成功了。而他们首先想到的也不是打电话，他们也赢了。”彼得斯还宣称实验室有助于防止程序经理和开发员添加太多不必要的和复杂的特性。在许多因软件产品及其要求储存空间的增加而受到过挫折的客户中，“特性的衍生”是令人忧虑的焦点：“我们想的是，利用可用性测试，我们能够确实增加更多的特性，并制造出越来越易于使用的产品。所以如果你做得对，我们并不认为特性的衍生会真的有用。这暗示着在能力和易于使用之间存在着一个平衡。只不过在这个行业中一直在灌输的是人们正像行政命令的加工人员一样开始做事儿，我们不能使产品造得便于使用，所以我们就要删除一些特性。这个方法就是可行性测试。