感谢 @wsedr‍ 的分享。原文点这里。

三年前我偶然看到微软员工肯特·苏利文（Kent Sullivan）的一篇很有意思的文章，讲的是开发 Windows 95 用户界面的过程与发现。载有这篇文章的网页已经无法打开（这也是我喜欢收集囤积此类内容的一大原因）。

文章中指出了在 Windows 3.1 程序管理器层（Program Manager shell，https://en.wikipedia.org/wiki/Program_Manager ）中出现的一些问题，并讨论了为电脑新手开发独立层级的可能性。按照我的理解，这也许是受到了苹果公司（Apple）在System 7 （https://en.wikipedia.org/wiki/System_7 ）时期的 At Ease 项目（https://en.wikipedia.org/wiki/At_Ease ）的启发。我仍清楚记得小学时为了让学生不会在在访达（Finder）中弄乱硬盘而使用 At Ease 的情景。

下文是肯特的文章原文，题为《Windows 95 用户界面：易用性设计》（The Windows 95 User Interface: A Case Study in Usability Engineering）。

摘要

为广泛使用的商业软件（如微软 Windows 95）设计用户界面是一项浩大的工程，需要众多参与者在广泛目标下进行紧张的工作。这篇设计简报主要描述了如何使用迭代设计中的易用性原则以及问题追踪来控制 UI 设计，并讨论了具体问题和其解决方案。

关键词

迭代设计（iterative design）；微软 Windows 操作系统；问题追踪；快速成型（rapid prototyping）；易用性设计（usability engineering）；易用性测试（usability testing）

前言

Windows 95 是对 Windows 3.1 和 Windows for Workgroups 3.11 操作系统的全面升级。 Windows 的方方面面几乎都进行了改动，用户界面也不例外。本文讨论了 Windows 95 的设计团队、设计目标和过程，并以具体问题和解决方案来说明易用性设计（如迭代设计与问题追踪）是如何得到应用的。

设计团队

Windows 95 的用户界面设计团队是在项目初期（1992年10月）成立的。我作为附属成员在1992年12月加入团队，主要为团队提供易用***（usability services）。团队成员的背景各异，集中了产品设计、平面设计、易用性测试以及 CS 领域的人才。参与项目界面设计的大约有12人，另外，开发用户界面的软件工程师也有12人左右。

设计目标

设计团队有以下两个广泛目标：

• 使操作系统对于刚接触电脑和 Windows 的人来说更容易学习。
• 使 Windows 3.1 的一般和高级用户更加方便地使用 Windows。

在当时，Windows 3.1 和 3.11 的装机量已经达到5000万，还要加上还未广泛涉及的家庭用户，很明显，设计一款更好的产品并非小事。如果产品的设计和测试没有经过仔细推敲，极有可能在提升一部分用户易用性的同时降低另一部分用户和潜在用户易用性。我们对高级用户的需求比较了解，但对于新手用户的需求知之甚少。

设计过程

目标很广泛，时间很紧张（大约只有18个月的时间来设计和编程），我们从一开始就明确了传统的“瀑布式”开发过程将会使我们无法高效地得到最佳解决方案，甚至可能得到完全无法使用的操作系统。

在“瀑布式”开发过程中，系统的设计被分割开来（通常还被限制在编写规范的程度），易用性测试也被放在设计末尾的品质保证过程中。我们明白，团队需要更多机会来进行设计，让用户进行测试并与其他设计做比较，作出改变，并收集更多用户反馈。幸运的是，我们放弃“瀑布式”开发转而使用迭代开发的想法，与公司内已经进行的其他项目不谋而合，使我们对于这种开发方式的可行性及优势可以有更加具体的了解。

迭代开发的实践

我们的开发过程如图 1 所示。与使用迭代开发的其他项目相同，使用纸面上或电脑里设计的原型在实验室里测试设计中的想法和易用性。当某个设计用代码实现之后，则交由易用性实验室进行提炼优化。当编程出的设计达到一定数量之后，会在实际情况下进行长时间的更加广泛的测试。测试中发现的易用性方面的小问题在产品下线前就要进行解决。更重要的是，测试中收集的数据也要被用于下个版本的开发过程中。

图 1. Windows 95 的迭代开发过程

我们的迭代设计主要分为三个阶段：探索阶段、快速成型阶段和精细调整阶段。

探索阶段

在这个阶段中我们对设计方向进行实验，并收集用户数据。我们使用 Cairo 团队的工作成果作为用户界面视觉设计的基础。我们继承了 Cairo 团队大部分基本 UI 和互动的设计（如“我的电脑”，任务栏，快捷菜单，3D外观等），并收集了用户关于 Windows 3.1 的前 20 大问题。

图 2 展示了我们在1993年1月进行了易用性测试的 Windows 95 操作系统原型。此原型基于 Cairo 团队的设计，并包含了对 Windows 3.1 一些已知问题的初步修复。

图 2. 早期 Windows 95 的桌面（放大图标以清晰展示）

顶端的 “文件柜（File Cabinet）” 图标继承了 Windows 3.1 风格（左侧显示其分级，右侧显示内容），中间的 “World” 图标显示网络上的内容，第三个图标 “程序（Program）” 是一个存有电脑上程序链接的文件夹。底部是任务栏，由三个按钮（系统、搜索和帮助）与文件存储位置组成。另一个图标，“回收站（Wastebasket）”用于存储被删除的文件。

此原型的易用性测试和之后的一系列测试由微软易用性实验室进行。我们进行了易用性的迭代研究，由三至四名代表不同领域的用户（通常是 Windows 3.1 的新手和高级用户）使用原型完成不同任务。我们在测试中提出的问题有时非常宽泛（如“用户是否喜欢此产品？”），有时非常具体（如“用户能否在短时间内学会拖拽和拷贝文件？”）。在测试中收集用于迭代研究的数据有：出声思维法记录，任务完成时间，错误数量，错误种类，用户评价等。

最初的发现

针对此原型的易用性测试发现了一些之前没有考虑到的问题：

• 新手用户对文件柜左右分栏的形式不理解（图 3），不知道两栏内容的关联及如何在文件夹之间跳转。新手用户常被文件柜的复杂性吓到，并对一些基本问题产生不理解（例如“文件夹内为何还有文件夹”）。许多用户不理解每一个文件夹中“上一级文件夹”按钮的存在，认为这看起来像是一个文件，实际上这是返回上一级文件夹的操作。

图 3. 早期系统中的“文件柜（File Cabinet）”

• 各类用户均对程序文件夹产生误解。我们之前认为在桌面上放置一个存有程序链接的文件夹能够让用户从 Windows 3.1 中的任务管理器进行自然过渡，并使新手也能更容易理解。很明显我们错了。新手用户很快就在文件夹中晕头转向（与文件柜不同，每个文件夹都要在新窗口中打开），其他用户则无法分辨文件与文件链接的区别。
• 由于功能存在重叠，用户很难分辨任务栏三个按钮（例如，需要查找帮助时，是使用“搜索”还是“帮助”？）。

与 Windows 3.1 的比较

基于最初的实验数据，我们明白需要基准来研究 Windows 95 之前存在的问题以及每个设计中存在的特定问题。首先，我们从市场调研中得到了 Windows 3.1 用户最常见的 20 个问题，之后针对这些问题对 Windows 95 和 Windows 3.1进行比较。我们也询问了教授 Windows 3.1 和 Macintosh 的教师，了解他们在教学里发现的系统中容易掌握和困难的地方。

发现的主要问题有：

• 在Windows 3.1 中，新手用户平均需要 9 分 30 秒以上才能找到并打开下级文件夹中的文件。Windows 95 原型的数据没有根本变化。这种结果是完全不能接受的，尤其是市场调研数据表示，用户反馈的的首要目标就是打开程序。
• 新手和一些一般用户很难使用鼠标操作，尤其是双击操作。只能双击打开文件夹时这个问题尤其突出。
• 新手和大部分一般用户完全依赖视觉提示来找到指令。他们从直觉上依靠菜单栏和工具栏，甚至在经过教学后仍然不会使用快捷菜单。
• 除了高级用户外，用户不知道如何有效操作重叠的窗口，尤其是当新手用户最小化窗口后，他们以为窗口已经被关闭。我们从教师口中及实验室观察中发现用户开启同一程序的多个副本使电脑内存占用过多的情况非常普遍，用户不知道如何切换到程序的另一个副本。一般用户的使用更加熟练，但是仍然存在问题，尤其是多文档界面（Multiple-Document-Interface，MDI），如程序管理器和 Word 软件的使用。市场调研显示，高达 40% 的一般用户出于不理解系统逻辑不会同时开启两个程序。
• 新手用户对文件夹层级不理解。一般用户能够理解文件夹层级，但通常情况下还是将文件保存在程序默认的文件夹中。这个问题在 Mac 用户群中也有出现。

改变设计方向

在研究和询问中发现的这些问题大大改变了 Windows 95 用户界面的设计。在最初的 Windows 95 原型中，我们有针对性地改变了 Windows 3.1 的某些特点（例如，将“我的电脑”变为一个文件夹）并将其他特点沿用（例如桌面上的文件管理器和程序管理器图标）以防止设计大幅度走偏。我们明白如果开发与 Windows 3.1 截然不同的产品将会吓倒众多用户，这显然是不能接受的。

然而，我们从 Windows 95 原型中得到的数据及与 Windows 3.1 的比较表明现在的设计思路无法继续。新手用户对基本任务的完成情况非常糟糕，一般用户也觉得 Windows 95 只是不同于 Windows 3.1 而没有任何进步。

接下来我们决定后退一步，花几天时间好好思考现状。设计团队在公司外的地点讨论了目前收集的数据：基准易用性研究、询问和采访、市场调研以及产品支持信息。在讨论中，我们意识到需要将重点放到用户最频繁的操作上。同时，我们也意识到现阶段之前过多考虑与 Windows 3.1 的继承性有些不妥。

最终，我们发现解决方案并不是设计一个类似 Windows 3.1 的产品，而应该对各层级用户在不同方面都能产生吸引。我们觉得易用的系统应该对不同人群的需求作出改变：新手用户能够更快学习并适应操作系统，操作系统也能对更有经验的用户提供高效的解决方案。

快速迭代阶段

在设计初期，我们希望通过将 UI 基础功能多样化来避免其进入“易学难用”的死胡同。为了达成这一目标，我们需要快速地尝试众多新想法，对它们进行比较，并将好的想法迭代下去。我们需要高效地进行设计和评估来完成这一过程。

改进 UI 设计规范

虽然我们在最初就明确使用迭代设计来开发用户界面，“瀑布式”开发的一个特点仍然被保留了下来：庞大的设计规范（“spec”）。在项目初期的几个月里，设计规范的体量快速**，反应了团队成员共数百小时的辛苦劳动。然而，通过用户测试中发现的数据，设计规范中的内容无法跟上进度。设计团队面临重大挑战：是花费数周时间修改设计规范以反映现状同时牺牲迭代时间；还是停止更新设计规范，转而让原型来反映实际的规范。

经过许多争论，设计团队决定采用后者。这一决定使得团队外的人员很难跟进我们的工作进度，但能够使我们以最快速度对产品进行迭代。这一改变也带来了意想不到的效果：团队成员需要建立更加紧密的联系，因为设计规范更多存在于口头表述和白板上的草稿中。在项目进行期间，设计团队越来越多在走廊上进行讨论。

为了让各方能够对我们的项目有更好的了解，我们进行了以下工作：

1. 设计团队定期开会。每周（有时更加频繁）的会议上我们讨论自己所做的工作进度，以及对他人工作进度的影响。
2. 通过电子邮件发送易用性实验安排和结果。设计团队成员会定时收到过往易用性实验的数据和今后易用性实验的安排，让每个人都能够了解当前版本易用性的信息，并能够更好了解项目的走向。
3. 严肃追踪易用性问题。如 Windows 95 体量的项目，设计团队需要一种标准化的过程来了解目前发现的易用性上的问题，记录这些问题出现和解决的时间，并在问题交由用户测试确定解决后关闭。这个程序将在下文“追踪现有问题”部分继续讨论。
4. 对团队外人员提供定期的 Presentation。在项目进行过程中，越来越多的团队（微软公司内外的团队都有）希望了解我们的工作，我们则向他们展示工作成果。这些展示比纸面文本更加高效，并且能够更加实时地反映工作进展。

为新手用户设计 UI

我们研究的第一个思路是为新手用户设计独立的 UI。原型很快用 Visual Basic 语言写出，并交由易用性实验室进行测试（图 4）。由于 UI 将用户的操作限制在较小的范围内，测试结果非常乐观，但我们很快在涉及更多用户的测试中发现了问题：

• 如果新手 UI 不支持某个功能，用户将会放弃这个操作（至少是暂时放弃）。
• 假设用户经验增长后想要停止使用新手 UI，他们在新手 UI 中学到的操作有时不能过渡到普通 UI 中。
• 新手 UI 与正常运行的程序之间存在差别（例如文本处理和电子表格程序），造成用户需要学习两种不同的操作方式，有时会使用户困惑。

图 4. 新手 UI 中的部分图标与文件层级展示

由于存在这些问题，我们将开发新手 UI 的想法摒弃了。由于我们的原型能够立即送交易用性实验室进行测试，这一问题上的耽搁并不影响我们对其他设计方向的研究与尝试。

快速迭代的一些实例

下面是我们设计并迭代三次以上的五个方面。除此之外还有许多实例，为了精简并不在此赘述。

1. 用开始菜单打开程序。虽然摒弃了新手 UI 的想法，我们将其最实用的特点继承下来：单击打开，明显的视觉提示，以及基于菜单的互动模式。我们使用 VB 编写了一系列实例，并让经验各异的用户进行测试，以使得 UI 能够使拥有不同经验的人都获得较好的体验，而非仅仅针对新手。图 5 中是最终版本的开始菜单，并展示了打开第二层菜单的场景。最终版本的开始菜单的功能是让用户在打开程序之外获得在 UI 一键即达的体验。
2. 窗口管理和任务栏。由于不知道需要投入多少工作，我们最初对窗口管理的设计并不激进。我们的首要工作是将最小化的窗口示意由图标改为托盘（见图 6）。我们希望为最小化的窗口设计更大而且不一样的图标来解决这个问题。这个想法之后被证明是错误的，用户体验的困难与 Windows 3.1 没有什么区别。实验数据表明，问题的根本在于最小化的窗口并不总能被看到，用户无法确定当前打开的窗口，也就无法快速切换。发现了问题之后团队快速修改了任务栏（图 7）。每个任务在任务栏内都有独立的显示，并且任务栏总显示在窗口前方。用户的测试表明这就是问题的解决方案。
3. 文件操作：“打开”和“另存为”。产品支持信息和实验室数据表明，新手和一般用户很难通过系统提供的对话来打开或者保存文件（图 8）。问题的出现是因为对话框的出现没有逻辑，选择操作也非常复杂。Cairo 团队使用 VB 编写了一个袋有文件系统的原型。在我们确定最终版本（图 9）之前，对许多设计版本进行了测试。
4. 打印：安装程序（Setup Wizard）。产品支持提供的信息表明打印机的安装和调试是用户面临的最大问题，Windows 3.1 的打印机设置界面对用户产生了很多困扰（图 10）。首先，找到打印机很困难，因为所有设备都在同一列表中。选择打印机接口，尤其是在网络环境中，需要用户进入4～5层菜单，并进行非常规的复杂选择操作。当我们开始着手研究这个问题时，设计团队开始利用安装程序来进行多步骤，不需要频繁进行的操作。打印机设置正好符合这一特点，安装程序的测试非常顺利。最终的安装程序中打印机选择界面如图 11 所示。
5. 寻找帮助：搜索文本/目录栏。实验数据显示 Windows 3.1 的用户在“帮助”菜单中搜索遇到了很大问题（图 12）。用户并不能很好理解对话的结构需要先打开一层列表再点击另一个按钮打开二层列表。我们在开发出最终的目录栏之前有过多次尝试（图 13）。目录栏只有一个列表，符合关键词的多个项目能够让用户无障碍地看到。

精细调整阶段

当我们已经设计了 UI 的大部分功能时，设计团队意识到需要放慢脚步，看看各个部分的组合是否恰当。我们进行了汇总性的实验，并进行了大规模的田野调查。

• 汇总性实验。针对市场调研的 20 个问题，团队对 UI 进行了全面的实验。让不同经验水平的用户完成同一件工作，来研究用户的学习时间以及学会后的使用熟练程度。我们将 UI 与 Windows 3.1 进行比较，并且在公司内的实验结束后，我们让第三方重复了同样的实验，使我们的结果能够写进白皮书中 [3]。实验结果非常乐观：用户完成任务的时间比在 Windows 3.1 中缩短了一半，在调查的 21 个方面中，有 20 个方面用户认为 Windows 95 更胜一筹。
• 大规模的田野调查。我们使用 Windows 95 的最终测试版对 20 位用户进行了调查。首先我们记录用户使用 Windows 3.1 的情况，之后观察他们设置 Windows 95。我们在一周和一个月后分别记录用户的使用情况。此时并没有发现产品的大纰漏，不过我们确实优化了 UI 中和帮助菜单里的一些表述。我们收集的一些数据交给产品研发人员以用于今后版本 Windows 的开发，也交给产品支持人员以改进售后效率。

追踪现有问题

在设计与测试 Windows 95 的整个过程中，我们遵循易用性设计的原则进行了许多实践 [2] [4]。我们明白，做一个 Windows 95 这样大体量的项目，需要有标准化的程序来记录发现的问题，解决问题的方法和时间，以及及时在阿用户测试表明问题已经解决后将问题关闭。

为了满足这种需求，我们建立了一个数据库（图 14）。在实验室测试的每一个阶段之后，我负责向数据库输入当前发现的产品的优点和问题，并有针对性地将这些问题分配给专门的人员（通常是设计师与用户指导人员的合作小组）。同时，数据库中的现有问题也要进行更新：如果还需要解决，就保持问题开放；如果已经解决，就关闭问题。每隔几周我会写出一份报告，列举出各人手头的问题，并将这份报告交给设计团队的每个成员（图 15）。之后我们会开会讨论问题解决情况，并对下一设计的测试时间进行预计。

图 14. 问题追踪数据库示例

图 15. 问题追踪报告示例

测试报告

与任何项目一样，可行性只有经过实际测试才有意义。因此有必要在这里列出一些归纳性数据。

实验室测试

我们在实验室中进行了 64 个阶段的实验，总共涉及 560 个对象。50% 的用户是 Windiws 3.1 的一般使用者，其余为新手用户、高级用户及使用其他操作系统的用户。此数据不包含由其他团队进行的测试（如参与收发邮件、传真等），其他团队进行的测试约有 25 个阶段，涉及 175 名用户。

寻找问题

在核心层级方面，数据库内总共收录了 699 条“易用性表述（usability statements）”，其中有 148 条发现的优点，其余 551 条为发现的问题。问题被分作不同等级：

• 一级。用户遇到此类问题时无法完成一项或多项任务。
• 二级。用户在完成一项或多项任务时遇到问题，但最终能够解决。
• 三级。用户在完成一项或多项任务时没有遇到太大问题。

在 551 个问题中，有15% 属于一级问题，43% 属于二级问题，42% 属于三级问题。

解决问题

在项目过程中，问题共有五种解决状态：

• 已解决（Addressed）：团队已经解决这个问题，并已经通过用户测试。
• 计划中（Planned）：团队已经提出解决方案，但解决方法仍需要具体化。
• 悬而未决（Undecided）：团队不确定是否要解决这个问题，或不确定是否有解决这个问题的可能性。
• 未定（Somewhat）：团队设计的解决方案经过测试仍有一些小问题。
• 不解决（Not Addressed）：团队不打算解决这个问题。

在项目收尾时期，“计划中“和“悬而未决”的问题被转移到其它分类下。有 81% 的问题被标注“已解决”，8% 被标注“未定”， 11% 被标注“不解决”。不解决的问题大多数是受到技术限制或时间安排限制无法解决。

结论

Windows 95 项目是设计团队中许多人接触的第一个迭代设计项目，许多人也是第一次进行易用性测试与问题追踪。

迭代设计

对我们迭代设计最好的诠释，是 Windows 95 最终产品的所有细节都与初版不同。在开发初期，所有人都没有料到需要改进的问题的范围与数量是如此之大。利用原型设计作为设计规范，并频繁进行用户测试，是我们能够快速提出多种解决方法的前提。

设计团队对迭代设计的熟悉程度非常高，以至于项目收尾时期我们常常要进行许多临时工作。有时由于时间限制甚至只能进行一次迭代。对此，我们表示很遗憾由于时间限制不能对产品进行更精细的调整和测试。

规范过程

“原型或代码即规范”这一方式起了很大作用，不过我们仍然进行了这一过程的优化。例如，某一发行版的各个原型都被记录下来，并包含了安装与运行说明。

设计团队编写了初期规范，并依靠它们来得到早期的反馈。当原型设计与易用性测试开始后，规范常常需要读者到原型中寻找细节。我们发现，原型其实是内容更加丰富的规范，并且由于能够作为它用（易用性测试、demo等），常常事半功倍。原型由于可以让读者更加直观地了解系统，通常也能够得到更多的反馈。

易用性测试

诚然，在产品的不同方面利用迭代的方法进行设计和用户测试让我们获得了各个方面的产品特性，但是让用户完整地测试产品也是将产品各部分有机结合的关键。如上文所述，我们根据收集到的数据优化了 UI 和帮助菜单里的文字表述。如果我们没有进行完整性的测试的话，用户的体验将不会如此高效并愉悦。

问题追踪

离开了团队成员紧张的配合，易用性问题将无法得到快速解决。用于追踪的数据库让这一过程变得更加可控，也保证了问题不会被无意中搁置。然而，离开了团队成员要将 Windiws 95 打造成市场上最好用的操作系统这一信念，问题同样不会得到有效解决。这种信念的关键在于，我们明白自己也许无法在第一次尝试时就解决问题，但这一过程中的不断试错能够与问题的解决给予我们同等重要的信息。

在数据库中，被标注为“未定”或“不解决”的问题被继承到新的数据库汇总，作为下一个版本 Windows 开发的垫脚石。产品策划和设计人员每天都对这些信息进行处理，产品支持人员也针对这些信息的处理写出报告。

致谢

感谢简·戴利（Jane Daily）、克里斯·古扎克（Chris Guzak）、法兰西斯·霍格（Francis Hogle）、马歇尔·麦克科林托克（Marshall McClintock）马克·马拉穆德（Mark Malamud）、苏珊·马拉希（Suzan Marashi）和马克·辛普森（Mark Simpson）对本文进行审读指正。同时，感谢劳伦·盖勒格（Lauren Gallagher）、肖娜·桑德诺（Shawna Sandeno）和詹妮弗·夏特利（Jennifer Shetterly）在平面设计方面提供的帮助。

参考文献

[1] Dumas, J. S. and Redish, J. C. (1993). A Practical Guide to Usability Testing (pp. 324-325). Norwood, NJ: Ablex Publishing Company.

[2] Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.

[3] Usability Sciences Corporation. (1994). Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity. (Available from http://www.microsoft.com/windows/product/usability.htm)【译者注：微软易用性页面已改为https://www.microsoft.com/usability/】

[4] Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction (pp. 791-817). Amsterdam: Elsevier Science Publishers, B. V.

[5] Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.