本文译自Donna Spencer所著《A Practical Guide to Information Architecture》，第18章。
本书主要对信息构架及其设计进行了一些入门的理论和实践介绍，其中包含了一些作者自己的方法，和业界采用较多的方法。无论是网站或者移动应用均可以参考并根据自己的情况进行试验性尝试。
第18章 如何创建一个信息构架
假设到目前为止，我们之前谈论过的所有事情你都全部完成了。你心里清楚你要为你的客户或者业务取得什么成果。你也了解你的用户、他们的需求以及他们获取你信息的方式，并且，你知道你的内容是关于什么的。
此外，你还掌握了许多关于分组、分类机制、信息构架模式以及标签的知识。
知道吗？是时候开始为你的网站创建信息构架了。（你可能会说：“终于！”）
这同时也是整个过程中最恐怖的一个部分。现在，你需要去创造些东西。
接下来你完成这个步骤的方式方法取决于你是如何工作和思考的。（不同的人之前会有微小的差异。）
如果你喜欢严格按照步骤来做事——这一步引入下一步的模式——你可能会好奇该“如何”从你之前收集到的这些信息里创造出一个理想的信息构架。不好意思，这一步不是线性的（而且你可能还记得我们在第10章里讨论的，永远不会有完美的结果）。而如果你喜欢那种让你心里对于如何获得一个结果结论比较有谱的线性过程，这里你也将会遭遇一些困难。
但是，如果你是一个更加依靠直觉并且有创造力的人，这一步会显得比较简单。跨出那创造性的一步，把所有信息整合进全新的信息构架，这些将让你觉得非常舒服。你很有可能会觉得这步相当容易（前提是你已经收集了足够的信息）。
下面我的将一步步帮你完成这部分。
第1步：确定你要创建的东西
首先，想一下你在这部分到底要做些什么。
如果你采用一个层级模式（甚至是一个层级和数据库结合的模式），你有可能想要创建最高层级的组别以及子分组。
如果你大部分采用数据库内容，你有可能想要为你的内容创建属性。
第2步：开始行动
现在，草绘你的信息架构图。
你之前预期的不止如此？
瞧，你已经做好了所有必需的准备工作。只要你明白你要创建什么，并且收集了足够的用户和内容信息，那就没有任何理由再浪费时间了。
此时此刻，最好的办法就是把你所知道的所有信息再次在脑中回响，然后呢，就尽管绘制些东西。没错，尽管去尝试，草绘一组优先级最高的群组或者属性。
没错，就是现在。
开始行动——开始在一张白纸或者一块白板上随意绘制，或者在脑中稍微过一下你想要的东西。一旦你熬过了这种对于从无到有的恐惧并开始做些什么，自然水到渠成。
我曾经在一篇博文里写到过这些，并用了“尽管绘制些东西”（译者注：“Just make it up”）这个说法。从评论来看，一些人认为我的意思是你应该直接从无到有来做。其实我根本不是想表达这个意思。你创造的内容是基于你所知道的基础之上，因此不可能是无中生有的——你需要加工你已知道的所有信息。
但是，不要在这个时候力争完美。只要产出一点或者一部分内容来作为起点。不要因为没有立马得到完美的解决方案而感到烦恼。
第3步：检查
这一步比上一步更加重要。不管你有多么有经验，你最开始绘制的那个构架图版本不会完美无缺。我的亦是如此，绝大多数经验丰富的信息构架师对我也是这么说的。只有在检查你的之后，才能真正做到完美。
再一次的，这一个步骤因人而异，主要取决于你是在处理一个层级内容还是数据库内容。
【如果你是在处理不同层级的内容】
查看一下你草拟的分组。想一下你对于你的对象了解多少。（由考虑你的核心对象或者核心任务开始。）对于他们要做的事情来说，这个看起来会起到效果吗？他们能理解这些分组吗？正确的东西会被分组到一起吗？他们理解得了这些标签吗？
然后看一下你的内容。把它们填入你的草拟分组中。它们都合适吗？它们分类都很明确吗，还是有一些内容可以分入多个组？有没有不适合任何分组的内容呢？
【如果你是在处理数据库内容】
-
看一下各个内容类别的属性。看一下你对你的对象了解多少以及他们需要什么。那些属性能否让你对象方便的进行筛选、分类并缩小内容范围？他们能够理解每一项属性的含义吗？
-
把你定义的属性赋予一个样本内容。你能清楚明确的赋予吗？有没有对象相比下差强人意？有没有一些属性还得再做做功课？
第4步：修正
对于两种内容，回到第2步并修订之。
看一下你的草稿，好好分析下你的目标对象以及内容。看看草稿构架是否会有作用。
每一次这样做的时候，都先核对下你的核心任务和核心内容。当你修正的时候，再开始看那些不常见的任务和内容。每一次都切记要深入并且不放过细节。
第5步：停下来
你将知道何时该停止修订。当你审视你的草稿构架图、你的对象需求以及内容，会有某个时刻，感觉非常良好。你感觉它们如此简洁并且正确，不能再更加改进了。
我不确定是否每个人都会遇到这样的时候（尽管在和我workshop里的伙伴们聊过之后，我发现这个挺常见的），但是当我在执行这一步的时候另一件奇怪的事情发生了。我不仅感觉良好，而且还觉得自己怎么如此愚笨以至于花了这么多时间才完善到这一地步。“几天之前我居然还会觉得这个很难，怎么会？这个方案也太明显了，我应该做的更快才对。”
这只是我所知的这个心态的一种表现方式。我之所以那样觉得是因为我成功地把一团混乱的东西变的简单而优雅。为此我花费了大量的心思，才使得它最后看起来如此明显。
第6步：讨论
在一个项目中，这一步是一个和其他人探讨草稿构架的好时机。和你的客户、同事或者主题专家（译者注：Subject Matter Expert，SME）聊天。然而，除非你已经完整而正确的走完一边整个流程，否则给他们展示一个半成品是没有意义的。
和他们聊天的时候，准备好和他们解释下你是如何产生这个想法的。准备好解释一下那些你放弃的点子以及你的方案的基本原理。但是最重要的是准备好各种针对极端案例内容和用户需求的细节问题。告诉你们一个秘密，如果人们和你谈论详细的极端案例，说明你的核心想法是正确的。否则他们肯定就是在针对核心想法挑毛病。
如果他们开始挑毛病了，做一个聆听着。想一下到底出问题了，为什么他们不理解你。我的经验是，如果很多人对你的草稿有意见，那一定是哪里有问题。长久以往它就会失效。
我上一次展示一个我觉得没问题的草稿构架图的时候，主题专家中的一部分人对它持保留意见。他们很礼貌的表示，“我仍不是很确定，让我们看看吧。”那时我才输入了一半内容，后来我发现他们是对的——我的构架不会有用。这个例子中我的错误在于，我以为我理解但是事实上我并不理解这些内容（而它们是建立在一些滑头的法律之上的），所以我没有意识到问题。我重新写了内容同时调整了构架。然后我回去和那些人说，“喂，还记得你们说我的构架不会有用吗？没错，它是不行。”
小窍门
作为一系列步骤，这个流程是相对简单的。这里我给出了一些额外的小窍门。
【多少个内容组？】
多少内容组算是太少或者太多？像你预期的那样，这是没有正确的答案的——它取决于你的网站以及内容。
你想要人们在当前的任务中方便地发现他们需要的任何东西。这包含了三个步骤：
-
通览分组列表
-
忽略那些不相关的东西
-
在可能相关的东西之间抉择
你可能觉得少一些分组数目有助于加速构架的完全。的确一开始会变的更快，但是如果你的组数少，分组本身就可能变的抽深奥且难以解读，使得接下来的步骤变得困难。
那如果你创建更多的组减少深奥的组出现呢？好，第一步“概览分组列表”将会变的缓慢。但是第二步和第三步会由于内容变的简单易懂了而执行的更快。
就像你所看到的那样，这都是一个平衡的过程。如果你不确定你要选择何种方式的，那么试着用这个步骤去创建两个版本。随后和你的对象一块测试一下，看哪个更加合适。
我博文评论里的一条最好的诠释了这个方法：
我不想让自己听起来像个自以为是的家伙（或者任何澳大利亚俚语里相同含义的称呼），但是对于一个导航栏中的项目来说，最佳的数量是零，在这个前提下取得一个折中解决方案之后再逐步增加项目数量。
零项目意味着对用户来说的零理解成本，这是比较理想的，而这之后增加的每个项目则要求用户要付出直线增加的复杂理解成本。我知道零项目是不实际的（或不政治现实的）（译者注：politically realistic），但是我觉得这个具有挑战性的办法完全可以理解成“哪些是我必须要加进我的列表的？”而不是“我该怎样精简列表？
上述这些事我的想法，我同意你认为长列表也可以正常工作的观点（以及用户在测试中验证是一种内部方案游说的强有力办法）。长列表的关键在于用户忽视其他只关注自己正在找寻项目的这个过程的速度。如果我们能够让我们的构架让用户更加倾向于忽视无用内容而不是理解有用内容，则更有可能成功。举例来说，如果你把一张按首字母顺序排列的100个人名给我看，告诉我我的目标是找到我自己的名字，这个时候，这个练习的其实是排除忽略掉其他不是我名字的99个项目。
——DanWillis,uxcrank.com
【导航的设计】
当你草绘信息构架的时候，你会对导航有个大概的想法。虽然说你应该先完成构架图（使得你的分组和标签正确无误），但是其实你不能把两者分的太开。如果有想法，就把导航先绘制一下以防之后又忘记了，不过，此时最重要的还是全力完成信息构架。
【用哪个分类表】
在workshop的时候大家一直问的一个问题是他们是否应该根据对象为中心的方案（译者注：audience scheme）、主题为基础的方案（译者注：topic-basedscheme）还是其他。对于这个问题，除了提醒他们对象为中心方案难度大（见175页）之外，通常我还会鼓励他们两个都试试。其中的一个方向肯定会比另外一个更加有效。这真的是解决这类问题最简单不过的方法了。
如果你有两个不错的解决方案，另一个抉择的方法便是可用性测试（你迟早会做这个测试——详见19章）。这个测试通常来说能让你对于哪个方案更有效有一个清楚的认识。
如果最后两个方案都可行，或者一个方案对于一个对象可行而另一个方案对于另一个对象可行，那你得想一下如何来把两者都应用到你的网站上去。可能你需要把内容重新围绕主题整理同时又提供一个对象为中心的入口。（关于聚焦入口模式详见16章）。
【如果利益相关者不喜欢】
如果你的客户、利益相关者、作者以及主题专家对于你的构架非常不赞同，或者对于你如何完成它已经有了固定的想法，你可能需要：
看看自己是否真的没有考虑周全，或者陷得太深。回到最开始找到那些人们十分不赞同的部分并重制。放弃已有的点子重新开始是艰难的，但是这或许是你重新找到那些遗失部分的必经之路。
按照上面的流程重新走一遍你的方案，看看它是否有效。如果没有，那么对于那些无效的部分做详细的记录，这样你到时候就可以很清楚的解释问题。你以后逐步会随着经验的增长而学到，那些表面看上去明显而简单的东西其实并不是那样的。
【团队合作还是单干】
你可以自己一个人单干，也可以寻找团队合作。我发现自己一个人把最初方案想明白更简单。而对于复杂的问题，我发现同时考虑信息构架、对象需求和内容并和其他人探讨的话有些困难。如果你也是这样并且在团队中工作，你可以首先独立把草稿方案做出来（并对内容和需求进行至少一轮检查），然后和其他人在一起把每个人最好的部分一起梳理一遍。
如果你在团队中这样做，千万不要始终讨论是否要用某种特定的方式解决方案，这会让你和你的小伙伴们陷入困境。举例来说，不要针对是否要采用”产品与服务“作为单一的组或合并的组进行冗长的讨论。应该两种方式都去试一下看看哪个更好。
【流程的方法学】
是不是不知道实践中具体该怎样做？是应该用电脑绘图软件创建一个网站地图呢（更多关于站点地图的内容详见20章），还是用思维导图软件，甚至表格软件？
只要你采用的方式适合你的想法，用何种方式并不是很重要。有时候我会把我知道的所有东西简略的写到便利贴上，然后把他们随机地贴在我办公桌上直到我看到有合适的方案。又有时候我会把所有的用户调研和内容想法贴到白板上然后写上一通。还有的时候（这是我最常用的方式）我坐在舒服的办公椅上，双脚搁上桌子，在脑中默默思索（这往往会吓坏项目经理，他们会觉得我啥都不做）。偶尔我也会在跑步或游泳的时候把问题想清楚。有时候和客户在一起，我会用一块白板和N只马克笔在完成这些。不管如何，方式的采用只取决于是否对你合适。
唯一一件你不应该做的事情便是呆坐在电脑前面。电脑软件确实是记录实现你想法的好工具，但是对大多数人来说，站在白板前面或者做一些类似在大桌子上交换纸张的实际活动时，他们更有创造力。即使你更喜欢用软件来做思维导图，也该至少先从纸上勾勒开始。
【记录你方案的基本原理】
当你建立你的信息结构时，记录下那些你摒弃的想法以及为什么你保留了当前的想法。这将帮助你在面对客户或者团队成员时很好的回答他们那些“为什么不这样不那样”一类的问题。你可以清楚的回忆起自己当时的想法并让他们心服口服。
没必要为此建立一个庞大而正式的文档。一些随便写下的笔记就可以了，甚至拍一些白板上不同阶段的照片也行。我保证你在整个信息结构建立的过程中，肯定会忘记当时做某些决定的原因。
【随着时间而改变的信息结构】
一些网站的信息结构是随着时间而改变的，因为其中很多类别的内容是建立在循环的基础上的。举个例子，UX Australia conference（译者注：http://www.uxaustralia.com.au/）的网站在一年之中随着各个里程事件的达成而改变。
如果你的站点也会随着时间以周而复始的方式变化，或是会增加额外的内容，记得把这些包含进你的信息结构中。
【信息构架中的排序】
你要考虑的另一件事事信息构架中的排序问题。在大多数情况下，这个顺序是很简单就能想到的——它们会有一个自然的顺序。有时候这个顺序是按照重要性程度定义的，有时候分组会结合在一块形成自然的子组，看上去就像它们就像一个整体。
最糟糕的情况是你按照字母顺序排序——字母顺序对于A到Z的那种列表（当人们在完成一个已知项目的信息任务时）是不错的，但是它不适合导航项目。字母顺序本质上是随机的顺序。因此，你还是得花些时间来找寻一个有意义的顺序而不是懒惰的默认为字母顺序。
