如何创建一个信息构架

假设到目前为止，我们之前谈论过的所有事情你都全部完成了。你心里清楚你要为你的客户或者业务取得什么成果。你也了解你的用户、他们的需求以及他们获取你信息的方式，并且，你知道你的内容是关于什么的。

此外，你还掌握了许多关于分组、分类机制、信息构架模式以及标签的知识。

知道吗?是时候开始为你的网站创建信息构架了。(你可能会说：“终于!”)

这同时也是整个过程中最恐怖的一个部分。现在，你需要去创造些东西。

接下来你完成这个步骤的方式方法取决于你是如何工作和思考的。(不同的人之前会有微小的差异。)

如果你喜欢严格按照步骤来做事——这一步引入下一步的模式——你可能会好奇该“如何”从你之前收集到的这些信息里创造出一个理想的信息构架。不好意思，这一步不是线性的(而且你可能还记得我们在第10章里讨论的，永远不会有完美的结果)。而如果你喜欢那种让你心里对于如何获得一个结果结论比较有谱的线性过程，这里你也将会遭遇一些困难。

但是，如果你是一个更加依靠直觉并且有创造力的人，这一步会显得比较简单。跨出那创造性的一步，把所有信息整合进全新的信息构架，这些将让你觉得非常舒服。你很有可能会觉得这步相当容易(前提是你已经收集了足够的信息)。

下面我的将一步步帮你完成这部分。

第1步：确定你要创建的东西

首先，想一下你在这部分到底要做些什么。

如果你采用一个层级模式(甚至是一个层级和数据库结合的模式)，你有可能想要创建最高层级的组别以及子分组。

如果你大部分采用数据库内容，你有可能想要为你的内容创建属性。

第2步：开始行动

现在，草绘你的信息架构图。

你之前预期的不止如此?

瞧，你已经做好了所有必需的准备工作。只要你明白你要创建什么，并且收集了足够的用户和内容信息，那就没有任何理由再浪费时间了。

此时此刻，最好的办法就是把你所知道的所有信息再次在脑中回响，然后呢，就尽管绘制些东西。没错，尽管去尝试，草绘一组优先级最高的群组或者属性。

没错，就是现在。

是的。

开始行动——开始在一张白纸或者一块白板上随意绘制，或者在脑中稍微过一下你想要的东西。一旦你熬过了这种对于从无到有的恐惧并开始做些什么，自然水到渠成。

我曾经在一篇博文里写到过这些，并用了“尽管绘制些东西”(译者注：“Just make it up”)这个说法。从评论来看，一些人认为我的意思是你应该直接从无到有来做。其实我根本不是想表达这个意思。你创造的内容是基于你所知道的基础之上，因此不可能是无中生有的——你需要加工你已知道的所有信息。

但是，不要在这个时候力争完美。只要产出一点或者一部分内容来作为起点。不要因为没有立马得到完美的解决方案而感到烦恼。

第3步：检查

这一步比上一步更加重要。不管你有多么有经验，你最开始绘制的那个构架图版本不会完美无缺。我的亦是如此，绝大多数经验丰富的信息构架师对我也是这么说的。只有在检查你的之后，才能真正做到完美。

再一次的，这一个步骤因人而异，主要取决于你是在处理一个层级内容还是数据库内容。

如果你是在处理不同层级的内容：

查看一下你草拟的分组。想一下你对于你的对象了解多少。(由考虑你的核心对象或者核心任务开始。)对于他们要做的事情来说，这个看起来会起到效果吗?他们能理解这些分组吗?正确的东西会被分组到一起吗?他们理解得了这些标签吗?

然后看一下你的内容。把它们填入你的草拟分组中。它们都合适吗?它们分类都很明确吗，还是有一些内容可以分入多个组?有没有不适合任何分组的内容呢?

如果你是在处理数据库内容：

看一下各个内容类别的属性。看一下你对你的对象了解多少以及他们需要什么。那些属性能否让你对象方便的进行筛选、分类并缩小内容范围?他们能够理解每一项属性的含义吗?

把你定义的属性赋予一个样本内容。你能清楚明确的赋予吗?有没有对象相比下差强人意?有没有一些属性还得再做做功课?

第4步：修正

对于两种内容，回到第2步并修订之。

看一下你的草稿，好好分析下你的目标对象以及内容。看看草稿构架是否会有作用。

每一次这样做的时候，都先核对下你的核心任务和核心内容。当你修正的时候，再开始看那些不常见的任务和内容。每一次都切记要深入并且不放过细节。

第5步：停下来

你将知道何时该停止修订。当你审视你的草稿构架图、你的对象需求以及内容，会有某个时刻，感觉非常良好。你感觉它们如此简洁并且正确，不能再更加改进了。

我不确定是否每个人都会遇到这样的时候(尽管在和我workshop里的伙伴们聊过之后，我发现这个挺常见的)，但是当我在执行这一步的时候另一件奇怪的事情发生了。我不仅感觉良好，而且还觉得自己怎么如此愚笨以至于花了这么多时间才完善到这一地步。“几天之前我居然还会觉得这个很难，怎么会?这个方案也太明显了，我应该做的更快才对。”

这只是我所知的这个心态的一种表现方式。我之所以那样觉得是因为我成功地把一团混乱的东西变的简单而优雅。为此我花费了大量的心思，才使得它最后看起来如此明显。

第6步：讨论

在一个项目中，这一步是一个和其他人探讨草稿构架的好时机。和你的客户、同事或者主题专家(译者注：Subject Matter Expert，SME)聊天。然而，除非你已经完整而正确的走完一边整个流程，否则给他们展示一个半成品是没有意义的。

和他们聊天的时候，准备好和他们解释下你是如何产生这个想法的。准备好解释一下那些你放弃的点子以及你的方案的基本原理。但是最重要的是准备好各种针对极端案例内容和用户需求的细节问题。告诉你们一个秘密，如果人们和你谈论详细的极端案例，说明你的核心想法是正确的。否则他们肯定就是在针对核心想法挑毛病。

如果他们开始挑毛病了，做一个聆听着。想一下到底出问题了，为什么他们不理解你。我的经验是，如果很多人对你的草稿有意见，那一定是哪里有问题。长久以往它就会失效。

我上一次展示一个我觉得没问题的草稿构架图的时候，主题专家中的一部分人对它持保留意见。他们很礼貌的表示，“我仍不是很确定，让我们看看吧。”那时我才输入了一半内容，后来我发现他们是对的——我的构架不会有用。这个例子中我的错误在于，我以为我理解但是事实上我并不理解这些内容(而它们是建立在一些滑头的法律之上的)，所以我没有意识到问题。我重新写了内容同时调整了构架。然后我回去和那些人说，“喂，还记得你们说我的构架不会有用吗?没错，它是不行。”

小窍门

作为一系列步骤，这个流程是相对简单的。这里我给出了一些额外的小窍门。

多少个内容组?

多少内容组算是太少或者太多?像你预期的那样，这是没有正确的答案的——它取决于你的网站以及内容。

你想要人们在当前的任务中方便地发现他们需要的任何东西。这包含了三个步骤：

通览分组列表

忽略那些不相关的东西

在可能相关的东西之间抉择

你可能觉得少一些分组数目有助于加速构架的完全。的确一开始会变的更快，但是如果你的组数少，分组本身就可能变的抽深奥且难以解读，使得接下来的步骤变得困难。

那如果你创建更多的组减少深奥的组出现呢?好，第一步“概览分组列表”将会变的缓慢。但是第二步和第三步会由于内容变的简单易懂了而执行的更快。

就像你所看到的那样，这都是一个平衡的过程。如果你不确定你要选择何种方式的，那么试着用这个步骤去创建两个版本。随后和你的对象一块测试一下，看哪个更加合适。

我博文评论里的一条最好的诠释了这个方法：

“我不想让自己听起来像个自以为是的家伙(或者任何澳大利亚俚语里相同含义的称呼)，但是对于一个导航栏中的项目来说，最佳的数量是零，在这个前提下取得一个折中解决方案之后再逐步增加项目数量。

零项目意味着对用户来说的零理解成本，这是比较理想的，而这之后增加的每个项目则要求用户要付出直线增加的复杂理解成本。我知道零项目是不实际的(或不政治现实的)(译者注：politically realistic)，但是我觉得这个具有挑战性的办法完全可以理解成“哪些是我必须要加进我的列表的?”而不是“我该怎样精简列表?”

上述这些事我的想法，我同意你认为长列表也可以正常工作的观点(以及用户在测试中验证是一种内部方案游说的强有力办法)。长列表的关键在于用户忽视其他只关注自己正在找寻项目的这个过程的速度。如果我们能够让我们的构架让用户更加倾向于忽视无用内容而不是理解有用内容，则更有可能成功。举例来说，如果你把一张按首字母顺序排列的100个人名给我看，告诉我我的目标是找到我自己的名字，这个时候，这个练习的其实是排除忽略掉其他不是我名字的99个项目。“

导航的设计

当你草绘信息构架的时候，你会对导航有个大概的想法。虽然说你应该先完成构架图(使得你的分组和标签正确无误)，但是其实你不能把两者分的太开。如果有想法，就把导航先绘制一下以防之后又忘记了，不过，此时最重要的还是全力完成信息构架。

用哪个分类表

在workshop的时候大家一直问的一个问题是他们是否应该根据对象为中心的方案(译者注：audience scheme)、主题为基础的方案(译者注：topic-based scheme)还是其他。对于这个问题，除了提醒他们对象为中心方案难度大(见175页)之外，通常我还会鼓励他们两个都试试。其中的一个方向肯定会比另外一个更加有效。这真的是解决这类问题最简单不过的方法了。

如果你有两个不错的解决方案，另一个抉择的方法便是可用性测试(你迟早会做这个测试——详见19章)。这个测试通常来说能让你对于哪个方案更有效有一个清楚的认识。

如果最后两个方案都可行，或者一个方案对于一个对象可行而另一个方案对于另一个对象可行，那你得想一下如何来把两者都应用到你的网站上去。可能你需要把内容重新围绕主题整理同时又提供一个对象为中心的入口。(关于聚焦入口模式详见16章)。

如果利益相关者不喜欢

如果你的客户、利益相关者、作者以及主题专家对于你的构架非常不赞同，或者对于你如何完成它已经有了固定的想法，你可能需要：

看看自己是否真的没有考虑周全，或者陷得太深。回到最开始找到那些人们十分不赞同的部分并重制。放弃已有的点子重新开始是艰难的，但是这或许是你重新找到那些遗失部分的必经之路。

按照上面的流程重新走一遍你的方案，看看它是否有效。如果没有，那么对于那些无效的部分做详细的记录，这样你到时候就可以很清楚的解释问题。你以后逐步会随着经验的增长而学到，那些表面看上去明显而简单的东西其实并不是那样的。

团队合作还是单干

你可以自己一个人单干，也可以寻找团队合作。我发现自己一个人把最初方案想明白更简单。而对于复杂的问题，我发现同时考虑信息构架、对象需求和内容并和其他人探讨的话有些困难。如果你也是这样并且在团队中工作，你可以首先独立把草稿方案做出来(并对内容和需求进行至少一轮检查)，然后和其他人在一起把每个人最好的部分一起梳理一遍。

如果你在团队中这样做，千万不要始终讨论是否要用某种特定的方式解决方案，这会让你和你的小伙伴们陷入困境。举例来说，不要针对是否要采用”产品与服务“作为单一的组或合并的组进行冗长的讨论。应该两种方式都去试一下看看哪个更好。

流程的方法学

是不是不知道实践中具体该怎样做?是应该用电脑绘图软件创建一个网站地图呢(更多关于站点地图的内容详见20章)，还是用思维导图软件，甚至表格软件?

只要你采用的方式适合你的想法，用何种方式并不是很重要。有时候我会把我知道的所有东西简略的写到便利贴上，然后把他们随机地贴在我办公桌上直到我看到有合适的方案。又有时候我会把所有的用户调研和内容想法贴到白板上然后写上一通。还有的时候(这是我最常用的方式)我坐在舒服的办公椅上，双脚搁上桌子，在脑中默默思索(这往往会吓坏项目经理，他们会觉得我啥都不做)。偶尔我也会在跑步或游泳的时候把问题想清楚。有时候和客户在一起，我会用一块白板和N只马克笔在完成这些。不管如何，方式的采用只取决于是否对你合适。

唯一一件你不应该做的事情便是呆坐在电脑前面。电脑软件确实是记录实现你想法的好工具，但是对大多数人来说，站在白板前面或者做一些类似在大桌子上交换纸张的实际活动时，他们更有创造力。即使你更喜欢用软件来做思维导图，也该至少先从纸上勾勒开始。

图1. 绿色的便利贴上写满了内容

图2. 白色便利贴上的用户需求

图3. 随机组合直到能解决问题。粉色便利贴上是标签

记录你方案的基本原理

当你建立你的信息结构时，记录下那些你摒弃的想法以及为什么你保留了当前的想法。这将帮助你在面对客户或者团队成员时很好的回答他们那些“为什么不这样不那样”一类的问题。你可以清楚的回忆起自己当时的想法并让他们心服口服。

没必要为此建立一个庞大而正式的文档。一些随便写下的笔记就可以了，甚至拍一些白板上不同阶段的照片也行。我保证你在整个信息结构建立的过程中，肯定会忘记当时做某些决定的原因。

随着时间而改变的信息结构

一些网站的信息结构是随着时间而改变的，因为其中很多类别的内容是建立在循环的基础上的。举个例子，UX Australia conference的网站在一年之中随着各个里程事件的达成而改变。

如果你的站点也会随着时间以周而复始的方式变化，或是会增加额外的内容，记得把这些包含进你的信息结构中。

信息构架中的排序

你要考虑的另一件事事信息构架中的排序问题。在大多数情况下，这个顺序是很简单就能想到的——它们会有一个自然的顺序。有时候这个顺序是按照重要性程度定义的，有时候分组会结合在一块形成自然的子组，看上去就像它们就像一个整体。

最糟糕的情况是你按照字母顺序排序——字母顺序对于A到Z的那种列表(当人们在完成一个已知项目的信息任务时)是不错的，但是它不适合导航项目。字母顺序本质上是随机的顺序。因此，你还是得花些时间来找寻一个有意义的顺序而不是懒惰的默认为字母顺序。

测试信息构架

你越过了信息构架设计流程的主要的一座大山。目前对于你设计出的信息构架，你也比较地满意。它不仅适合你的内容也应该很好的服务于用户。

在继续下一步之前测试一下这个设想是一个不错的想法。相比于仅仅想着希望它能够服务于用户，去实际确保一下显然更好。

这便是可用性测试。它的组成包含三个步骤：把你要测试的对象丢给测试用户，要求他们去完成一些他们一般会完成的任务，然后检查你的测试对象是否工作正常。当你在实际去做之前对对象进行可用性测试的时候，可以发现哪些正常工作，哪些没有，以及哪些需要修复。它使得那些将来不能工作的部分浮出水面帮助你及时采取措施。

当然，可用性测试可以用于任何目标对象。虽然说它被大量使用在软件以及网站上，我也听说过有零售店曾经为了检验货架陈列的改变效果而专门建立测试性的商店。

对于任何项目，你可能不会在如此庞大的对象上做可用性测试。你想要测试你的信息构架草稿——你的分组和标签。最终这些将形成人们寻找信息或执行任务的主要通道。所以把它们设定正确并知道它们是正确的，是十分重要的。

这时候的可用性测试不会检查任何你要在项目最后时检查的东西。你会在完成导航、页面布局以及内容的设计之后想要再一次彻底的做一次测试。然后，每一次你想测试的东西越多，想要发现哪些方面不在工作就越难——是你的标签难以理解呢，还是页面太臃肿以至于人们无法找到导航条?针对信息构架的可用性测试只告诉你你的分组和标签是在正常工作的。另一个要对信息构架做可用性测试的理由在于导航和内容需要和它契合工作，所以最好在应用导航和内容之前发现任何可以发现的错误。

可用性测试不是测试人们能否使用你的网站，而是检查你的网站能否让他们做他们应该做的事情。这两者之间存在着微妙而重要的区别，这是你的测试时要谨记的。你是在测试你的方案，而不是测试测试者的能力。

你想发现什么

在开始可用性测试之前，想一下你想得到什么样的结论。这将帮助你决定如何执行测试以及选择哪些测试人员。

你想发现的主要一个事情是你的分组是明显的，你的标签是易懂的。你可能要检查一下你总的路劲是否正确(比如，如果你采用一个对象为中心的分类表，那么人们是否按照那种方式来看你的信息并且理解分组)。或者你也可以不测试整个信息构架，取而代之的是深入的检查其中部分设计时遇到困难或利益相关者持不赞同意见的地方。

何时测试

我接下来要介绍的方法有一个最好的优势在于它实行起来非常容易。不需要太多的准备工作，并且结果也出来的很快。取决于不同的情况，你可以某天早上创建一个测试，在当天下午得到结果。用它来测试信息构架真的非常方便。快速测试、进行调整、再次测试，这样的流程棒极了。所以你可以一有满意的方案了立马进行测试。

如果你之前没有机会做用户调研(我知道各种各样的原因会导致这样的情况)，你可以利用这个机会测试一下你的信息构架，同时做一些额外的调研。即使你之前做过一些调研了，很有可能又会出现一些新的问题然后你想要了解更多，亦或是一些新的设想。把构架测试和一些简单的调研结合起来有助你在项目后期做更明智的决定。

你可以用其他方式来控制测试时间。(测试花的时间其实很少，你可以把它加入别的活动中。)如果你想和你的对象用其他方式进行交流——可能是一个利益相关者或工作人员会议，以便为网站其他部分收集需求——你可以同时进行一个简单的测试。

如何测试

这样的测试是很简单的。你要做的就是问一下用户他们如何利用你的信息构架完成一个特定的任务或找一个特定的信息。

举例来说，如果我想为我的会议网站进行测试，我会让测试对象找一些关键信息比如会议价格、某天有哪些活动以及他们能从会议获得什么。我其实没有要求他们找到答案，因为我不提供内容，但是我会问他们在哪里找寻信息。我会一步步的给他们展示信息构架并让他们告诉我他们会在哪里查看——这十分简单。

这个测试方法用在层级模式(详见第16章)、简单的数据库结构以及组合式层级和数据库(尤其用来检查最高层级内容)时效果最佳。如果你使用了子网站结构，你可能需要从最高层级开始测试，或测试一个以上的子网站。这个方法对于测试聚焦入口结构也是很棒的，因为你可以看到不同人群选择何种方式获取信息。

它不太可能适用于大多数的wiki结构——这些结构没有一个实际意义上的信息架构来测试。你可以在之后有了一些内容的时候进行测试(详见第24章)。

它适用于目录中的头几个层级，但是不太适合更深的层级——尤其是那些含有许多产品的层级。

准备工作

开始之前，你需要一下三样东西：

1. 一份草拟的信息架构图

你需要的第一个东西便是你草拟的信息架构图。

你的架构图还停留在草稿阶段，这没有问题。这是一个检查哪些部分工作哪些部分不工作的绝佳办法。你不一定只测试一份构架图，你也可以试试其他版本或不同方案。

同样，如果在草稿中，你把同一个内容放在了多个地方(因为你不确定该往哪放)，这也是没问题的。这可以让用户觉得自己找到了“正确的答案”，然后提供给你关于路径的有用信息。

2. 场景

你需要的第二个东西是一系列任务或者你认为用户可能要寻找的一组东西。在可用性测试中我们称之为场景，它们代表了用户在测试中做的事情和寻找的东西。

当你把这些写出来的时候，确保使用人们常见的说辞并提供一些上下文背景使得整个任务易于理解。尤其得避免采用和信息构架图上一样的词汇。如果你这样做了，测试就变成了在场景中进行寻宝大作战。

举例来说：

如果你在设计一个家居网站，不要说“你需要一个崭新的书柜”，因为人们会开始冲着“书柜”两个字进行寻找。你应该说“你刚搬了新家，各种书放在纸盒里遍地都是”，这样子就能够让他们去思考这个问题的解决方案。

如果你有内网，那在那上面不要说“请查看产假相关条例”，取而代之的应该是像“你发现你的宝宝要出生了，可以享有哪些权益?”这样的说辞。

在你的会计软件上，不要说“收取可接受的发票”，试一下“你刚给你的客户提供了报告，是时候去拿钱了”。

应用这些更加实际的场景能够确保人们考虑到要完成的任务，而不是只是去寻找一些特定的词汇。

对于场景来说没有一个所谓正确的数目。你希望有足够多的场景来涵盖信息构架中的一大部分(或是你最感兴趣的那部分)以及涵盖人们一般会做的大部分任务(以便于验证主要任务的完成是相对简单的)。

人们在场景中会看到信息构架的一部分，并记住他们看到东西的地方。这是OK的，就像人们在真实生活中那样。但是过一会人们便开始把注意力放在记忆他们看到事物的地方，而不是考虑他们该在哪边寻找事物。

我发现平衡这两个问题最好的方法是有足够多的场景来涵盖你的内容和一般人物，并且有足够多的参与者保证单个人不会完成所有的场景——他们只需要保持活跃状态。

随机选择你的场景也是不错的办法(如果你像我下面所描述的那样把场景写在索引卡上，只需要洗一下卡片就可以了)，因为每个人会按照不同的顺序完成。这样就确保了你的测试没有顺序倾向性

3. 参与者

你需要的第三个东西是一群能抽出小段时间参与的人员。我们在第6章里讨论过，参与者必须是将要使用你信息的人。

对于这类可用性测试需要说明的最重要一点在于它只占用一小部分时间和精力。就算是人们投入的几分钟时间也可以给以带来十分有价值的数据。所以你安排参与者参与的方式很大程度上取决于你的项目情况。比如，在做内网的项目时，我会做面对面的测试，基本上都是直接去人们办公桌前进行。对于网站项目，我则会建立网上测试，通过邮件或者有问题的那个网站邀请人们。如果你能让人们执行测试的难度和力度降低，他们的参与性会大大提高。

关于更多如何让人们参与的内容，可以参见第6章中关于招募参与者的部分。

方法

做这类可用性测试主要的两种方式是面对面和网上(你也可以两者都做)。面对面的优势在于你可以和人们交谈。像其他的调研活动那样，你可以问调研对象他们为什么做了某个决定以及一些词语对他们来说意味着什么。这种反馈帮助你理解你的信息构架工作(或不工作)的原因，而不是只是告诉你它正在工作。

当然，要实施面对面的调研并不总是很简单，这也就是网上测试有用武之地的理由。网上测试的主要优势在于你可以招募那些不能面对面调研的人。而且你也可以招募到比面对面调研更多的对象，这将给你提供不少有用的信息。这两种方式有着不一样的准备工作。

纸上准备工作

图4. 场景卡片和层级卡片

如果你决定做面对面的测试，你需要准备好你的信息构架以及场景。我最喜欢的方式是准备一套索引卡片。

对于信息构架图：

把最高层级的类别写到卡片上。如果你的类别一张卡片上写不下，接着下张卡片写就是了。把字写的尽可能大一些，保证你能在一臂的距离还能看清。为每一个类别编号1,、2、3、4、5等等。

对于每一个最高层级的类别，把他们的子类别用上面的方法也写下来。同样，一张卡片写不下就继续下一张卡片。如果可以就使用不同颜色的卡片来区分层级与层级，这样比较方便但是也绝不是必须的。把层级编号，这次要加入上一层及的号码，后面跟上这个层级的号码(比如1.1、1.2、1.3)。

继续为各个类别和层级编号。

对于场景来说，把各个场景写在一张张卡片上(同样，如果可以分开卡片的颜色会比较方便)。我通常会在卡片边角为这些场景用A到Z的顺序编上标签。(数字编号和字母编号的系统有助于记录和后期分析。)

为你的测试想一个描述性的说法。这有利于你更有效地向人们解释活动并帮助他们理解任务。我通常会这样说：

“感谢你们今天来到这帮助我们。我们已经花了很大的精力来改进【你的网站名字】，所以我们希望检验一下我们之前的方案对于这个网站的使用者来说是否有效果。

我待会会告诉你们去哪里找一些我们设定的信息。在这些卡片上有一串人们在这个网站上会做的事情。我将给你们展示其中的一个以及一系列词语，这些词语最后可能成为我们网站的导航词汇。你们要做的是告诉我你们最先看哪里，随后我会再给你们展示另外的页面，同样，你们也要告诉我你会会看哪里。如果中间出现了一些问题，我们会重新再来一次，但是我们不接受超过两次的选择。这毕竟不是找东西的游戏。这个听起来可能有些奇怪，但是不用担心，一旦咱们完成了一次，你就知道我的意思是什么了。如果卡片上的任务(场景)你们觉得不会去做，或者它们没有意义，跳过便是了。”

准备好你的卡片(以及一些白纸和马克笔)，然后就开始吧。

进行测试

当你和参与者在一起的时候，你应该像你之前描述的那样进行整个测试。所以首先给他们展示一个场景(你也可以读给他们听)，然后给他们看最高层级的卡片。让他们选一组。对于选定的一组，给参与者看第二层级的卡片，持续下去直到没有新的卡片可看。

如果一些参与者选择了一组之后觉得自己好像选错了(通常这是由于他们在接下来的卡片展示中没有发现任何有用的东西)，那就回到上一步让他们再次选择。但是就像你之前概述的那样，只能重新选择两次。毕竟你是想知道他们会往哪里看，而不是让他们真的去找到那个“答案”。

在场景测试里，如果你觉得参与者在试图去记忆他们看到答案的地方，而不是在真正思考他们在寻找什么东西，那就该收尾了。

如果参与者在任何一步里需要回到上一步，你应该先问问他们遇到了什么情况。看看他们是否记得他们为什么选择了那组以及他们觉得那组应该包含些什么。千万小心不要让他们认为自己犯了一个错误——切记，你是在检验信息构架，而不是在检验参与者。但是这时通过询问你可以获得很多人们对于组别想法和寻找内容方法的有用信息。

当测试完成以后，感谢参与者的帮助并让他们知道接下来该做什么。

我在用这种方法测试信息构架时，有时候会注意到一些持续出现的问题——通常是一个没有意义的标签。这也就是为什么我会准备好多余的卡片和马克笔。相比于用一些我知道没用的内容进行测试，我更情愿更换一下标签(写一张新的卡片)，然后继续测试下这新的表情是否更有效果。

记录结果

在测试进行的时候，记录下参与者的回答(这就是为什么我们要为索引卡片建立数字和字母编号)。我比较喜欢有一个人在身边专门记录，因为有这么多不同的卡片而且还要记录下参与者的选择，这将是很繁琐的一件事(而且整个测试进行相当迅速)。你要做的就是记下每个场景进行的轨迹。

举例来说：

A: 1, 1.2, 1.2.1 (no), 1.2, 1.2.6(开心)

B:7, 7.6, 7.6.5

有一个帮手的话，还可以记录下人们的评论。这些评论既有趣又有用。

测试之后，我经常会用一个庞大的表格文件来记录结果。我把场景放在顶栏，把信息构架放在下方。随后我查看参与者在每个场景中寻找信息留下的所有结果和统计。由于我给他们两个地方去找，所以我通常用大写X标注他们第一个选择，用小写x标注第二个选择。

这个过程很简单，但是它很快就能让你看到用户的查看模式。对于一些场景来说，你会发现有一个持续的路径。而对于另外一些，可能不会那么明显。有时候会发现一些和你之前认为“结论”很不一样的结果。

在线测试

准备这样的测试用的在线工具会有很多，而准备工作也各有不同。在写本书的时候，我所知道的有三种专门用于信息构架测试的在线工具(都是比较新的)：

TreeJack：Optimal Workshop出品(http://www.optimalworkshop.com/treejack.htm)

C-inspector(http://www.c-inspector.com/)

PlainFrame(http://plainframe.com)

前两个工具让你按照层级树测试信息构架，第三个工具让你以导航的形式测试，即屏幕上的导航栏。通常我会在导航还没有任何雏形的情况下设计信息构架(第23章里会有讨论)，所以层级树这种形式更适合我。但是如果以导航的形式和部分内容一块进行测试又会更加简单一些。

就像面对面测试的思路一样，你得先上传一个层级(你的信息构架)以及一系列场景，然后通过邮件或者你网站上的链接将你编写的介绍性测试发送出去。

图5. Treejack

图6. PlainFrame测试的结果展示

理解结果

一般来说结果是比较容易理解的。我之前提到过的表格文档，或者上述工具的结果输出，都清晰的展现了你的构架中哪些在工作哪些不在工作。当你在理解这些结果的时候，不仅要考虑发生了什么，还要考虑为什么发生。

首先，想一下总的路径是否正常工作。测试有没有显示针对你的信息构架你选择了一条好的基本路径(尤其是在你选择对象为中心或任务为中心的前提下)?

找到那些参与者寻找目标的地方和你预期一致的场景。你可以比较有信心的确定那个位置是某个内容的最佳安放地。

对于那些工作良好的部分，考虑一下背后的原因并检查下这个原因是不是来自你精心设计的构架。这里你还得有一些自我讽刺的精神，确保那些没有很好执行的场景是因为你使用了引导性语句，参与者被引导，或是因为他们的确得在执行完至少5次那个场景后才能发现理解信息构架。

当你发现结果和你预期的不一致的时候，想一下到底哪里有问题：

是否每个参与者理解的信息位置都和你预想的不一样?如果这样，那你就要考虑下把内容放在那个位置。修改一下你的构架来适应人们的选择。

是不是你的一部分标签表意还不够清晰，或者参与者理解它们的方式和你预期的不一样?你需要再看一下这些标签以及标签下放置的内容，或是分类本身。

当你分析完那些工作和不工作的部分了，回到我们上一章讨论的流程。调整一下信息构架(或是完全颠覆之并重新用一个新的方案)，然后再次测试一下。持续这样子做直到你对自己的作品满意。

用Windows Explorer执行树状测试

By Brian Hoffman，网站体验专家，EnergyCAP公司

“我做了一个开放式的卡片整理，整理出一些最高层级的分类。内容分类填入这些分类之后可以发现一些用词的问题。但是我想测试下我设计出的层级，所以我不认为封闭式的卡片整理能够带来理想的结果——我想要测试整个层级而不只是最高的那么几个层级。

因此我有了树状测试的点子。我希望让参与者面对一个自然的交互界面，所以最后我把层级以Windows系统下嵌套式文件夹的方式展现。我们给参与者布置任务，要求他们在文件夹中浏览同时鼓励他们边想边说，以在层级中寻找内容。

这个方法真的很有效。在结合迭代式的测试流程，我觉得我发明了一种十分强有力的网站信息构架初始设计方法。”

信息构架测试——3种方式

By Melinda Anderson，独立用户体验咨询师

“几年前一个本地的(澳大利亚)政府客户来寻求我的帮助。他们正准备重新设计他们那个以信息为基础的庞大网站。当时他们已经设计出了一个新的站点结构，但还没有招募用户来测试一下。所以他们想在下一步进入深入设计和开发之前看看这个新的结构是否工作。而对于这个数据内容庞大的网站，当时只产出了一小部分线框模板，因此可用性测试不太可能。网站没有足够的线框来构成一个原型，但是如果等到网站开发基本完成又意味着后期更大的风险。

我之前听说过一个利用索引卡片测试的办法。那个客户提供给我他们提交的结构，然后我把它转化成了索引卡片。有了这些卡片以及一系列信息寻找的任务，我跑到了当地的图书馆(当然是在图书馆允许的情况下)，试图拉拢一下人来做测试。我发现参与者能够迅速的理解那个结构因此之后的任务产出的结果没有之前的任务结果那么有实际指导意义。此外，我发现一边和这些卡片打交道，并试着记录下用户使用的路径，同时又要问问题以便理解他们的动机，很有挑战性。然而，在这些实践的最后阶段我依然可以回到客户那边并给出一些有关关键问题领域的建设性意见。最后客户当然是开心的离开了。

大概又过了6个月有一桩相似的案例出现在了我的办公桌上。我一个同事研究出了一个用来创建带导航的原型网站的工具。我们决定按照标准的可用性测试标准来对它执行以下信息架构测试。客户提供站点图我们负责开发出一个原型。我们从他们的主要对象中抽出了6个人作为参与者。和上次一样，参与者很快理解了结构，因此在大概15项任务之后，结果便有些欠说服力。然而这一次，记录他们的行为更加方便简单，因为我并没有布置翻阅卡片的人工任务。测试为我们提供了强有力的结论。又由于采用了一种采访风格的方法，我们能够收集到有关标签的反馈，挺像采用基于卡片的分类验证机制那样。我们把结果用不正式的改进文件反馈给客户，然后他们依据这个来实施改进。

时间过了两年，我现在为一家设在伦敦的机构工作。有一个客户想要给他的新网站做可用性测试。然而，由于网站有庞大的数据内容构成，他面临着和我第一个客户一样的问题——他们没有足够多的交互内容来进行测试。为了在耗时一个小时的测试之后有尽可能多的结论，他们需要提供一个相当完整的原型。这从预算上是不可行的，并且时间也不允许。

在研究信息构架测试工具的时候，我有了一个点子。它可以描述称一个全新的基于网络的软件程序(Treejack http://optimalworkshop.com/treejack.htm)。利用它，用户可以在没有主持人的情况下远程的完成测试。而由于客户对于全程都用Treejack进行远程测试会觉得不放心(他们对于信息构架测试的概念不熟悉，担心得不到他们要的结果)，我们会邀请一小部分样本用户来到我们的实验室，随后类似白站测试(译者注：white site testing)和可用性测试，我们会观察他们用Treejack完成任务的过程。Treejack能很方便的记录下用户采用的路径并生成方便人们理解和分析的结论形式，帮助我们更快更简单地发现关键问题。此外，通过观察，我们还能收集到有关站点的评价和反馈，这在远程研究里是做不到的。

同时我们也得到一些很棒的结果然后反馈给了客户，我们的确发现了一些之前没有想到的问题。我发现我们的结论有可能会有偏差。一些参与者喜欢先浏览一遍结构看看每个部分里都有哪些内容，然后再回溯做出选择。同时对于一些类别用户的浏览行为来说是一直存在的现象，而这和研究的初衷是不吻合的。研究的初衷在于依靠用户自身的本能决定。我还发现不是所有的参与者都会用Treejack，就算是给他们提供了完整而全面的教程亦是如此(记住，用户总是不太愿意去阅读教程的)。

从第一次使用Treejack到现在，我已经用它完成了深入的研究，这些研究里远程的测试占极大的比重。我发现，虽然说这种远程的研究没有实验室和主持人的参与成本相应比较低，但是没有直接的与参与者进行互动导致我们最后只能获取路径信息，而且这个信息只有研究人员才能正确的解读。我还得把用户与程序之间的交互方式和我们预期不一致这种情况考虑进去，因为这可能会导致结论偏差。虽说如此，我还是觉得这种数据记录的远程方式相比基于卡片的人工分类验证机制更值得推荐。

再针对信息构架测试尝试了许多种方法治好，我在这里可以很有信心的说，我更喜欢采用电子原型而非索引卡片的办法。我发现用户在自由操作的情况下，我可以花更多的精力去观察、记录并提出更多详细的问题。我认为，远程方法后期的一对一谈话相比一直远程的操控主持更好，因为我可以和参与者共同探索概念和原理，这可以帮助我更好的理解我的测试结果，并且让我之后可以提出更加精确的改善意见。”