《网站设计解构》试读
1998 年，可用性专家 Rolf Molich①分别给 9 个团队 3 周的时间对 Web 邮箱 www.hotmail.com 进 行 评 估。 该 实 验 是 被 他 称 为 CUE（Comparative Usability Evaluations，相对可用性测试）系列实验②的一部分，试图建立起一套切实可行的可用性测试标准。在每一项测试中，Rolf 都会请多个可用性团队对同一个设计进行自由评估。
这次测试被称为 CUE-2，因为它是该系列实验中的第二项测试。在各团队记录下的结果中，反映出一个令人惊诧的趋势。
尽管可用性专家们在检测界面问题时宣称使用的方法非常科学，但是可用性评估本身却“并不十分科学”。
在 一 次 接 受 Christine Perfetti③（ 她 当 时 还 在 Jared 的 公 司 User Interface Engineering④即 UIE）的采访时，Rolf 谈起了自己的评估，说道：
CUE-2 的各团队总共提交了 310 个不同的可用性问题。提到次数最多的问题有 7 个团队提交。只有 6 个问题被超过半数的团队提交，而有 232 个问题（75%）只被提交了一次。许多标记为“严重”的问题都只有一个团队提交。即使是那些所有团队都测试过的常见任务，得到的结果也完全不同——这些任务中有 70% 左右的发现都是唯一的。
在 2003 年进行的 CUE-4（参见 http://www.dialogdesign.dk/Summary3.htm）中，共有 17 个团队被聘请对 www.hotelpenn.com⑤进行评估，该网站有一个基于 Flash 的酒店客房预定系统，由 iHotelier⑥开发 。在这 17 个团队中，9 个进行可用性测试，其余的 8 个进行专家评审。
所有团队共提交了 340 个可用性问题。然而，这些问题中只有 9 个被超过半数的团队提交。而且共有 205 个问题（占提交结果的 60%）只被发现过一次，其中又有 61 个被标记为“严重”或者“极为严重”的问题。
思考一下。
为了在评估过程中发现所有“严重”的可用性问题，Hotmail 项目聘请了9个可用性团队。而在 CUE-4 中，为了找出所有 61 个严重问题，Hotel Penn 则需要聘请 17 个可用性团队。17 个啊！在被问到开发团队如何确信已经准确标识出网站中存在的问题时，Rolf 总结道：
很简单：他们根本没法确定！
那么在今后创建可用性网站的过程中，可用性测试是否仍将扮演重要角色？ Rolf 继续解释道：
（我们）应该主要在项目的中期阶段使用它们，以此来增进同事间的信任。然后应采取其他更合算且有效的预防措施，例如为界面进行高可用性的模块化分组，以成熟的标准和准则为基础进行评审，以及情境式调查⑦。
我们认为 Rolf 的回答并不完整。首先，为了判断你是否在解决最重要的问题——解决这些问题可以让我们获得最大的收益，可用性测试也许并不比一位专家或者一位评估人员执行的启发式评估⑧来得更为准确或可靠，但可用性测试可以而且确实已经为我们理解人们的网络交互行为提供了巨大的帮助，它仍然应当被视为一种必不可少的工具。
其次，任何评估或观测的方法都应当被放在上下文情境中分析。“页面浏览量”和“平均页面花费时间”这两个指标都曾经被视为判断网站效率高低的衡量标准，但它们必须结合被访问页面自身的目标来考虑，否则就毫无意义。一个用户访问了一系列的页面，这种举动是因为任务流程很有效呢，还是因为他根本找不到想要的内容？用户在某个页面上花费了大量的时间，是因为他们很感兴趣呢，还是因为遇到了困难？ NYTimes.com（纽约时报的网站）无疑希望读者能在网页上逗留足够长的时间，阅读整篇文章或者浏览所有的标题，但Google 的目标却是让用户能在搜索页面中尽快找到需要的内容，然后绝尘而去。较长的“花费时间”在 NYTimes.com 上可能预示着一篇高质量的文章，而在 Google.com 上却可能预示着开发团队一次重大的失误。
不管怎样，可用性评估无法告诉设计师怎样才能做出好的设计，它只能帮助我们发现已有设计中存在的问题。从这一点来看，下面这段 Rolf 的陈述颇能引起我们的共鸣：
我希望有一天我们能拥有庞大的资源库，里面存放着经过现实用户的周详测试而且证明可用的通用界面模块（building block）。我还希望我们能向大家展示，由可用性专家把这些模块组装成完全成熟的网站，从而高效地生产出大量具有极高可用性的网站。
庞大的资源库。界面模块。周详的测试。
如果你正在疑惑 Rolf 的故事和手中的这本书有什么关系，上面这三个词已经包含了答案。 这是一本关于模块的书。这里没有原理，没有概念，没有代码，只有模块。
本书的第一个目标是近距离地观摩这些界面模块——认出它们，剥离它们，分析它们的功能以及工作原理。只有通过这些，身为设计师的我们才能将它们“组装成完全成熟的网站”并且创造出“极高可用性”。
但这只是第一步，我们还有其他的一些目标。准确地说，我们希望本书能够解决在每个 Web 项目中都反复出现的三种问题。
首先，我们对一个应用程序目标的理解是高层面的，而要想把它转化为低层面的设计细节，这个过程可能会非常艰难。这就好像拿走你的魔杖，绑住一只手，然后要你把蒸汽变成石头一样。在整个过程中，弄明白从哪里开始可能是最困难的一步，而即使你认为一切都已搞定，也很难确保不会有任何遗漏。当你忙着迎合业务目标的时候，又如何能保证自己完全满足了用户的需求呢？1
其次是标准与创新的问题。在绝大多数情况下，标准就意味着无趣。我们也许都会同意，在设计项目中最大快人心的部分就是凭空创造出一个前人尚未想到的解决办法。这种时刻非常令人兴奋——心如撞鹿、肾上腺素急速上升。但是大部分项目中，这种情况非常罕见。这是因为，即使是最具创新精神的项目，能称得上“前所未见”的地方可能也只占整个项目的 20%，其余都是基于标准的支撑功能。这些工作不会让我们心如撞鹿、肾上腺素急速上升——它们只是“苦力活”，是每个项目都必须要做的一部分。也正因为如此，我们往往不太重视它们。
比如说，此刻某个团队正在创建一个新的设计，里面包含了某些令人惊叹、前所未见的功能。但要想运用这些突破性的成果，用户需要先注册并登录。
注册功能并不新颖，并不会让人激动，对开发也没有太多挑战。但是无数团队都不得不一而再、再而三地设计这个功能，就好像之前从未创建过一样。这使得设计“注册”的工作非常枯燥乏味，但是忽视它却会给开发者带来很大的麻烦。因为它不是项目中最“帅”的部分，所以往往得不到重视，结果却可能给用户带来难以使用的挫折体验，甚至造成公司在收入上的损失。
而另一方面，创新也可能会产生问题。如果你已经致力于可用性界面设计一段时间了，你可能会和我们注意到同样的事情：可用性和创新常常会互斥。酷和易用有时候是一对欢喜冤家。
Live.com⑨在它首次发布的时候就遇到了这种麻烦，其中使用了一种有争议的无限滚动设计模式。开发者的本意是，如果用户希望查看更多搜索结果，这个方案将为他们省去被迫翻页、等待载入新页面的麻烦，而可以直接在单个页面中即时载入后续的搜索结果，这样当用户往下滚动页面时就能随时看到新的内容。然而，实际的结果并不如人所愿。用户们并不熟悉这一变化，因此当他们发现这个页面似乎永远也拉不到头时，很容易就会产生挫折感，而且很快就会厌恶这一创意。一句话，他们觉得它的表现不像 Google。无限长的页面滚动可能确实很酷，但是它对用户来说太莫名其妙，因此完全没有达到预期的效果⑩。（第 4 章详细讲述了这个故事。）1
每个人都渴望自己的产品能在市场上引起轰动，这需要我们创造出光芒四射的界面，但不能因此而牺牲可用性。要想做好这一点可能非常困难。当我们打破陈规时，实际上是在冒险，因为很可能用户根本无法理解我们设计出的界面。框架体系为我们提供了一种方法，把无趣的支撑功能进行标准化，这样就能避免重复开发，从而有更多的时间进行真正的发明创造。
最后是“低成本、高回报”的问题。Web 开发的团队越来越精简（很多团队的规模都只有 10 年前的一半），但公司对每个团队的期望却越来越多。与此同时，项目也变得比以往更为精密和复杂。为了节省时间和精力，开发团队必须开始考虑使用以前曾经完成过的功能。就像我们之前所说的，开发者不得不反复设计注册功能，就好像之前从未曾创建过一样。它确实被创建过（全世界的开发者都在往自己的产品里添加注册功能，估计已经不下数百万次了），但尽管它就在那里，却仍然要从头再来一遍。所有这些重复创造、重复开发的工作导致效率极为低下。为了降低在这方面耗费的精力（并且给刺激、有趣的创新部分留下更充裕的时间），开发团队需要可重复利用的设计。
重用是如今最应该优先考虑的事。
————————————
①Rolf Molich 于 1984 年投身于可用性方面的研究，1993 年在丹麦创立了可用性咨询公司DialogDesign。 他 同 时 也 在 Nielsen Norman Group（ 由 Donald Norman、Jakob Nielsen 和Bruce Tognazzini 三位著名用户体验专家创办的可用性咨询公司）的大型可用性测试项目中担任首席研究员。Rolf Molich 也是“启发式评估法”的发明人之一（另一位发明人是Jakob Nielsen），并著有 User Friendly Computer Systems（《用户友好的计算机系统》）一书，英文版本名为 Usable Web Design（《易用网页的设计》）。——译者注（以下未特别说明的均为译者注）
②该实验包含了 7 项研究案例（CUE-1 至 CUE-7），聘请了 60 多个专业可用性团队为同一个应用程序进行测试或评估。
③Christine Perfetti 是一位颇受欢迎的讲师和技术指导，经常出席世界各地的会议并且是最受欢迎的发言人之一。她曾任 UIE 公司副总裁兼行政董事，后自己创办 Perfetti Media。
④User Interface Engineering（用户界面工程）是一家专注于网站和产品可用性方面的咨询培训公司，由资深用户体验专家 Jared M. Spool（也就是本书的第二作者）于 1988 年创立。公司网站是 http://www.uie.com/。
⑤www.hotelpenn.com 是宾夕法尼亚酒店的网站。宾夕法尼亚酒店是世界上最著名的酒店之一，总部位于纽约曼哈顿核心区。
⑥iHotelier 现已更名为 TravelCLICK。这家 1989 年创立的公司专为宾馆及酒店提供一站式电子商务解决方案，在全球 140 多个国家拥有 15000 多位客户。网址为 http://www.travelclick.net/。
⑦情境式调查（Contextual Inquiry）是一种以用户为中心的设计方法（User-Centered Design，UCD）。它要求研究者在自然情境下旁观研究对象的实际工作，并记录下详细的信息。在该过程中，研究者应避免影响到研究对象的日常工作环境。研究者试图通过这种观察和讨论帮助他们设计出能协助、缩短甚至削减用户工作流程的产品。
⑧启发式评估法（Heuristic Evaluation Method）的发明人正是 Rolf Molich 和 Jakob Nielsen。它是一种“打折”的可用性观测方法，用于在计算机软件中标识用户界面设计方面的问题。观测者依据已经过证实的可用性原则（启发式方法）对界面执行的交互进行评估。这种评估方式如今被广泛应用于新媒体领域，尤其适用于需要在短期内设计出用户界面，或者由于预算金额的限制无法进行其他界面测试的情况。
⑨Live.com 本是 Windows Live Personalized Experience（Windows Live 个性化体验）的用户自定义门户，由微软于 2005 年 11 月发布。它是最初发布的 Windows Live 服务之一。但是随着微软的战略调整，Live.com 被My.Live.com 所取代，而原来的域名 Live.com 则指向了搜索引擎 Bing（取代了之前的 Live Search）。因此，作者文中所提到的 Live.com 实际上指的是 2009 年 6 月首次发布的 Bing。
⑩如今的 Bing 图片搜索仍然采用了无限滚动的交互方式。不过所谓的“无限滚动”仍然是有限的：无论搜索到多少结果，Bing 最多显示前 1 000 个，而且不提供翻页功能。
这次测试被称为 CUE-2，因为它是该系列实验中的第二项测试。在各团队记录下的结果中，反映出一个令人惊诧的趋势。
尽管可用性专家们在检测界面问题时宣称使用的方法非常科学，但是可用性评估本身却“并不十分科学”。
在 一 次 接 受 Christine Perfetti③（ 她 当 时 还 在 Jared 的 公 司 User Interface Engineering④即 UIE）的采访时，Rolf 谈起了自己的评估，说道：
CUE-2 的各团队总共提交了 310 个不同的可用性问题。提到次数最多的问题有 7 个团队提交。只有 6 个问题被超过半数的团队提交，而有 232 个问题（75%）只被提交了一次。许多标记为“严重”的问题都只有一个团队提交。即使是那些所有团队都测试过的常见任务，得到的结果也完全不同——这些任务中有 70% 左右的发现都是唯一的。
在 2003 年进行的 CUE-4（参见 http://www.dialogdesign.dk/Summary3.htm）中，共有 17 个团队被聘请对 www.hotelpenn.com⑤进行评估，该网站有一个基于 Flash 的酒店客房预定系统，由 iHotelier⑥开发 。在这 17 个团队中，9 个进行可用性测试，其余的 8 个进行专家评审。
所有团队共提交了 340 个可用性问题。然而，这些问题中只有 9 个被超过半数的团队提交。而且共有 205 个问题（占提交结果的 60%）只被发现过一次，其中又有 61 个被标记为“严重”或者“极为严重”的问题。
思考一下。
为了在评估过程中发现所有“严重”的可用性问题，Hotmail 项目聘请了9个可用性团队。而在 CUE-4 中，为了找出所有 61 个严重问题，Hotel Penn 则需要聘请 17 个可用性团队。17 个啊！在被问到开发团队如何确信已经准确标识出网站中存在的问题时，Rolf 总结道：
很简单：他们根本没法确定！
那么在今后创建可用性网站的过程中，可用性测试是否仍将扮演重要角色？ Rolf 继续解释道：
（我们）应该主要在项目的中期阶段使用它们，以此来增进同事间的信任。然后应采取其他更合算且有效的预防措施，例如为界面进行高可用性的模块化分组，以成熟的标准和准则为基础进行评审，以及情境式调查⑦。
我们认为 Rolf 的回答并不完整。首先，为了判断你是否在解决最重要的问题——解决这些问题可以让我们获得最大的收益，可用性测试也许并不比一位专家或者一位评估人员执行的启发式评估⑧来得更为准确或可靠，但可用性测试可以而且确实已经为我们理解人们的网络交互行为提供了巨大的帮助，它仍然应当被视为一种必不可少的工具。
其次，任何评估或观测的方法都应当被放在上下文情境中分析。“页面浏览量”和“平均页面花费时间”这两个指标都曾经被视为判断网站效率高低的衡量标准，但它们必须结合被访问页面自身的目标来考虑，否则就毫无意义。一个用户访问了一系列的页面，这种举动是因为任务流程很有效呢，还是因为他根本找不到想要的内容？用户在某个页面上花费了大量的时间，是因为他们很感兴趣呢，还是因为遇到了困难？ NYTimes.com（纽约时报的网站）无疑希望读者能在网页上逗留足够长的时间，阅读整篇文章或者浏览所有的标题，但Google 的目标却是让用户能在搜索页面中尽快找到需要的内容，然后绝尘而去。较长的“花费时间”在 NYTimes.com 上可能预示着一篇高质量的文章，而在 Google.com 上却可能预示着开发团队一次重大的失误。
不管怎样，可用性评估无法告诉设计师怎样才能做出好的设计，它只能帮助我们发现已有设计中存在的问题。从这一点来看，下面这段 Rolf 的陈述颇能引起我们的共鸣：
我希望有一天我们能拥有庞大的资源库，里面存放着经过现实用户的周详测试而且证明可用的通用界面模块（building block）。我还希望我们能向大家展示，由可用性专家把这些模块组装成完全成熟的网站，从而高效地生产出大量具有极高可用性的网站。
庞大的资源库。界面模块。周详的测试。
如果你正在疑惑 Rolf 的故事和手中的这本书有什么关系，上面这三个词已经包含了答案。 这是一本关于模块的书。这里没有原理，没有概念，没有代码，只有模块。
本书的第一个目标是近距离地观摩这些界面模块——认出它们，剥离它们，分析它们的功能以及工作原理。只有通过这些，身为设计师的我们才能将它们“组装成完全成熟的网站”并且创造出“极高可用性”。
但这只是第一步，我们还有其他的一些目标。准确地说，我们希望本书能够解决在每个 Web 项目中都反复出现的三种问题。
首先，我们对一个应用程序目标的理解是高层面的，而要想把它转化为低层面的设计细节，这个过程可能会非常艰难。这就好像拿走你的魔杖，绑住一只手，然后要你把蒸汽变成石头一样。在整个过程中，弄明白从哪里开始可能是最困难的一步，而即使你认为一切都已搞定，也很难确保不会有任何遗漏。当你忙着迎合业务目标的时候，又如何能保证自己完全满足了用户的需求呢？1
其次是标准与创新的问题。在绝大多数情况下，标准就意味着无趣。我们也许都会同意，在设计项目中最大快人心的部分就是凭空创造出一个前人尚未想到的解决办法。这种时刻非常令人兴奋——心如撞鹿、肾上腺素急速上升。但是大部分项目中，这种情况非常罕见。这是因为，即使是最具创新精神的项目，能称得上“前所未见”的地方可能也只占整个项目的 20%，其余都是基于标准的支撑功能。这些工作不会让我们心如撞鹿、肾上腺素急速上升——它们只是“苦力活”，是每个项目都必须要做的一部分。也正因为如此，我们往往不太重视它们。
比如说，此刻某个团队正在创建一个新的设计，里面包含了某些令人惊叹、前所未见的功能。但要想运用这些突破性的成果，用户需要先注册并登录。
注册功能并不新颖，并不会让人激动，对开发也没有太多挑战。但是无数团队都不得不一而再、再而三地设计这个功能，就好像之前从未创建过一样。这使得设计“注册”的工作非常枯燥乏味，但是忽视它却会给开发者带来很大的麻烦。因为它不是项目中最“帅”的部分，所以往往得不到重视，结果却可能给用户带来难以使用的挫折体验，甚至造成公司在收入上的损失。
而另一方面，创新也可能会产生问题。如果你已经致力于可用性界面设计一段时间了，你可能会和我们注意到同样的事情：可用性和创新常常会互斥。酷和易用有时候是一对欢喜冤家。
Live.com⑨在它首次发布的时候就遇到了这种麻烦，其中使用了一种有争议的无限滚动设计模式。开发者的本意是，如果用户希望查看更多搜索结果，这个方案将为他们省去被迫翻页、等待载入新页面的麻烦，而可以直接在单个页面中即时载入后续的搜索结果，这样当用户往下滚动页面时就能随时看到新的内容。然而，实际的结果并不如人所愿。用户们并不熟悉这一变化，因此当他们发现这个页面似乎永远也拉不到头时，很容易就会产生挫折感，而且很快就会厌恶这一创意。一句话，他们觉得它的表现不像 Google。无限长的页面滚动可能确实很酷，但是它对用户来说太莫名其妙，因此完全没有达到预期的效果⑩。（第 4 章详细讲述了这个故事。）1
每个人都渴望自己的产品能在市场上引起轰动，这需要我们创造出光芒四射的界面，但不能因此而牺牲可用性。要想做好这一点可能非常困难。当我们打破陈规时，实际上是在冒险，因为很可能用户根本无法理解我们设计出的界面。框架体系为我们提供了一种方法，把无趣的支撑功能进行标准化，这样就能避免重复开发，从而有更多的时间进行真正的发明创造。
最后是“低成本、高回报”的问题。Web 开发的团队越来越精简（很多团队的规模都只有 10 年前的一半），但公司对每个团队的期望却越来越多。与此同时，项目也变得比以往更为精密和复杂。为了节省时间和精力，开发团队必须开始考虑使用以前曾经完成过的功能。就像我们之前所说的，开发者不得不反复设计注册功能，就好像之前从未曾创建过一样。它确实被创建过（全世界的开发者都在往自己的产品里添加注册功能，估计已经不下数百万次了），但尽管它就在那里，却仍然要从头再来一遍。所有这些重复创造、重复开发的工作导致效率极为低下。为了降低在这方面耗费的精力（并且给刺激、有趣的创新部分留下更充裕的时间），开发团队需要可重复利用的设计。
重用是如今最应该优先考虑的事。
————————————
①Rolf Molich 于 1984 年投身于可用性方面的研究，1993 年在丹麦创立了可用性咨询公司DialogDesign。 他 同 时 也 在 Nielsen Norman Group（ 由 Donald Norman、Jakob Nielsen 和Bruce Tognazzini 三位著名用户体验专家创办的可用性咨询公司）的大型可用性测试项目中担任首席研究员。Rolf Molich 也是“启发式评估法”的发明人之一（另一位发明人是Jakob Nielsen），并著有 User Friendly Computer Systems（《用户友好的计算机系统》）一书，英文版本名为 Usable Web Design（《易用网页的设计》）。——译者注（以下未特别说明的均为译者注）
②该实验包含了 7 项研究案例（CUE-1 至 CUE-7），聘请了 60 多个专业可用性团队为同一个应用程序进行测试或评估。
③Christine Perfetti 是一位颇受欢迎的讲师和技术指导，经常出席世界各地的会议并且是最受欢迎的发言人之一。她曾任 UIE 公司副总裁兼行政董事，后自己创办 Perfetti Media。
④User Interface Engineering（用户界面工程）是一家专注于网站和产品可用性方面的咨询培训公司，由资深用户体验专家 Jared M. Spool（也就是本书的第二作者）于 1988 年创立。公司网站是 http://www.uie.com/。
⑤www.hotelpenn.com 是宾夕法尼亚酒店的网站。宾夕法尼亚酒店是世界上最著名的酒店之一，总部位于纽约曼哈顿核心区。
⑥iHotelier 现已更名为 TravelCLICK。这家 1989 年创立的公司专为宾馆及酒店提供一站式电子商务解决方案，在全球 140 多个国家拥有 15000 多位客户。网址为 http://www.travelclick.net/。
⑦情境式调查（Contextual Inquiry）是一种以用户为中心的设计方法（User-Centered Design，UCD）。它要求研究者在自然情境下旁观研究对象的实际工作，并记录下详细的信息。在该过程中，研究者应避免影响到研究对象的日常工作环境。研究者试图通过这种观察和讨论帮助他们设计出能协助、缩短甚至削减用户工作流程的产品。
⑧启发式评估法（Heuristic Evaluation Method）的发明人正是 Rolf Molich 和 Jakob Nielsen。它是一种“打折”的可用性观测方法，用于在计算机软件中标识用户界面设计方面的问题。观测者依据已经过证实的可用性原则（启发式方法）对界面执行的交互进行评估。这种评估方式如今被广泛应用于新媒体领域，尤其适用于需要在短期内设计出用户界面，或者由于预算金额的限制无法进行其他界面测试的情况。
⑨Live.com 本是 Windows Live Personalized Experience（Windows Live 个性化体验）的用户自定义门户，由微软于 2005 年 11 月发布。它是最初发布的 Windows Live 服务之一。但是随着微软的战略调整，Live.com 被My.Live.com 所取代，而原来的域名 Live.com 则指向了搜索引擎 Bing（取代了之前的 Live Search）。因此，作者文中所提到的 Live.com 实际上指的是 2009 年 6 月首次发布的 Bing。
⑩如今的 Bing 图片搜索仍然采用了无限滚动的交互方式。不过所谓的“无限滚动”仍然是有限的：无论搜索到多少结果，Bing 最多显示前 1 000 个，而且不提供翻页功能。