信息架构的概念 - UCD大社区

信息架构的模式

hoowolf — 2012-03-28 09:04:49

最近忙着毕业设计，需要文献翻译。本想随便那之前翻译的交个差，但总觉不够严谨。我的毕业设计主要是帮老师的研究所做个网站，本来已经有网站了，但老师和我都觉得老版本的网站很是陈旧。于是毛遂自荐。

网站需要重构，自然信息架构部分也是重要的一环，虽然之前也看了不少，比如《下厨房的搜索OR分类之思》即是思索的痕迹，但还是系统地翻译了Five Simple Steps团队著作的《A Practical Guide to Information Architecture》其中一个章节：《IA Patterns》。（对于这本书，网上有PDF文档流传，由于个人洁癖，就不贴出来，需要的可以留言。另，需要本章节PDF的亦可留言索要。）

——Start——

这一章都是关于信息架构的模式——主要是针对不同类型网站的信息架构所需的一些通用方法。希望能够抛砖引玉，当你构建自己网站的信息架构时，能够从这些模式着手开始。当然，前提是你的网站得符合这些模式中的一类，或者是他们的结合。

模式是什么

一种模式即是对于一类频繁遇到的设计问题的通用解决方法。

模式的思想来源于建筑[1]。正如你所想像的，建筑物有许多普遍的问题等待解决——食品准备区和食品服务区间的关系，人们如何进入一幢建筑，以及房间的内饰怎样与屋外和谐相处等等。

模式在软件开发领域也非常普遍（一些问题屡次出现），提供一些软件设计的解决方案给开发者们。交互设计也同样如此，一些可复用的解决方案浮出水面，通用的需求譬如有登录表单和分页设计。

模式中很关键的一点是这些想法都是来自真实世界的需求。你不必坐下来冥思苦想，为一个全新的领域创建一套模式。以下我们讨论的模式都是“劳动人民”智慧的结晶。

信息架构模式

信息架构与人们需要使用信息的很多领域都有关。下面我将阐述每个模式的特点，使用场景，并提供相关案例。

首先我将讨论四种简单模式（层级、数据库、超文本和线性）以及三种的结合。

简单模式

层级

在层级的概念中，类目之间关系是父子关系或者广义与狭义——即抽取为更广义的群组或者是分解为更具体的群组。

层级结构可以描述为扁平式和锥形式：

扁平的层级结构特点是：顶层有很多类目，但层级数较少；
锥形的层级结构特点是：顶层类目较少，但层级数很多；

一个层级结构也可以描述为严格型（strict）和多元层级型（polyhierarchy）：

严格型层级中，一个类目只能处于一个位置；
在多元型层级中，一个类目能够置于多个位置；

现实世界里，严格型层级结构是必须的——毕竟一个实体一次处于不同地方是不可能的。然而，在数字世界里，我们很容易就能让一个东西置于很多地方，且很好的解决了现实里类别混乱的局面。我们能够将东西放在期望看到的多个位置，并且允许类别边界的重叠。

层级结构是组织信息所使用的最简单和常规的方法，适用于内容范围很广。尤其适用于小型站点，仅仅需要一些简单的层级——顶层（首页），一些二级页面和底层的详细页面。

同样，层级结构对大型站点也适用。尤其是那些内容型的网站（内容杂乱多样）。即使你的信息复杂度各异，层级结构也有作用。例如，你首先可以展现综述信息，然后允许用户根据需要细分出更多详细信息。

3次点击的“魔咒”

很多年来，一直有个“传说”：每个具体内容从首页进入时都应该少于三次点击。

对于很多网站来说，这简直是天方夜谭。按它这么操作，很多网站每个层级的类目将会多的让人无从选择。

相反，更重要的应该是让用户在每个层级都能轻松决策，并告知其处于正确的路径。如果用户觉得自己的操作是正确的，那么他们会按照自己的意图进行浏览学习。

图片16-3：CHISIG(Computer-Human Interaction Special Interest Group)是一个小型的组织且信息量也很少。简单的层级结构就很有效。

图片16-4.白宫官方网站有许多内容，但仍然采用了基础的层级结构。（whitehouse.gov）

数据库

这里讨论的数据库并不是一种技术对象——各种信息的数字化存储，而是一种概念模式。

它们的相同点都是具有特定规划的结构或模型，所有的信息都必须来适配于这些结构。所以你不能强加一些不适合此模型的东西。

数据库模式针对的是具有一致性结构的内容。有些内容可能与其他的没有直接关系——它们确实不具备层级内容里所需的父子关系——但是它们都由相同的内容块组成，拥有相同的结构。

例如，etsy网站，这两个类目没有任何共同点：

图片16-7. Sleepy time (来自esty.com)

图片16-8.Headbands (来自esty.com)

但是它们具有相同的内容块来构成列表：

标题
描述
标签
材质
位置
付款方式
创建日期
照片
类别
颜色

即etsy上的每个产品都是相同的结构。

数据库模式应用场景要么是较小的信息集，要么是很大的数据集。

数据库结构最大的优点是一次性储存数据，然后可以使用不同的数据块和方式来展示信息。例如，在etsy里，你可以通过类别、颜色、位置甚至是最近更新（很小的层级）来寻找内容。这给了用户很多途径来发掘他们自己感兴趣的信息。

数据库结构适用于音乐、产品目录、书籍、文章、博文等等具有一致性结构的内容。它为用户提供了很多进入内容的入口。例如，flickr（flickr.com）中，你能够通过摄影者、相册集、小组、最受欢迎和标签来发掘照片。

元数据

元数据通常被定义为“关于数据的数据”或“关于信息的信息”。这种定义虽然不是很有帮助，但是很准确。元数据就是所有的与内容块相关以及描述内容块的信息。

有三种不同类型的元数据：

固有数据（Intrinsic）:对象实际是什么
管理型（Administrative）：它是如何使用
描述型（Descriptive）：类目的描述

比如UX Australia博客，元数据可能包括：

类型：博客发表的文章（固有数据）
作者（管理型）
发表时间（管理型）
URL（管理型）
状态：已发表（管理型）
标题（描述型）
分类（描述型）
标签（描述型）

这些元数据主要用于两件事情：

生成特定的内容列表（例如，展示‘Announcements’类别下的所有内容）
选择页面中需要展示的内容（例如，包括标题、作者、描述、分类）。

当然，项目最困难的部分莫过于决定收集哪类内容和他们的内容是什么（或者你将使用哪些分类）。

超链接

超链接模式是信息架构中很有趣的部分，因为它似乎是一种反结构（anti-structure）模式。内容块仅仅根据相互关系来进行连接。与层级或数据库不同的是，不存在主结构——内容仅仅通过链接进行连接。

超链接结构最佳案例是维基（wiki）。维基没有预先规划的结构——内容仅是通过内嵌的链接产生联系。

维基百科（Wikipedia）就是最好的注解。维基百科的内容并没有主架构，也没有很健壮的数据库结构。（没错，他是储存在数据库中，且有一些基础的数据块，例如表头、描述等。但是它不是上面所述的“数据库结构”。）每个页面都是独立的，通过相关链接与其他页面进行连接。

如果内容已经创建了一段时间，但你仍然不确定构建的东西，那么超链接结构特别有用。在这种情况下，预先确定详细架构甚至是为网站确定基本模式都是不可能的。许多文档项目都是这样起步的——人们首先写出独立的文档页面，然后忙着通过链接来创建文档关系。

许多网站开始时都是超链接结构，当内容确立后，才进行重构。

超链接结构的主要问题在于：该模式的成功很大程度上取决于人们在内容块间创建的联系。对于层级结构，你能很清楚地看到下一级；对于数据库模式，你能展示一种特殊类别的所有内容；但对于超链接结构，它本身并没有能力自动展现关联内容。如果作者没有创建链接，用户就根本有办法发现信息。

线性

线性模式，顾名思义，按照直线规则一个跟随着另一个。

线性模式并不常见——通常使用该模式是为了用户能够按照他们所理解的方式跳转内容。

如果你遇到一种情境：当用户转移到另外一件事前，必须先理解一件事情，那么很适合使用线性模式——通常例如，教学资料。如果用户实际并不需要按特定规则阅读的话，就不要使用线性模式了，否则用户会有一种挫败感。

[译者注]

苹果官方的“Start Developing iOS Apps Today”文档中就是利用了线性模式，显然iOS开发的学习是个循序渐进的线性过程。

混合模式

现在让我们看看如何结合这三种简单的模式来创建更复杂的信息架构。他们之间会有重叠，所以不要纠结于你的网站到底属于哪一类模式。

“简单等级+简单数据库”模式

一种很常见的模式就是简单的层级结构与多个数据库式内容的结合。

这种模式适用性很广。你可以针对基础内容创建网站的层级结构部分，然后利用强大的数据库模式将具体信息与某部分集成。当然，也可以是其他任意组合。

案例分析：UX Australia

图片16-17. 会议网站——一些内容页面安排在了一个小的层级结构中。

图片16-18. 展示部分使用了数据库结构——这个索引页面说明了标题、演讲者、简短概述、A-Z顺序排列。每个链接都指向一个详细内容的展示页面。（www.uxaustralia.com.au/conference-2009/program/presentations）

这种模式的主要挑战之一是决定哪部分转化为结构性内容，哪部分留下作为层级结构内容。可有如下考虑：

你想在网站的另一部分再次使用某类内容？如果你没有二次使用的需求，那么就不必担心过度组织的问题——完全是小题大作。
数据库结构能帮助你管理大量信息集。如果你一年内有很多新闻故事素材，你能够将之视为层级式内容进行管理。如果一天内有上百条，你可能得利用数据库结构来进行自动展示了。

中心辐射型（星型）

中心辐射模式归根结底也属于层级模式的一种。然而，这里想单独阐述是因为人们使用的时候还是与层级模式有些许不同。

在层级结构中，人们倾向于从顶层（首页）开始，一级一级向下浏览内容，经常是徘徊于层级结构下的某个分支。而中心辐射型结构中，人们会从一个层级进入到另一个具体信息，然后返回出发点（中心点）然后在进入到其他详细页面，如此往复。例如，对于LinkedIn，个人页面就是一个中心点——它是你经常流连徘徊的地方。

子站（Subsites）

我参与过很多大型网站——政务网站、大学教育网站等等。我用的最多的一个模式，自称为“子站点”（曾有一段时间，人们称之为“门户（portals）”，但后来就销声匿迹了）。

很显然，整个网站都是有一系列子站构成，并通过首页或多个顶层页面连接起来。子站可以应用任何模式，也不必局限于同一种。

在一些应用场景中，子站点都是使用统一的导航和页面布局，潜移默化地表达一种观点：这些子站点是品牌网站的一部分。当然，有些实践方案的导航和页面布局往往会考虑内容和用户的感受而略有不同，但是仍然会通过一些细节处理来展示其整体效果。

该模式特别适用于大型组织结构——往往拥有许多职能部门或者很多子品牌——但有需要以一个整体的效果呈现。此外，内容分析后，如果你不能找到一种单一的模式解决各部分的信息架构，那么你就应该考虑“子站模式”，而不是强迫套用某种模式。

正如你所想到的，大学网站是个很好的案例——大学作为一个整体代表了一个组织和品牌，但内容多样，每个学院和组织机构都有特定的交流沟通需求（包括对象、政策等）。政府机构也是一样。例如，ABC（Australian Broadcasting Corporation，澳大利亚广播公司）旗下拥有很多电视台、广播站、新闻以及其他网络服务。

图片16-28. 对于ABC，首页承载了许多子站点的入口。

集中入口点（Focused entry points）

很多大型站点，不可能以一种单一的方式组织内容就能满足所有的用户——所谓众口难调。

面对这种情况，我通常使用“集中入口点”模式。首先我都会根据内容和核心用户确定一个适用于该站点的信息架构模式（层级结构居多）。

然后，假设一些用户不会通过主信息结构来寻找信息，我会有意提供一些入口点来帮助他们发掘有用的信息。这些入口点不必覆盖所有站点内容——专注核心信息即可。

我曾说过一些分类组合很难使用——特别是用户组合和任务组合。我发现入口点很好地解决了该问题。例如，你先运用基础的层级结构组织网站内容，然后为不同的用户或任务提供合理入口。

案例——澳大利亚的水

澳大利亚政府的“水”主题网站包含了很多政府政策和相关大纲。当然，政策和大纲并不总是这么明显——一些人可能很了解（如相关政府人员和媒体工作者），但是很多人都很无措。两类人都需要找到自己关心的信息。

这个网站是个运用“集中入口点”模式的典型案例。主信息架构是简单的层级结构，围绕政策和大纲进行组织：

图片16-34. Water policies and programs，作为类别分组显示出来了。

话题式入口，比如脱盐（desalination）、雨水贮蓄池（rainwater tanks）和节水（saving water），提供一些用户感兴趣的话题入口：

图片16-35. 话题入口页面——链接贯穿整个网站

标签（Tagged）

标签模式无论在基础的数据库模式或者是超链接模式中都有所运用。网站中的每个类目都利用关键词作为标签——而它们同时也是内容的入口。

标签可能是内容原作者添加的，也可能是其他具有权限的读者（例如同一团队成员）。

这种模式适用于大量不同内容的作品集，特别是内容读者都具有很不同的观点和想法。

当用户感觉无从下手时，标签能够帮助用户探索和发现相关的信息。例如，Flickr列出了所有的标签，你可以根据一个特定的标签找出所有相关照片——摄影师和访问者都有权添加标签。

	适用内容	适用内容	挑战和话题
层级	拥有各类内容的小心站点	习惯先阅读概述信息，然后详细内容	平衡内容的广度和深度
数据库	内容具有一致性	想通过更多方式进入内容	所有内容需要适应于结构，且不要收集超出需求的元数据
超链接	培育阶段的内容	追随相关材料的链接	作者需要了解链接的内容；当内容完成后，可能需要重构；
线性	顺序性内容	用户想按照特定顺序理解某些内容	只有当用户必须按顺序阅读时才使用
简单层级+数据库	综合性内容加上具有一致性结构的内容类型		区分出哪些内容需要结构化，哪些不需要
目录	大量结构性内容集	寻找特定类别，然后顺藤摸瓜查看具体产品
中心辐射	分级内容	用户每次想回到中心页面，然后在查看新的内容
子站	大型企业和政务站点，需要许多独立的内容版块		考虑子站是否需要统一的导航、页面布局和品牌
集中入口	任意均可，但通常层级	用户想随心浏览，且没有最好的方法
标签	大量内容集	根据自身的定义发掘信息；轻松找到相关信息；	谁有权限进行标签操作

[1] 最著名模式方面的建筑著作是Christopher Alexander的《The Timeless Way of Building》（1979）。

[2] 目录模式更多信息可以参见Jared Spool的文章：The 8 Types of Navigation Pages和Galleries: The Hardest Working Page on Your Site。另外，也可以参考Jared和Robert Hoekman Jr合著的《网站设计结构——有效的交互设计框架和模式》（Web Anatomy: Interaction Design Frameworks that Work）。

网站信息架构实践方法

千鸟 — 2011-12-01 22:56:40

十几年前高中时，为了管理书架上的图书，把图书分门别类做好索引和编号，比如“小说”取首字母XS开头为“XS013”。手工贴好标签，并规定所有取书的人必须放回原处。网页设计做了六七年后，偶然在学术论文中看到，原来当年发明的事情有个专业术语叫“图书馆学”。把这两者结合起来思考，对网页&网站设计本质的理解豁然开朗。

2006年5月写过一篇网站的信息架构算是最粗浅意识形态，中间引用了人民大学周晓英教授的部分内容，不想引来狐朋狗友的奚落。更没想到的是，居然被周晓英教授看到，然后留了一大段文字解释。再后来这朋友亲自上门道歉，我也把相关内容都删除了。这事给我很大的触动，原来互联网时代学术界离业界如此之近，而国内从2003年前后才开始涉足研究此领域，我是近两年才搞清楚。几年实践下来，我总结影响对专业技术理解有三个因素：宽度、深度、积累：

宽度指视野，需要对大量新鲜内容的发掘和观察，或者有效业界沟通。尤其不要局限在中文环境里，欧美英文网站水准普遍偏高，亚洲的韩文、日文网站也很有特点。
深度指理论，注意从实际中总结理论，而不要理论先入为主的去反证。学术论文虽然枯燥，整体质量要比业界同行总结含金量高很多，只是特别生硬几乎都不落地。需要一定的实践功底来消化。
积累指经验，不仅包括前两点，经验还需要总结和沉淀。目前的商业设计其实绝大多数都没有太多技术含量，但鲜活的商业案例无疑是诠释理论的最好补充。

信息架构原理的四大体系：组织系统、标引系统、导航系统、搜索系统。我对《Web信息架构》的此总结比较满意，能引导我不断深入理解，唯一不爽是中文版对label“标签”的翻译。就此，我与本书中文技术审校范炜先生沟通过，并从2008年至今保持有联系。他说学术界与业界观点一致，需要为label另寻译法。而我推荐的“标引”（之前我翻译为“标记”）动词性第一，与“标签”的名词性搭配有异，目前并无定论，想法仅供同行参考。

接下来我们尝试准备把业界与学术相结合，一则强调理论与实践相结合，二走中文本地化路子，把老外的理论在中国网络环境落地。提炼并保留一些经典案例，利于后来者继续深入研究。而针对这些年接触信息架构、从事信息架构、理解信息架构的过程。以我为例总结实践经验如下：

了解客户端技术原理

客户端技术可以促进对整个Web构成体系原理的了解，一定程度上加速对信息架构的认识。2001年在flash如日中天的时候，我选择从HTML开始学习web design，那个时代的学习都靠拆解别人的页面来逐条代码分析。从2004年网站重构开始，“结构+表现+行为”三层分离帮助了我正确认识网站本身与“内容”的关系，为后来的“元数据”打好了基础。我对flash的不感兴趣，源于与“信息系统”内容组织原理的相悖，当然随着理解加深，是越来越不感兴趣。而如今移动互联网时代，HTML5几乎已经完全盖过flash的风采。2010年4月Apple公司认为flash已经走向末路，2011年11月Adobe公司直接放弃移动设备，我为当年的选择深感欣慰。

对信息系统应用的大量实践

最早我们搞“网页设计”，完全没有对所谓“信息系统”的认识，如同目前绝大多数IT从业者不知道IT是Information Technology简称一样。以现在的理解来看，我最早接触的信息系统是2001年底留言板和动网BBS系统，2003年和2004年左右动易CMS系统，2005年市面上绝大多数BLOG系统，2006年使用Wordpress的BLOG系统一直到现在。改过无数模板的风格和内容，其实就是表现层、框架层优化，涉及到了信息元数据。

手动管理成千上万条信息

这种事情绝大多数同行不屑去做，技术含量低，且投入产出比不高。2005-2011年我曾经在两个系统上投入过大量精力手工干这种粗活，开始通常是没人做，恰好我做这种事情又特别有耐心。做多之后反思，越想越觉得有价值，一方面最笨方法往往能换来最扎实的基础，另一方面最笨方法做出来的内容质量确实最高。此类工作枯燥之极，但可以强迫自己去深入思考，高压环境下对传统专业知识，对“内容、信息”的理解绝对深刻。

全程主导设计信息系统

在有足够基础知识和辅助经验之后，需要实践来验证，或者说这是相辅相成的过程。信息系统的大小无所谓，关键要看技术含量，比如Wordpress这样精巧的系统如太大反而没意思。设计过程中尽可能的考虑长远，是对自己能力的一种锻炼，其难度本身也是对方案灵活性的考验。信息架构的工作很多属于铺垫，并不是马上就能出效果，其优秀在与本身可以规避很多问题。而不是制造各种隐患，让交互设计再来解决。

巨量搜索请求观察

从全网大型搜索引擎开始，主要指Google和Baidu，不过显然应该以Google为主。随着我们学习新知识就应不断积累起搜索技巧，并且可以很自然的学习到“搜索引擎友好”相关知识，传说Baidu很多产品经理都有关键词搜索的固定指标。我从2008年用淘宝比较多开始，发现购物搜索也很好玩，因为淘宝搜索本身也有“竞价排名”因素的存在。长期实践，我从淘宝里可以迅速找到各种稀奇古怪的冷门商品，并且经常一页页翻完100页搜索结果，某些关键词不明确的商品只有这样才能找到。有时我真会认为，咱们搞信息技术、信息系统的人，应该能够比普通从业者更快速获取信息，更准确查到信息，以及更有效判断信息。

相关话题：信息架构的概念源地址：http://blog.rexsong.com/?p=14079

信息架构中信息类粒化简谈（二）

蜗牛也是牛 — 2011-08-02 15:25:24

上一篇（信息架构中信息类粒化简谈（一））写的简单了，大家看了都没有什么感觉，好吧，我承认，我弱智了….今天写的希望大家能看上眼，哪怕一个白眼….
说到信息架构，粒化能帮助我们较快的实现标签系统，大家知道标签系统与组织系统，搜索系统，导航系统共同组成信息架构，个人认为还要加上网站布局，因为布局本身就在指引用户的视觉并做操作引导。也算是信息架构的一个部分。

情景化的信息架构方式，就是模拟我们现实生活中的一些情况来大致拟定信息层次和粒度，例如我们去美食一条街，什么吃的都有，烧烤，西餐，徽菜，麻辣烫，特色小吃等等，生活中一般还有红灯区在这些美食旁边映衬着，这给这条街的美食运营带来很大方便，因为这是需求的延升，所谓食色性也（但是网站千万不能这么运营，网警会把你整死），我们在做餐饮类网站的时候，可以模仿这条美食街的美食商家组织方式，明显是按照服务的内容与店名区分的，用户在这条街上走的时候，如何选择哪家饭店，这就是用户心里与用户对展现的信息进行筛选的过程，一般用户选择哪家饭店考虑的因素有哪些？店名与服务类型的匹配程度，表现的是否直接，一家海鲜美食餐厅的名字直接与服务内容的关联性，可同时用餐人数，装修档次，主营餐饮类型风格，消费水平，促销，停车位等等，这些元素是影响用户决定的主要因素，也应该应该是最低的一层，用户做信息筛选的时候或者信息阅读的时候所能给用户带来的最主要的价值，满足用户直接的信息需求。

我们面对这样的场景如何让将其转移到网站上，首先我们我们就需要根据用户的需求就行分析探讨，确定影响用户行为的信息元素有哪些，并将这些元素做排序，简而言之就是所谓的认知实践对象，然后与完成实践对象的物理过程。模拟现实生活的物理模型，映射到网站的信息架构，建立信息的映射模型，因为用户的对互联网的认知还是基于现实生活，就如你在搜索引擎搜索信息的输入关键字还是依据你的日常生活，搜索”暑假补习学校”，不会转化到其它的代码进行输入，直接按照我们的日常生活的习惯就行，搜索的分类目录还是依据一定的标准进行索引，还是基于我们的生活，现实情景的生活。我们做的信息提供，那种最合适的那种信息组织架构方式将信息传递到用户面前。用户是信息的需求者，要直接的看到他们想要的，信息的匹配就关系到信息的组织形式，用户就像嫖客，不想花大钱，还想爽的快活，追求那种低劳动成本获得做大的效率。我只能陪着笑脸说换下一批小姐….

信息粒化层次

我们看某某网的餐饮店的信息筛选方式与信息粒化的例子：

大家想想这些粒化的信息哪些能给你去寻找你目标预期，菜系，适合用餐场合，风格等均有描述，但是缺少价格这个核心信息，因为很多人价格这块比较在意，我就是一个，因为消费太高可能不是我能承受的，我能承受在50元/人左右。毕竟在这个物价飞涨的年代，工资不涨反而可能下降的情况下，我必须夹紧屁股消费….（可能价格也是一些商家的商业秘密），在对用户决策有影响的信息这块我们必须在信息的架构与粒化的情况下体现出来，往往也是以为这个因素，我们就放弃在这个网站的上下一步行为….例如一些租房类网站，地段，楼层，房屋类型，房租多少等等，这些都是基于用户的日常生活而来，租房的人的需求是什么。主要考虑的有哪些，租房的朋友都清楚，我看中的第一个是离我公司的距离，然后是房租，再到配套设施，信息来源，合租的人情况，这些都是我们在进行网站信息架构下信息粒化的深度。

网站信息架构下的粒化最后还是我们生活的真实映射，反映到用户身上，解决用户关心的问题，他们关心的信息才是我们需要做的，搞了半天用户说这TM的和我没有半毛钱关系。那情何以堪…..来自生活，回到生活…

相关话题：信息架构的概念源地址：http://www.webiwen.com/archives/99

web信息架构和社会化

tony — 2011-06-20 18:55:48

大家都喜欢PPT，那就分享吧。

这个演讲稿实际有34页，拆分“动作”之后变成63页面。
下面是简单的解释，为了给书友会各舵主使用的，都分享出来吧。
真害怕误导大家，喜欢速读的朋友直接阅读61页，就可以了。

第1页
web信息架构这本书是十几年前信息数字化沉淀下来的理论体系，而今，互联网的发展让用户从当初的简单消费到深度参与。这次演讲的内容，主要不侧重说概念，而是说如何构建一个让用户深度参与的信息系统。

第2页
网上经常遇到留言，说没有干货，那就提前申明一下，这次照旧没有干货。

第3、4页
北京报名的问题库，现场也可以继续提问题。（新浪微博活动功能不靠谱！）

第5页
一个信息系统，每个人都有自己的想法，谁对此负责，统筹这件事情？

第6、7页
在没有深度实践，对过来翻译的理论存在理解的偏差。

第8、9页
维基百科其中对信息架构定义的一个版本。

第10页
信息架构的位置，与交互设计、导航设计的关系。

第11、12页
有很多术语和名词，《web信息架构》中都有，我们这次重点并非翻译这些概念，有不理解的，可以现场交流。

第13页
设计师通常的设计过程是按“逻辑页面”、用户使用流程、用户用例谈体验，而对于一个内容网站，核心的体验却是内容本身，内容本身是什么，周围的关系是什么，如何组织它们。

第14页
从宏观来看，信息页虽然被设计师抽象成“一个页面”，但实际上，成千上万的内容，是用户的目的地。随着网站的发展，越来越多的用户，他们知道你网站的第一个链接，是内容页，而非首页。

第15页
视图1：单个用户通常对整个信息系统的视野，仅仅是他感兴趣+他能力范围可见的一个部分。
视图2：真实的情况是，每个用户都只能看到部分，而你如何让这个系统对每个人都有效。

第16页
是上页面的延续和总结

第17页
是豆瓣09年的用户真实访问路径的一个可视化视图。
圆的大小代表热门曾度，箭头代表从A类页面到B类页面的概率大小。

第18、19页
通常，内容网站的方法，业内很多专家会告诉你，你应该做SEO、做社会化营销，要推广你的内容。相比较如何优化你的内容本身，大家更加热衷制造流量的高峰。

其实关于SEO，无非是搜索引擎关于信息架构的规则输出，而且是基于搜索友好，基于各个领域信息的最粗略版本的规则。关于社会化营销，依然如此。

那些奇技淫巧被“专家”捧得太高，不断优化网站的信息系统才是核心的竞争力。

第20页

这个页面主要是阐述两个纬度：
1 自然属性：单则信息+信息与信息之间的关系（在没有用户参与前提下，信息天然就是如此）
2 社会属性：从信息的产生=》最终用户的消费（他们如何参与到这个系统里面）
小号字是这几个纬度在设计中要考虑的要素。

信息粒度：举例“歌曲”、“专辑”，“相册”、“照片”。
元数据：信息包含哪些字段。
规模：信息数量有多大。
时效、长尾：内容以什么频率更新，用户的注意力是聚焦还是分散的？例如：相比上百万人同时关注上映的几部电影，书籍的注意力就显得长尾一些。

传统和数字化：这类信息在没有被数字化之前，市场情况如何，用户习惯如何。数字化之后呢？
利益链：内容是由谁产生的，他们生产信息的动力是什么，谁来帮助传播，能否抵达最终消费用户？举例：房产信息网站
情景：用户在什么情景下查找信息，用什么设备？
消费周期：每天？每周？每月？每年？还是一竿子买卖？
社会化方式：在消费信息的过程中，用户愿意做什么，是否需要交流？

第21页
关于一个西红柿，大家对此的说法都不一样：
有别名
有错别字
被加工后的状态
增加定语后的样子
甚至有些定语加上去，对于用户来说是两样东西：小西红柿。这些是通过简单的技术分词，无法处理的领域。一个好的系统，需要把这些“看法不一”规则化。帮助用户查询，也帮助信息建立关系。

另外，关于西红柿
每个元数据，都可能让信息和信息之间建立联系。
西红柿和西瓜，不是因为他们都是水果，而是因为他们都是夏天的时令食材。
西红柿和鸡蛋，因为大家经常用他们搭配。
…
通过处理元数据，找到信息和信息之间的关联办法，关联的强弱。

第22页
除了了解信息，还需要了解你的用户。图中是下厨房的用户模型，数据比例当时是猜测的，实际情况是产生内容的人要远远低于这个百分比。

第23页
做信息架构讲究深入浅出：
自然属性的深度，决定范围，是不容易迭代的，需要全面和深入。找到信息和信息之间的现有规律。
社会属性是给产品建立竞争门槛的，你期望用什么样的规则，来引导用户如何使用你的产品。

下面是这些要素的一个递进的过程。

第24页
构建一个信息架构的顺序。根据这些要素，一步一步地迭代。

第25页
在用户浏览地过程中，用户愿意为这个系统wiki什么内容？
豆瓣的一部电影也许有500W人访问过，得到近20W人的评分、近10W人的短评、几千人的长篇评论。
这些转化率是固定的吗？是否可以平移的呢？
不一定：
有些书籍是有社会化效应的，用户愿意为此交流，但对于很多教辅、母婴类畅销书籍，用户并不需要这些社会化功能。

第26页
这页主要是想说，利用用户的相关行为，如何帮助用户计算出相关的，可能感兴趣的东西。
而所有这些相关，都需要探索和试验。

第27页
一个信息系统，重点在于是规则让信息变得有序。

第28、29页
淘宝的将各种纬度的信息罗列给用户的方式，信息的各种纬度也都考虑到，但这感觉，就好像用户在使用一个机器，你把零部件全部暴露出来。这并不优雅。
印象中淘宝在分类体系的“交互层面”，做了很多很多的大小改版，调整分类的交互，搜索的悬浮窗口。

29页举例：商家总把一些信息杂音增加到标题，甚至图片上面，为什么？是不是规则的设计不合理？这种对用户甄别信息是否有帮助？有没有什么办法解决呢？
一个好的信息系统，不要让商家去想那些奇技淫巧做注意力，而是让商家只管卖物美价廉的商品，谁的服务好，谁就得利。

第30页
优雅的架构：一个复杂的系统，不是要让用户觉得复杂，用户只需要知道，他要的你能给。你怎么给的原理，他不需要知道。

第31、32、33、34页
就不解释了

相关话题：信息架构的概念源地址：http://uitony.com/?p=196

叙词表

CDCer — 2011-06-13 13:08:19

说叙词表这个名词之前，我们先来看看下面这些日常见到的吧。

漫画人物表：
常见于漫画书开头部分，描述角色形象与对应名字，帮助读着搞清谁是谁。

摘自漫画《圣斗士星矢》——车田正美

世界杯小组赛分组表：
用于介绍世界杯小组赛各队分组情况，描述组名与球队的包含关系，让观众一目了然了解赛事。

西餐菜单：
点餐之前不看不行的东西，描述类别、菜名、所含食材、价格。话说西餐菜单的食材描述着实是make sense的。

以上列举的漫画人物表、世界杯小组赛分组表、西餐菜单正和叙词表有着很大的共性，都是正式开工前的必备工具。可以把他们理解为叙词表的各种变形体。言归正传，在项目里的设计阶段，我们很容易遇到对产品某个局部称谓不统一的问题，或者即使内部称谓统一了但是向用户传达又不靠谱的情况。于是，设计师与产品经理就会着手整理一份叙词表（也就是术语表），帮助规范术语。

什么是叙词表？
简单来说，叙词表就好比《新华字典》，是一本能查到什么是什么的工具书。遇到奇怪词汇，人人都有意识到里面去查阅的地方。

Msdn（下图）大家都熟悉不过了，她就是一个典型的叙词表，以索引形式列出各种术语便于用户检索。

叙词表的历史:
“其实叙词表的发展已经有一段很长的历史。这么丰富的历史可以让我们从一堆国家标准和国际标准中汲取经验，包含单语种叙词表的构造。例如：
ISO 2788 (1974, 1985, 1986, 国际标准)
　　BS 5723 (1987, 英国)
AFNOR NFZ 47-100 (1981, 法国)
DIN 1463 (1987-1993, 德国)
ANSI/NISO Z39.19 (1994, 1998, 2005, 美国)”
摘自《Web信息架构-设计大型网站》

ANSI/NISO Z39.19的标题如下图，“单语种受控词表的结构、格式、管理规范”。

摘自文档

文件中受控词表说明部分以叙词表方式呈现，左术语右定义（如下图）：

摘自文档

ANSI/NISO Z39.19规范的目的是为检索系统和网站导航提高信息存储效率，同时确保描述一致性。她主要梳理了多词同义与同词多义的术语。多词同义例如：VHF与Very High Frequency同为高频率意思。同词多义例如Mercury在不同领域可解释为水星、水银或者精神等多种意思。该规范主要从定义范围含义、用等价关系链接近义词、区别同形异义词来管理词表。

技术行话
专家沟通时，专业行话能带来效率和专业性，不过考虑到教育成本，也不妨采用朴实易懂的词汇。下面列出的行话大家知道即可。

优选术语（Preferred Term, PT）
也称为可接受术语。所有关系都是根据优选术语定义的。

异形术语（Variant Term, VT）
等价于优选术语，或者大致上与优选术语同义。

上位类术语（Broader Term, BT）
上位类术语是优选术语的上层术语，在等级中的高一层位置。

下位类术语（Narrower Term, NT）
下位类术语是优选术语的子术语，在等级中的低一层位置。

相关术语（Related Term, RT）
相关术语与优选术语为并列关系，同为上位类术语的下层术语，用相关关系连接。

将以上结构用英文缩写再缩写后得到一个单字母小模型，结合方位关系便于大家记忆。这也是ANSI/NISO Z39.19术语结构的精髓部分。

语义关系
叙词表的术语之间包含着比较丰富的语义关系，我们来深入了解一下：

等级关系

从图中十分明了地看出A包含B的等级关系，可以写作：A NT B （NT即下位类术语）

术语的等级关系会有三种类型：
属
同生物学“界门纲目科属种”关系。例如：鸟 NT 鹊

整体-部分
局部B是整体A的一部分。例如：脚 NT 大脚趾

实例
B是A的一个实例。例如：海 NT 地中海

等价关系

图中的等价关系可以是同义词、近义词、缩写、词语变体等。可写作：A VT B （VT即异形术语）。例如：70-200 f/2.8 L USM VT 小白；70-200 f/4 L USM VT 小小白；70-200 f/4 USM IS VT 爱死小小白（这里的小白、小小白、爱死小小白是指佳能的几支经典长焦镜头，这些名词在摄影圈算得上“术语”了）

相关关系

同类别中并列的部分，用相关关系连接。可写作：A RT B （RT即相关术语）。例如：小小白 RT 爱死小小白，小白，爱死小白，大白（你们懂的~）

其他写法
用（Use, U）
即：异形术语用优选术语。中文也可以写作：“见”（See）。

摘自文档

代（Used for, UF）
即：优选术语代异形术语。
原则：
If Term A Use Term B, then Term B UF Term A.
例如：
outline USE shape
shape UF outline

总结

以上我们主要了解了ANSI/NISO Z39.19叙词表的发展史，术语行话，术语关系模型，以及一些常用的语义关系和写法。结合项目中应用到术语表的话，我们还需要根据实际工作的情况灵活的运用这些规范，避免因沟通和理解的问题导致术语表的推动效果受到影响。

参考文献：

相关话题：信息架构的概念源地址：http://cdc.tencent.com/?p=3927

也谈信息架构

94smart — 2011-05-31 08:57:29

关于信息架构，其实我也不大懂，我就看过两本中文翻译书和一本很学术的中文书，我一直认为信息架构是数据结构的另外一种叫法。

结合Tony的信息架构扫盲贴，我也扯扯信息架构的东西：（顺序可能不妥，请见谅）

每个网站产品都需要规划信息架构，包括检索、标记、导航、展示等，在产品最开始规划时就需要做，且后边规划功能时针对需求进行调整。
信息架构需要和真实信息尽量匹配，比如做个游戏信息库，每条游戏信息需要完整还原真实的游戏信息结构，包括名称、开发商、上市时间、分类、题材、介绍、图片等，奉行够用就好是不行的，关键信息一定要规划进去。
信息可以有很多种维度，只是有些适合于检索/标记，比如分类、题材，有些只适合于展示，比如图片。
信息架构最后可能变成数据库表的结构设计、页面结构，变成SQL、XML或HTML等。信息架构的工作被编辑、产品经理、开发经理/项目经理覆盖了，所以国内没有单独的IA职位。
信息架构和UGC不冲突，当然分析内容并结构化的工作比较困难，不能指望用户全部按照结构化的思路来提交。
标签Tag是个民意化的标记形式，但不能替代信息架构里的主要标记系统。

暂时想扯这么多，以后再补充。

信息架构

tony — 2011-05-29 17:47:11

写几篇关于信息架构的文章，系统地输出我理解的信息架构。

写在前面的话

发了一篇关于招信息架构实习生的博客，收到不少简历。
但谈起信息架构，多数不了解，稍微了解的扯了很多很偏的东西。

随手搜索了一下，我发现了原因：
1 《web信息架构》这本书太概念，太学术。多数人不知道如何指导实践。
2 有人绑架了“信息架构”这个词，拿出去唬人，内容都是皮毛或者是根本和信息架构不沾边的东西。

另外一个理由是，《web信息架构》06年出第一版，而这本书的最早版本是1998年，而真正的理论形成，我的推测还要往前推很多年，基本上可以推测是“信息”遇到“数字化”的年代，那个年代成就了很多科技公司。

我知道国外关于IA是有专门的职位的，并且有的组织是专门研究这个领域，包括很多大学教授、各大公司的用户体验工作者。说实话，我没有太多地关注具体内容，但我觉得，我们把老外十几年前的理论奉为圭臬，而信息架构是设计领域非常底层的事情，它会随着技术和产品的变化而变化，中国网站的设计为什么鲜有创新，我相信在这个层面可以找到一些原因。

技术开源，让国内的技术水平很容易和国际接轨。
设计也需要开源，但相对更难。

国内设计行业线下聚会越来越多，但真正理念和思想上的碰撞却越来越少。
设计领域的文章越来越多，但能深入骨髓的文章越来越少。

信息架构这个领域，我也算不上专家，本想通过实践多沉淀一些干货，再做体系化的输出。
但看到关于如此多对于信息架构的误读，就算顺手把肚子里面的东西掏出来抛砖引玉吧。

（这系列的文章只允许“有价值”的评论，我根据心情删除）

什么是信息架构(Imformation Architecture)

1. The structural design of shared information environments.
2. The art and science of organizing and labeling web sites, intranets, online communities, and software to support findability and usability.
3. An emerging community of practice focused on bringing principles of design and architecture to the digital landscape.

1. 关于信息领域的产生、消费的结构化设计。
2. 这是一门学科：通过组织和标记信息来解决网站、企业内网、在线社区、软件领域的可寻性和可用性。
3. 这是一个专注于实践探索出一定规则的新兴领域：数字化领域的设计和架构。

这是Wikipedia上对信息架构的定义中的一个版本，这个定义是狭义地针对数字市场，而没有包括传统行业(图书馆、超市、库房等)。

上面的定义太学术，需要举些例子来剥开概念的外衣。

误区一：把网站布局设计等价于信息架构

“通俗一点的讲，信息架构就是合理的组织信息的展现形式” 这是目前百度百科关于信息架构的一句话，这个描述显然是太通俗了，展现形式是信息架构最肤浅的一层。功能的组织，和信息的组织，是两个层面的事情。

误区二：信息架构无所不能，甚至包含交互设计、等价到用户体验上

有些朋友可能读过那本书，里面通篇关于词表的东西理解不透彻，后面好不容易有几页是关于导航设计的，哥们就以为看到精髓了，并且思维发散到其他设计领域去了。（说实话，早几年自己也干过这类事情，所以特别不敢轻易写博客）

所有网站都有信息架构？

比如，我曾经说，支付宝就谈不上信息架构，用户使用支付宝，是完成任务，主要的是人和系统的交互。
说实话，这个说法显然不精确，比如每一单交易其实都是一则信息，这则信息不管是对用户还是支付宝，都有被索引的价值。
但你知道我想表达什么？
如果你在支付宝、团购、甚至是新闻网站、微博、社交网站工作，都别谈什么信息架构，它不能深入指导你做设计。

信息架构能帮助哪些网站产品？

1 一个海量的信息库。
2 用户访问网站的主要目的是获取信息。
3 信息的时效性不是短暂性。

找商品、找餐馆、找房子、找汽车、找工作、找对象…涉及用户衣食住行。
书、电影、音乐…涉及人们的精神生活。

虽然搜索引擎的崛起，解决了用户绝大多数“找”的需求，但显然，信息纬度的多样性，以及人和信息的关系，是纯粹的搜索引擎不能触足到的领域。早期搜索引擎是对信息粗放的理解和建立关系。
你现在想想，你有多少“找”的需求，不是通过google和百度？为什么呢？

要抬杠地说，所有的网站基本上都需要向用户传递信息，有信息就需要组织。
所以，我要举出没有网站需要信息架构的例子不太现实。我只能告诉你，这个知识领域能帮助到你多少？

信息架构的职能位置

如果你的网站是基于信息的，那么一个信息架构师的位置是必须的，这个人甚至可以不通交互。交互设计恰恰是信息架构的一个对立领域。交互设计解决的是人和系统之间的对话。信息架构是梳理信息系统本身。

国内网站如果说没人关注信息架构也有点过于悲观。要不然不会出现那么多垂直的可以脱离百度的入口。我的猜测是“高手在民间”。比如房产领域的搜房、安居客，汽车类网站，婚恋类网站，大众点评，去哪儿…他们在公司也许叫“编辑”、“产品经理”，这些人也许完全不谈什么“信息架构”，他们是每个垂直领域的专家，通晓自己一亩三分地的信息规则和用户需求，他们在行使“信息架构师”的职能。相比像我这种张口闭口吞吐专业名词的设计师来说，他们要务实许多。

但我始终觉得，信息架构的是有规律可寻的，靠谱的架构师可以游走于各种信息库，用少绕弯路的办法解决很多疑难杂症。这里面的规律会在后面的文章里面讲到，如果有自认为在我说的信息架构范围内的“编辑”、“产品经理”，你们工作中遇到的问题可以和我交流。

“数据比算法重要”

这是算法工程师经常拿来教育新人和外行的话。
这里的数据，比信息的范围更广，但这里有很多是相通的，比如：

你有10本书，要向用户推荐，最快的办法当然是人肉推荐，要算法搞毛？
只有说你有10W本书，人肉没法推荐，才需要找算法，那算法说需要数据，数据不是指的这10W本书，而是可被计算权重的根据。
而怎么才能有丰富的数据？只有这10W本书的信息库，组织得足够清晰，关系明确，结合用户访问和反馈的信息，算法才有发挥的空间。

信息架构的发展

在互联网、鼓吹的“云”时代里，信息和人的关系已经基本同步，而《web信息架构》的体系，显然缺乏考虑人实时对系统的影响，但这些影响不是交互，而是UGC，用户随时会贡献新的内容，你的内容体系是否能包容各种不同人的想法和思维习惯，并且能把这些内容通过规则而建立合适的索引方式。

在用户对内容参与深入，甚至很多网站自己根本没有内容，全部用户贡献。信息架构的要考虑的问题，自然要更多一些。

不算结尾的结尾

1 写这篇文章，我基本没有考虑可读性，很多该加链接的地方也不想加。算是草稿，会随时修正，删除废话什么的。
2 我会在合适的机会整理成PPT，预计会在下月北京UCD书友会试讲，但也可能跳票。
3 我本不是一个纯粹的人，转载请拷贝走我的广告：下厨房（这是我的创业项目，信息架构是这个项目的核心竞争力）。

相关话题：信息架构的概念源地址：http://uitony.com/?p=166

关于信息架构的改版

kevin2.0 — 2011-05-16 17:38:46

关于图虫的改版，里面的用户讨论应该很多，但是从官方产品团队看来，其实他们原来的产品结构，比我们还要好一些，之所以要改版，也是因为整个产品形态不够轻巧，现在的新版本，是向轻的方向发展，个人中心内容减少，主要突出了大家的互动内容，而与自己相关的资料，大量感少，收到一个入口或者另开一个新区域，比如小组就开了一个新的区域，放在顶栏上叫我的小组，这样首页和小组分开，各自各的纯粹。

最近在改网易博管客顶栏的方案，怎么改都不理想，原因在于顶栏以下的东西，实在有点头痛，单靠一条顶栏，想解决问题也是十分困难的，对整体产品定位和架构合理性的思考，在顶栏的设计同时，也没停止过。

网易博客产品，跟图虫的旧版本，存在一样的问题，即图虫的个人中心内容太多太多干扰，网易博客个人中心也一样，个人中心非常庞大，用户进去就像进入一个门户首页，主要动态点击量不理想，而附加产品的流量更加少得可怜，到底，哪个是你们想要的，产品搞不清，用户也搞不清，反正动态所有一样，没有区别，产品重要度几乎平铺，也没有区别，更别说重点在什么地方了。

所以有种感觉，把个人中心轻量化，突出主要功能，而小组和别的产品，收到个人中心的一个入口，点击后再看到更多。

这点Blgger的新版本也在试着做了，新版本在信息架构上也显得更加纯粹，把几乎所有管理项收到一个入口里，点击后才看到更多。

也正是这些问题，一直困扰着我，做产品，一方面要照顾老用户的体现，而一方面需要照顾整个产品发展的方向，在整合新的产品进来时，在老架构的基础上不断加料，会让产品的纯度变得越来越复杂，当产品发展到一定程度时，需要重新架构，似乎也是必须的，但何时切入，新架构如何考虑，真是白头发的事情。

需求减少，架构也需要干净，这似乎成了时下新产品的发展趋势，facebook去年的改版，基本上减少了个人中心的很多功能，以入口和收起方式代替，而tumblr的成功，也在告诉我们，产品并非所有功能都要，才会成功，twitter和微博的成功，其实也在说明同一个道理，产品不一定要功能十分强大，而产品定位、气质，产品架构的表现，才是关键所在。

如果网易博客以日志为主导，关系以关注为主导，分众以小组主，这样的产品架构起来就没有什么好纠结了，但是按目前产品的表现，其实远远不只是这些：

除了日志还有很多很多的动态类型，日志动态被隐藏在各种动态里面
个人首页的展示，会有各种各样的内容展示出来，而日志只是一部分，有些用户甚至不放出日志
小组在这个架构里面，处于一个非常尴尬的地位，用户进入个人中心，除了要去看各种动态外，还要阅读小组动态，小组的推荐和小组管理，在目前的架构里很难处理，小组越想处理好，个人中心就越庞大
关注关系在个人中心非常不突出，连多少人关注了我，也难找到入口

当然我上面几点，只是指出一些问题，如果要彻底去纠结，还能纠结出各种各样的问题，反而，个人中心出现前的整个博客，还更加干净一些（虽然也存在很多架构上的问题。）

关于信息架构，这方面真的需要再去学习一下，目前大量精力放在部分功能的改进上，而分散的改进，随着功能的增加减少，架构不合理的问题越来越严峻，按这样发展，跟时下的新产品趋势，越走越远，产品的陈旧程度越来越高，易用性也会慢慢下降，最终导致只能有老用户在使用或者核心用户因为功能分散而失去活力，新用户存活率也不可能高起来。

我们的架构如何合理起来，这真是一个白头发的问题。

有时我觉得想这个很累，因为结果总是出不来，真TM要喊一下：求一位强悍的信息架构师，帮忙架构一下这个产品吧！

信息构架的若干原则 (第二部分)

人仔 — 2010-06-24 17:13:17

3. 信息树应尽量窄而浅，且保持平衡（信息结构的宽度和深度）

信息树可以看成是对信息集合中的信息按照某种方式加以组织以后所形成的有序的信息载体，。在描述信息树时，信息的组织关系通常被描绘为一个树形的结构。对于信息架构而言，组织信息所要达到的目标有两个：一个是信息的有序；另一个是形成信息树。
而信息树的设计在网站上的体现主要是导航的设计，首先我们来看看信息树的宽度和深度的关系：
· 较大的宽度，使得信息树变浅，可以将信息明确显示在界面上，用户可以减少点击次数，但容易使一级导航承载的信息过多，用户不容易发现重点及内在组织关系；
· 较大的深度，使得信息树变窄，界面显得有重点、组织关系清晰，但由于用户不能通过一级导航获得所有组织关系，点击和寻找的难度加大。
因此，信息树的宽度和深度是相互制约的关系的，如何让信息树在这两者关系中保持平衡，并尽量使信息结构窄而浅，是信息架构中的基本原则之一。
接下来我们来看亚马逊（amazon.com）导航的变迁史（资料及图片整理来自LukeW’s Functioning Form）：

在1998年，亚马逊网站只有两个一级大类：书籍和音乐。即使增加了一些分类，比如音像和礼物，水平的 Tab 式导航也能够扩展的非常平滑，并且通过颜色的不同，很容易区分产品。

在1999年到2000年的时候，亚马逊还在不断增加新的分类，并使其信息树不断变宽。店铺、玩具与游戏、电器和电子贺卡这些新的产品分类的增加，一直把 Tab 导航标签做成两排。

2001年亚马逊尝试着把所有的商品分类Tab 去掉，仅保留商店目录和特色商店 (Store Directory/Featured Stores)。这次重新设计，用商品目录替代了日益增长的分类，特色商店并提供了一个比较方便的途径让用户可以访问常用（或热门）的分类。可见信息树变浅了，但深度却加深了，用户无法一眼从导航或者更多的信息。

今天的amazon，对所有的商品分类进行了重新组织，如将Movies，Music，Games三种具有相似属性的商品分类划分为一类，在此基础上新增了一层2级导航，可见改版后的amazon导航信息树宽度和深度更加合理，平衡的信息结构，具有更清晰的逻辑、且用户可以从导航中获得帮助。

附：信息构架的若干原则 (第一部分)

相关话题：信息架构的概念源地址：http://isd.tencent.com/?p=2075

信息架构中的常见模型-2

丽君 — 2010-05-31 19:53:34

上一期分享了三种基本的交互模型，双面板选择、画布工具条、向导（wizard），本期讨论的交互模型并不局限在一个页面上的信息结构，它们分别是：响应式出现和嵌入式连接。

1. 响应式出现

一个页面要显示很多内容，但是其中一部分内容不太重要，我们希望用户界面变得简单，但又不得不把内容放到界面当中，在这样的情况下，可以把重要的内容显示出来,并把其他内容隐藏，用户可以通过一个简单的操作访问隐藏内容，这样的页面不仅在一个页面上具备了信息结构，同时具有了垂直的层次结构，不是一股脑的丢给用户，而是在用户需要时显示。

[用法]

1）将主要和次要内容分开，默认显示主要内容，把次要内容放到事先隐藏的区域里；

2）在默认显示的界面上放置醒目的按钮或连接，让用户能够找到那些隐藏的内容。例如“更多”，或是使用向右或向下的箭头作为连接或按钮标签的一个部分。

3）打开隐藏区域后，设置另一个按钮或某种方式能够让用户关闭它。隐藏区域的内容应该是用户大部分时间都不会需要它的，因此要进入和退出这个额外区域的操作醒目就可以了。

[形式]

1）页面内展开：在主要界面上提供按钮或连接，用户点击以后，在页面内展开一个区域，显示进一步内容，这种形式能够即时的反馈用户的操作，同时容易给用户带来自然过度的体验，这种形式适合用在对主要内容的扩充，更详细的、更近一步的内容，当用户没有看到这些内容并不会影响使用，而打开这些内容，用户可以看到更多、或是得到更丰富的功能。

例如：

在QQ聊天窗口中当用户点击“聊天记录”时，页面展开一个区域，用户可以看到更多聊天的记录。

在QQ空间的个人中心中，页面将好友更新的日志标题列出来，当用户点击“展开”按钮时可以看到文章开头部分的段落，同时按钮转换为“收起”，用户可以选择把内容再次隐藏起来。

2）弹出层

用户点击按钮后，在页面上浮出一个层来显示进一步的内容，与页面内展开的形式不同的是，弹出层更适用于区域内的内容较为重要的时候使用，比如弹出层内包含一些操作、或重要提示。弹出层一般包含以下部分：标题栏（与内容区分隔较明显，有标题和关闭操作）；内容区（弹出层的主要内容区）；操作区（弹出层的主要操作区，确定/保存等按钮）。弹出层有两种类型，模式化的和非模式化的，对于模式化的窗口，弹出层可以移动，弹出层以外的页面为锁定状态，不可操作；对于非模式化窗口，该层仍然可以移动，弹出层以外的页面可操作，操作时弹出层可以消失也可以一直出现，根据具体情况而定。

举例：

在秀世界的应用中，用户点击“我的储物箱”弹出一个展示我已经购买的物品的层，这是一个模式化的例子，弹出这个层以后，原来界面处于灰度显示状态，其他按钮不能点击。

在绘图工具当中，对于一些扩充的工具面板也采用了弹出层的模式，这是一个非模式化的例子，当弹出层出现时，原来的页面工具仍然可以使用。

2．嵌入式连接

嵌入式连接已经是web上广泛应用的模式，当用户沿着某种线性路径进行浏览，如一段文本、一个操作流程，而在用户浏览的过程当中，我们希望在用户主要注意力之外提供一些额外的内容，它可能是一个故事的附加信息，或是一个对某个概念的解释、或是帮助文本。这样的形式可以让希望快速完成任务的人快速前进，而对于希望了解更多的人看到额外的信息，满足用户的好奇心和对未知内容的探索。

[用法]

1）为可能吸引用户的附加内容创建入口，

2）这些入口可能是带下划线的连接、大的标题、按钮、菜单项、图标及一些可以点击的图形区域。对于不容易理解的图标或是连接，可以添加简短的描述进行提示。

3）提供返回的途径，在用户阅读这些分支的内容以后能够回到他们的主要任务上。

[举例]

1）在网页新闻当中，对一段文字当中提到热门词汇加上链接，当用户对这个词汇感兴趣的时候看到能够看到与这个词汇相关的新闻：

2）网上书店在显示某本书的详细信息时，根据其它用户在该网站上的购买情况列举出一个书籍列表，在页面上的某个位置显示：“购买本书的顾客还买过”，以及“浏览本书的顾客还看过”列表，这些精确的推荐列表为用户提供了更多的同类书籍信息，它预测关注某一图书的用户可能会对某一类图书同样感兴趣。

相关话题：信息架构的概念源地址：http://isd.tencent.com/?p=2067

什么是元数据 (MetaData)

kent.zhu — 2010-01-26 22:00:45

在读《Web信息架构》的时候第九章讲到叙词表、受控词表和元数据。当时书中的定义很模糊，所讲的篇幅也少，就没有在意，一直也没有能完全理解。今天在读《锦绣蓝图》的时候第四章中再次提到元数据这个概念。遂多查了些资料认真的理解了一下。

什么是元数据？

元数据（Meta Date），关于数据的数据或者叫做用来描述数据的数据或者叫做信息的信息。
这些定义都很是抽象，我们可以把元数据简单的理解成，最小的数据单位。元数据可以为数据说明其元素或属性（名称、大小、数据类型、等），或其结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。

       举几个简单的例子：
       使用过数码相机的同学都应该知道，每张数码照片都会存在一个EXIF信息。它就是一种用来描述数码图片的元数据。根据EXIF标准，这些元数据包括：Image Description(图像描述、来源. 指生成图像的工具 )、Artist(作者)、Make( 生产者)、Model (型号)、….、等等。
       生活中我们填写的《个人信息登记表》，包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等这些就是锁定kent.zhu这个人的元数据。

       通常情况下元数据可以分为以下三类：固有性元数据、管理性元数据、描述性元数据。
        固有性元数据；与事物构成有关的元数据。
        管理性元数据；与事物处理方式有关的元数据。
        描述性元数据；与事物本质有关的元数据。
        当然，并不是说所数据总能清晰的划分在以上3类中。比如：一张由kent拍摄的大小为20K的JPG格式的印着一只小狗的圣诞卡照片。
      它的固有性元数据包括：20K、JPG；管理性元数据：kent拍摄、圣诞卡；描述性元数据：狗、小狗、圣诞、照片、圣诞节、…
      但是，圣诞卡则可以放在以上任何一个分类中。与事物构成有关（说明这个东东是什么）、与事物处理方式有关（说明这个东东的用途是什么）、与事物本质有关（可以直接用来描述这个东东）。

元数据之于信息架构的意义

      元数据是一种很有效的方法，用以确保网站上各种形式的内容确实都能被查找到。比如我们常常为搜索很久之前看到的一张美女图片犯愁，而如果一个图片网站如果信息架构足够好，我们就能凭借我们回忆到的元数据（关于武藤兰的？2000年拍摄的？）清晰的找到。
      元数据之于信息架构就像是房子的砖瓦，它可以根据需要摆放成不同的信息检索系统。元数据是所有组织系统的基础，从搜索到电子商务网站上的导航系统都强烈的依赖于元数据。
       前面提到，元数据实际上是为产品的可查找性（Findability）服务的。而用户在查找信息的时候不会按照机器思维去找（不会输入该照片的ID），而是直接输入关于信息的描述性信息如：“小狗圣诞卡”。也就意味着在创建关于描述性元数据的时候要尽量的提取出任官关于这个对象所讲述的故事，这些才是人们能记住的和习惯搜索的细节。

我们会发现，机械生成的元数据常常是不靠谱的，如在UCH系统下发布日志的时候系统会自动根据标题进行机械分析生成的一些元数据。
而充分利用手工元数据（handcrafted metadate）是提高可查找性的一个好方法。最常见的例子就是我们见到的Tag。Tag就是一种用户自创的元数据，其特点是无层次结构、自定义。比如这张Flickr照片下的手工元数据就为在Flickr上查找提供了更多的方便。

相关话题：信息架构的概念源地址：http://www.ikent.me/blog/2213

信息架构：从学习写字开始

tony — 2009-12-11 21:42:04

UCD邮件组又有人讨论信息架构，基本上围绕《web信息架构》这本书里面的内容，说实话，对于参与讨论的部分观点我基本看不明白，我展开说点我认为比较实在的。信息架构这个名词概念，UCD内部组在三年前就有过沟通交流，对于新手，我真不推荐读这本书。当你开始注意下面的问题了，我认为你可以读了：

我每收到10封设计师的简历，从邮件标题，到邮件正文，到附件名称，信息传递完全没有瑕疵的可能只剩下1封，以下这些情况大家对号入座一下吧：

1 标题：应聘交互设计师
2 没有正文，内容全部放到附件里
3 正文用通用模板，洋洋洒洒写一堆“如果来到贵公司，我会努力工作”的废话
4 附件名：“我的简历”，“个人简历”，“我的作品”
5 把附件解压开，图片名：“xxx 副本2”
…

这篇文章不是要说如何写简历，想说的是如何创造信息，你在互联网上敲下每一个字，都是在制造信息，敲字就像在现实生活中说话一样，话都说不好何谈信息架构？真心地建议那些即将踏入职场、或者已经踏入职场的同学好好阅读邮件礼仪，谈礼仪不仅仅是用“您”，“顺祝商祺”这样的礼貌用语：

1 考虑信息发布出去，接收者的是谁，阅读环境如何？
2 当信息淹没在列表里是否具备识别性
3 是否方便对方再次查找和索引
4 视觉设计师如果有图片作品，是否注意文件大小？（如果附上一个flickr的地址，肯定会得到印象加分）
…

在写UCD邮件组的发帖说明，其中提到：“每次发帖和回复之前，请自行阅读2遍。”发邮件不是在BBS灌水，上QQ泡MM。

《web信息架构》这本书我有很多做技术的朋友也读，从概念上理解，信息学的范围很广，如果非要就这本书的理论很范围刨根问底，一个人真的很难读透，我在读这本书光是读书笔记写了不下三篇，可以翻阅我过往的文章，基本上都是围绕信息架构的。

话都说不利索，凑一起谈信息架构，白扯淡！

相关话题：信息架构的概念源地址：http://uitony.com/?p=110

[翻译]信息架构新手完全指南

Robert.think — 2009-10-11 14:06:33

信息架构师是一个常常被误解的职称。他们是设计者？开发者？管理者？还是以上全部？我们在本文将探讨信息架构师是做沈恶魔，为什么它和可用性相关，以及在信息架构中需要用到的工具/软件。我们也会顺便分享一些对于信息架构的初学者来说有用的tweeters（twitter用户）、书籍和资源。即使您已经对这些内容非常熟悉了，您也可能从中发现一些可能错过的内容。

一般的工作领域猜想

一个信息架构师加入了我在亚特兰大工作的项目团队。因为我对这个领域不太熟悉，或者至少说不知道它的准确定义，我问道：“你好，john，总的来说信息架构师是做什么的？”他的回答是如此的含糊不清：“你知道当你去到一个银行的网站...上面有一些有关它的东西——颜色、文档、有关情绪的照片——这些产生安全感的元素。那就是我要干的。当然，大部分是” 等等。“那就是图像设计师，”我想。我想等我去做一番研究之后再来问这个问题——那么，这里就是了。

谁是信息架构师？

我觉得了解一份工作到底是干什么的最好方式是直接去聆听做这张工作的人是怎么说的。下面是引用一些信息架构师的话：

Jessie James Garett 说：

信息架构是一个范围很大的范畴。但不论是特定的场景或者给定目标的信息架构项目，我们经常考虑的是建立更有效的沟通结构。

——Jessie James Garrett

信息架构学会如此定义信息架构：

一门有关通过组织、标签web站点、内部网络、在线交流和软件，来帮助（提升）可用性和可寻性的艺术和科学。

——信息架构学会

最后，引用Andrew Hinton的话：

Flickr任凭我上传照片，并且可以让我组织它们，给它们打标签，我感觉很舒服。这里没有一个权力机构来告诉我怎么给我的照片打标签。这部分是由于它（Flickr）不愿意由于你做错了什么而让你觉得受伤害…Flickr不是一个任务严谨的系统。它是一个好玩的平台…如果你想要一个严肃的图片库，那么你可以使用类似国家档案馆或Corbis那样的，而不是Flickr。在（由系统）管理信息和打造基本平台让其他人来自己管理两者之间是有区别的。

但这两种方式都是信息架构。

——Andrew Hinton 于 Linkosophy

每段引言都让人深思。但在自己做了一番功课后，我认为没有一段引言能真实的描述这种工作。信息架构师游走于图像设计师、网页设计师、用户体验设计师、前端开发和可用性专家（我写过一篇关于所有这些工作的文章）之间。事实上，这些专业拥有相同的话题：用户为中心的设计（参考Jessie James Garrett的关于用户体验的元素的PDF）。随着时间过去，这些专业的职责已经比较清晰。图像/网页设计师专注于色彩、字体、样式等的运用来传达讯息，而信息架构师则从更有目的性的角度关注站点的结构。她可能问：用户浏览站点的流程是怎样的？软件如何帮助用户分类他们的信息？如何让用户回到之前的内容？那部分信息帮助了客户吗（比如：帮助下决定）？

为了达成这些，信息架构师需要集中与这些东西：目标用户群、网站相关的技术、会呈现在网站上的数据，以及（最好能有的）关于想法的早期可用性测试。

信息架构的进化

信息架构师不仅仅是设计师、梦想家或者项目管理者。他们必需能够从许多不同部门那里获取意见，来完善他们的工作。一般来说，他们开始是设计师，或者与设计师一起工作。在某种程度上，网站设计的技术要求也会成为他们的兴趣或职责。最好的信息架构师要和不同的部门合作，建立和维护网站最终样式的一致愿景。

可能你现在的情况与此类似，或者你在思考你的工作定位是否是信息架构师。如果你心痒痒想了解更多，我建议你查看“信息架构学会的‘我是架构师’吗？”

树立愿景

为了理解信息架构师如何影响一个项目，你可以想象（这个场景）在一幢大楼被建好之后再指派建筑师来工作。这是一个很可笑的说法，但它的确发生在今天。即使建筑在很好的规划营造之后，他们仍然可能面临着改动。Stewart Brand在他的书《建筑如何学习：他们建好之后发生了什么》详细描述了这种有趣的情况。再一次的荒诞不经，我们地地道道的把今天信息架构师放在相似的境地——指派他们去被一些自诩的信息架构师们已经搭建起来的网站。那是因为多数人一点都不了解。越早将愿景传达给专家，愿景越早得以实现。

很多人说，“在多数项目中信息架构师不是必需的”，这只是因为信息架构师的角色与项目经理相似——尽管并不完全一致。只有当你的站点需要处理大量的数据，特别是用不同一般的方式来处理的时候，信息架构师才是必需的。或许你的站点涉及关于书籍的新的搜索方式，比如？

信息架构师做什么？

信息架构师在一个项目团队中经常处理以下事情：

1、 研究客户和商业

信息架构师们在项目中承担各种各样的职责。为了研究项目的客户群，他们需要涉猎或指导可用性测试、卡片分类练习，焦点小组访谈，用户调研等。目标是提供关于影响项目的足够多的信息。信息架构师需要知道人们如何使用你的程序，人们如何处理程序提供的信息，以及当用户使用你的程序时他们的心智模型是怎样的。

2、 数据分析

信息架构师通过定期的探索获得的认识，来定义站点的基本情况是怎样的，以及网站如何来实现目标。在这点上，信息架构师能够和设计师、工程师以及其他对于项目产出物感兴趣的团队成员亲密合作是很有帮助的。通过分析数据，信息架构师可以创建一系列的用户角色。

用户角色真实用户群体的目标和行为的一个代表。在多数情况下，用户角色是通过分析用户访谈收集的数据而综合得到的。他们一般用1-2页纸来描述，包括行为模式、目标、技能、态度和生活环境，运营一些虚构的细节来使得用户角色更贴近于生活中的人物。对于每个产品，一般都会创建多于一个用户角色，但其他一个经常会作为设计的主要焦点。 ——www.wikipedia.org

3、 开发标签/导航/站点架构

最后，信息架构师会，本质上是，结构化站点。信息架构师会产出一些产出物，诸如网站地图、网站流程图和线框图来传达站点从实际角度来看如何运作。实际上，优秀的信息架构师在创建这些产出物时会将所有的想法考虑进来：商业上的、技术上的和社会的（用户）。通过这些，信息架构师将帮助决定站点的总体方向。例如，信息架构师应该定期的测试站点，研究报告，并且评估开发流程中任何用户测试结果。

著名的信息架构师

信息架构的发展也成长了该领域的专业人士。下面是我列出的5位多产的信息架构师：

Donna Spencer Donna Spencer是以为自由职业的信息架构师、顾问、作者和培训师。她有9年在家以顾问身份从事宏观和细节设计的经验。曾经设计过大型的企业内网和外部网站，电子商务和搜索系统，商业软件，设计模式以及一个内容管理系统。了解更多关于Donna Spencer

Nick Finck Nikc是一个有着12年互联网从业经验的资深专家。他的专长涵盖网站设计、网站开发、用户研究、网站分析、信息架构和网站出版。他是众多的刊物上网站设计相关文章的作者，也是网络数字杂志《网站专家在线杂志的选择》的创建者和发行者。了解更多关于Nick Finck

Jesse James Garret 1995年Jesse开始从事于互联网——在最开始是作为一名作者和界面开发者，然后是作为界面设计师和信息架构师。2001年他创办了Adaptive Path公司来帮助人们解决用户体验问题。现在他主要是撰写文章和发表演说，关于用户为中心的设计和信息架构。他是《用户体验的要素》一书的作者。

了解更多关于Jesse James Garret

Louis Rosenfeld Louis帮助开创了信息架构学，合作撰写了主要的文本，在他著名的顾问公司担任主席达七年之久。Lou还合作创办了信息架构学会，也是该学会的顾问团的成员。他同时还是用户体验网络的合作创办者。
从http://louisrosenfeld.com了解更多关于Louis

Andrew Hinton Andrew从1990年开始即以各种方式开始设计信息系统，从1999年开始称自己为“信息架构师”。他在2002年合作创建了信息架构学会，并且承担了赚钱其宣言的全部责任。现在，Andrew描述自己是一个专业于信息架构的“用户体验设计师”。了解更多关于Andrew Hinton

用到什么工具/软件？

信息架构相对于产出物而言，更多的是一种脑力工作。因此它经常受到更多的仔细审查。信息架构师需要平衡体验、研究和用户投票，来提供网站应该如何架构的合理化建议。这是他们工作的本质。为了传达他们的意见，信息架构师通常需要创建线框图。这些线框图能帮助所有的相关方理解网站架构的宽度和深度，包括所有与用户的交互方式。你可以从wikipedia.org上了解更多关于网站线框图的信息。

1、 Microsoft Visio 微软进入图表领域的前沿，Visio是微软office套件的最新成员。Visio是高端IT和信息架构领域专业人士的基本沟通工具。但是它缺少XML格式输出，并且缺少对于苹果电脑的兼容性，是一个值得注意的问题。了解更多关于Visio 2007

2、 OmniGroup’s OmniGraffle OmniGraffle是OmniGroup出品的微软Visio的竞争者，并且做的非常不错。只需要一些简单的点击操作（和下面列出的一些资源）你就能够开始用线框图传达你的想法。OmniGroup说他们的产品可以制作图表、进程图、快速的页面布局、网站原型，以及更多。它能够支持微软的Visio格式，链接PDF，你甚至可以将图表和AppleScript结合起来。了解更多关于OmniGraffle

3、 Axure公司的Axure RP Pro 5 Windows平台上备受关注的推行信息架构的产品。不好的是，它生成的HTML原型有太多“混乱”“冗余”的代码，相比比用Axure生成活动的程序便捷，这太不值得了。Axure公司描述他们的RP Pro5是“快速创建线框图、原型，以及软件和网站规范的主要工具”。了解更多关于Axure

4、 Lovely Charts Lovely Charts是一个全新的图表程序，由用户体验架构师合This is Lovely！的创立者Jerome Cordiez提供。它和上面的解决方案在很多方面不同：它是免费的，基于web的，并且非常简单。尽管这并非所有人喜欢的，但这个想法很有创意，并且我认为这能成为初级信息架构师最佳的交流媒介。了解更多关于Lovely Charts

各种资源

总结

这是有关这个每天都在演变的复杂领域的基本摘要。我并不指望本文可以反映5年来信息架构的当前状态，我只是认为我们都可以从项目里的信息架构获益。以后我会更透彻的考察信息架构的疯狂理念。在此之前，先下水试试看，下载一份OmniGraffle，然后不要迟疑尽管在下面留言吧！

翻译自Andrew Maier “Complete Beginers Guide to Information Architecture”

让复杂变为清晰

千鸟 — 2009-10-11 12:59:47

—— 《Information Architecture: Blueprints for the Web (2nd Edition)》中文版推荐序

Web design的本质是信息和内容，我一贯提倡的观点如此，并且认为国内互联网大环境的畸形发展导致我们误解长达十年之久。尤其在阅读完Christina Wodtke, Austin Govella两位合著的这本书之后，更加清晰了对整个方法体系的看法。

与具有划时代意义的《web信息架构》相比，本书没有过多涉及学术基础原理，直接将IA理论放到互联网中进行推演，建立了网站IA理论实施的初步思路和方法，并迅速得到同行认可。

作者首先在开头抛出了很多总结出来的经验与经典，在现实生活与网络生活中寻找某些共同点，给读者建立初步“架构”意识。其次分别在用户、技术、企业角度提出平衡法则，与我曾经提到产品体系分别有“业务架构、信息架构、技术架构”三套体系的存在，并需要互相牵制的观点类似。（参考2008年10月31日网站背后的信息架构）

在关键的实施流程中，作者巧妙利用了抽屉、CD架、砖瓦匠等实际物和人，形象阐述了信息架构对用户和用户行为造成的影响。把抽象问题给具象化了下来，图文并茂例子鲜活，在忍俊不禁的同时，还得不断提醒自己拿笔做记录。后边所举包括搜索、导航例子，甚至全站设计的流程模拟，其中都内嵌了很多专业术语和名词，可以帮助读者更有效理解。

但信息架构始终还是个专业名词，个人认为互联网产品的信息架构职能，通俗了说就是更早我们做网站时代的网站规划，其目标如本书副标题“怎样规划令人流连忘返的网站”。可惜，国内从事信息技术做网站、互联网产品的网络公司却很难看到信息架构师的身影，或者信息架构的流程。

据我所知，海外4A广告公司早在01年便已设立“信息架构”职位，以便更好、更专业的服务高质量品牌客户的网站设计需求。而国内传统互联网公司大部分是产品经理在承担这部分职责，因为普通设计师没有能力和经验来完成这部分工作，何况没有执行权利也无法保证策划方案的实施。因此很容易造成两者不是在奔同一个目标的现状，因为策划追求创新和创意，执行追求效率和成功率。（参考2008年1月8日策划和执行）

当然，也不是说做互联网产品必须有个“信息架构”职位的存在，或者一套看似专业的“信息架构”流程。关键产品经理和产品设计师都应该培养架构意识，做互联网产品需要资深设计师来“解放”产品经理，各司其职，各尽其能。这是我三四年实践，以及在奥美短期工作学习积累的心得体会。

也许在某些互联网从业者眼里，“信息架构”又是好事者炒作出来骗钱的概念，互联网的下个理论泡沫。事实上，信息架构是美国建筑师Richard Saul Wurman在1975年创造的新词，比交互设计、以用户为中心的设计等概念都早。首先信息架构是门跨学科的专业技术，其次信息架构是个极其抽象理论概念，第三信息架构还很不成熟。在此三个前提之下，写书传达清楚为什么？是什么？怎么做？我觉得做到相当不容易，其过程本身就是个对信息架构理解深度的考验。

在国内日趋规范和成熟的互联网大环境，可以看到问题都在慢慢好转。对于专业产品设计师来说，应该清楚认识到自己核心竞争力所在。理想的分工和协作在国内的确还很遥远，但，是时候做准备了。

Rex Song, 千鸟
OgilvyOne worldwide, Information Architecture
UCDChina co-founder
Sep. 14, 2009

——————————

有些日子了，可能会节选部分印书上。

相关话题：信息架构的概念源地址：http://blog.rexsong.com/?p=6729

基于情景的信息架构走查法

helicopter621 — 2009-07-12 02:01:16

信息架构建立以后，如何评估它的效果？
逻辑走查是以系统为中心的方法，即用业务逻辑等验证IA的有效性。卡片分类法则是以用户为中心的方法，尝试了解用户对于结构的理解和视角。Adaptive Path这篇文章则介绍了一种评新方法——基于使用情景来评估一个IA。

译介原文：http://www.adaptivepath.com/blog/2009/06/11/changemakerscom-ia/

方法概述：
邀请项目组的所有成员共同参与走查IA。研究员为他们简单介绍新设计的IA，然后将一个用户可能的使用场景以漫画的形式呈现出来（图1、2）。

图1

图2

参与者根据这个情景，各自描绘出TA认为用户会走的页面流（耗时15分钟）。最后，大家用30分钟进行讨论是否有遗漏的节点，以及节点之间的关联性是否合理。

具体操作：

1. 撰写一个情景案例，描述用户使用网站完成某个目标的开始点和终止点，以及TA是如何来到这个开始点的。

2. 根据情境案例，画出一个粗略的故事板（图1、图2，例子点此下载），通过图画，让参与者更好地理解用户情境，从而带入用户的视角，扭转以系统为中心的固有思考逻辑。

3. 为众人介绍过故事板后，给他们15分钟，让他们各自画出他们认为用户完成这个情景需要历经的页面以及顺序。

4. 讨论在各人的描画中出现的新信息、功能或分类。

这个方法挺新鲜，也许操作起来有点困难，但无失为让项目组深刻理解一个IA的方法。

前天星星同学在哼“橄榄树”，那句“不要问我从哪里来，我滴故乡在远方”，忽然让我想到，这是描述一个让用户迷失的IA的佳句——不要问我从哪里来，我的起点在远方。

但愿，您的IA设计为用户伸出了橄榄枝。

信息粒度

tony — 2009-03-19 13:49:04

先抛两个问题：
1 很多图片服务网站默认的看到的是相册，而flickr是图片？
2 很多音乐网站的从分类点击进去看到的是歌曲或者专辑，而last.fm是歌手？

“粒度”(granularity)指的是信息单元的相对大小或粗糙程度。各种不同的粗细程度有：杂志的议题、文章、段落及句子。
这是从《web信息架构》一书中摘下来的。
书中没有用很大的篇幅介绍信息粒度，从我的理解来看，
1 图片的粒度要比相册细
2 歌手的粒度要比歌曲粗

简单分析一下图片
图片是最小的信息单位，拿flickr来说，对于图片的集合，有几种形式：tag、sets（相册）、collections（付费用户能看到更大集合的相册）。
问题来了，flickr为什么不用sets作为信息的主线，而是用图片？

拿一个用相册作为信息主线的picasa作对比，相册是最小的信息单位，图片连title都没有。
从使用来说，一个新用户必须先创建一个相册，才允许上传图片。
从浏览来说，相册的结构解决不了浏览最近10张图片的需求。

如果就图片的信息架构展开说下去，有很多可以对比的东西，我当初就质疑过facebook的图片架构，最早是以相册为单位，后来发现这个架构并不适合社区，也就是给传图片和看图片的人都增加复杂度。现在改了，弱化了相册，由于历史遗留的问题，这点并没有改得很彻底。想看反例可以去看看中国的山寨版 facebook，目前都还没有跟着改过来。

再简单说音乐
音乐在信息结构上要复杂，歌曲的层级上面有专辑、歌手。周边信息也复杂，风格、年代、地区等。
网站在选择不同的信息粒度作为主线，将延伸出不同的使用方式。
看last.fm提供的其他产品服务和功能，都是紧紧围绕歌手这条主线，比如电台、活动。
一个国外音乐网站，上线之前没有解决音乐版权的前提下，能做起来，是一件很匪夷所思的事。但last.fm做到了，并且将这个模式做得很大。有兴趣可以看看它是如何处理专辑、歌曲的关系。

做产品设计很容易忽略信息属性本身，从信息的粒度着手，分析其上下级的关系，如何给单元信息进行有效地组合并传递给用户？信息和信息之间的相关度如何建立起来的？排序和展示方式如何？
了解信息粒度是信息架构的第一步。

相关话题：信息架构的概念源地址：http://uitony.com/?p=83

信息架构中的信息架构

Raymood — 2009-03-13 13:06:45

“信息架构”一词向来争论颇多。从概念、范围、应用，职业划分等多个维度，每个人都有不同的解释，就像当年的Web2.0那样。
可国内好像还未听闻哪一公司专门设立“信息架构师”这一职位，而更多的是由产品经理或交互设计师在做梳理信息这部分工作。

对“信息架构”兴味盎然的人仍不在少数，我属其一。

什么是信息架构？

通俗的说，每个人对各种信息有不同的需求，有人觉得1号信息重要，也有人觉得2号信息更有用…… 那么这堆信息该如何呈现不同的人们呢？

我们可以抽象的理解为：通过一堵“墙”架起了“人”和“信息”的桥梁，使之各自找到需要的信息。

这堵墙亦可以理解成一个广义的“界面”，它就是传说中的“信息架构”！（奇遇的手稿已被我撕下珍藏）

信息架构和信息架构

基于互联网产品的信息架构分为2种：静态展示型和交互型。
静态展示型的信息架构；譬如新浪,搜狐等web1.0的门户网站。( 体育新闻 - > 篮球新闻 -> NBA新闻 -> 科比…… )
交互型的信息架构；譬如SNS网站，信息是由人与人互动产生的。再如财务软件，对于财务人员和老板，在对信息操作的过程中，信息呈现是不一样的，权限和职责不同，架构亦不相同。

后一种架构比前一种更难设计，因为信息是流动的。

此外，整理了一些信息架构的有价值的文章、摘要和随笔

IBM出品的3篇经典：

人们会抛给您大量的数据和内容，希望您能够完美地将其组织在一起。信息架构师需要充当很多角色，而研究和分析能力对成功完成所有这些工作至关重要。——摘自信息架构本质，第 1 部分: 数据和内容的两难抉择
信息管理的一个关键要素是能够确定有价值的信息，并组织该信息以最适合特定的受众，此任务要求您能够以批判的思维考虑什么内容重要和什么内容不重要。 ——摘自信息架构本质，第 2 部分: 管理企业信息
按列表、同义词、方面和词典组织信息是四种已证明有效的常用方法。 ——摘自信息架构本质，第 3 部分: 组织复杂的信息”

信息架构的轻松一刻（轻松"理论",寓教于乐。注意：以下内容纯属巧合）

经常有人读《web信息架构》有感，而且篇篇都跟动物有关。今晚的动物世界将继续探讨稀有物种的归宿《敢问北极熊，路在何方？》。

信息缘何扑朔迷离？体验为何如此之烂？网站背后的信息架构告诉我们幕后真凶不止一个：业务架构、信息架构、技术架构都有责任。

信息架构的流程引入是很有必要的。它告诉我们为什么交互算过得去，但网站还是那么烂的原因：交互只能解决一个需求，但用户需要的是一串串需求。注：一串串指糖葫芦、羊肉串等“串”类食品，你，就是那个穿串串儿的人。

“主体间性”在前台，“主体性”在后台。“主体性”可以简单解释为“我，我的”；“主体间性”可以简单解释为“朋友，朋友的” — 麦田对《facebook模式的SNS架构特点》的理解…有点绕口令的意思。

“基于文章内容的重构，将是以后很多以媒体为定位的博客要做的事”这是Tony对博客架构的媒体局限的结论。
个人认为wordpress相关文章插件可以解决这个难题，它可以针对当前文章的关键词或标签，自动匹配相关性较高的文章，并形成列表（ueui.com.cn这个博客用的就是这款插件，有兴趣的同学可以仔细观察一下）。

在《浅析facebook的信息架构》中，白鸦首次将抽象的“信息架构”结合实例facebook，并采用色块来表现信息区域，进行归类、划分，使之具象化。
架构考虑不清？自己动手画画吧！动手能力很重要，平时在对信息的拆分和统一的过程中，慢慢就会有了头绪，此法我常用，并屡试不爽。

打乱信息架构的因素有许多，计划总也赶不上变化，这就是奇遇同学当年的无奈：“合理构建了信息结构，为何还去扰乱？ ”

还有还有 …… 待热心的同学们继续补充

社会结构的要素

甲壳虫 — 2009-03-12 15:59:04

原文作者：CHRISTINA WODTKE
原文链接：The Elements of Social Architecture
译者：甲壳虫

1977年出版的克里斯托弗.亚历山大(Christopher Alexander)所著的《建筑模式语言》中，收录了世界上各种文明中几个世纪的人类建筑智慧。它不仅在建筑学以及城市规划上意义深远，并且且在软件设计领域影响巨大。书中，亚历山大与他的合著者共探究了253个建筑设计模式。例如：

“203 孩子们的洞穴”

矛盾：孩子们喜欢呆在狭小，类似洞穴一样的地方。

解决方案：无论孩子们在房子周围，在邻居家，在学校，或其他什么地方玩耍，都要为他们创造一个小小的“洞穴”。把这些洞穴藏在简单自然的富余空间中，比如楼梯下，厨房的柜台里。保持“洞穴”的顶部足够的低－－2英尺6英寸到4英尺－－及入口狭小。

每种设计模式都探讨了多种设计空间来满足人们的需要以及提升幸福的感觉。但一直没有人能有足够的想象力把这些建筑上的原则运用到信息架构上去－即把它们从真实世界中提取出来并运用到信息世界中去。

当你把人们聚在一起的时候，人们会以令人吃惊的方式行动。在信息空间中，一个人的需求简单并且他的行为直接了当－－查找，阅读，保存信息。但是一旦你把一堆人聚在一起，你可以观察到他们是多么疯狂以及充满智慧。Digg,一个在线新闻服务，它的头条新闻由读者投票推选出来，这选择既有可能是有见地的政治评论，或是一条关于一种非法破解的软件消息。这种不可预测性使设计社会架构成为设计师们从事的最具挑战性的工作。

虽然你的设计永远无法控制人们该做些什么，但却可以提倡良好行为并劝阻恶意操作。心理学家科特·勒温（Kurt Lewin）开发了一个方程式，解释了为什么人们会做出这么疯狂的事情。温声称行为是一个人与他所处的环境共同作用的结果： B=f(P,E)。你不能改变一个人的天性，但却可以设计他们所处的环境。再让我们探讨一些在我的工作和我的同行的设计工作中已经观察到的一些亚历山大的模式。

身份

矛盾：网上我能够信任谁？

解决方案：给每个用户一个身份，并允许他们按自己觉得合适的方式个性化地修改它。身份允许用户通过独一无二的登录设置来获取，保护，表达自己的个性。这种参与能够用增强信誉,以及允许其在系统中收集物品的方式给予奖励。（书签，历史记录，联系之类的）

身份是社会架构的基石。克雷·舍基（Clay Shirky）在他那篇聪明的论文《一个队伍是它自己最大的敌人》里这么说到：

“如果你要写一个社会软件，以支持一个大型的，历史悠久的组织，你会怎样设计？你的设计要解决的首要问题便是：如何让用户参与进来。”

身份的要素

为了让你的用户能够成功地新建一个身份标识，你需要为用户提供多种方式来在线上展示自己。在线标识的4种要素是：

配置文件（Profile）

配置文件是一个关于用户的信息集合，特别是包括了一个简短的介绍以及一些上下文相关的事实。例如Orkut，谷歌进军社交网络的产物，它能够收集并突出显示用户的性别和婚姻状态。LinkedIn，一个商业网站，它没有涉及这些任何信息，而把重点放在工作经历，综合能力和教育上。

Orkut用户配置文件

LinkedIn用户配置文件

存在感

任何有吸引力并且生气蓬勃的社区都需要的是生活的原味。这种存在感是用户表达自己并加入在线空间的一种方式。存在可以是某种地位，历史记录，或所在位置。

信誉

在网站上，你的信誉相当于所有在网站上过去行为的总和，这便是社区定义“好”和“坏”的方式。人们的记忆并不可靠，而新的成员或访客也不总是知道过去发生了什么，网络软件中内置进的信誉系统，可以跟踪人们的行为，以及社区是如何判别这种行为的。亚马逊公司的“500个最好的评论”或易趣的“最棒卖家”称号便是信誉系统非常好的例子。

联系：

矛盾：在网站上有数以百万计的人，你如何确保你可以追踪到你所在意的人？

解决方案：创造各种方法来标识，联系，并以人们想要的方式组织他们，以及他们所产生出来的信息。这些复杂的关系如何分类要取决于你的用户将如何使用你的网站。

关系在社区中是永远存在的。比如线上，站点的软件清单和联系人目录，这是根据社区的需要拟定的。它可以很简单，如Twitter的扁平跟随者模式。Twitter基于这样的理念，即人们可以对他人进行广播并订阅别人的节目，就像他们面对的是一本杂志一样。而Twitter的系统设计中不认同，相互拥有同样的跟随者会是一个友谊的桥梁。他们把全部的关系建立在，“我对此感兴趣。”

为了确定关系实质，网站提供的更多选择给了用户更大的控制权，但这同时引入了复杂性。Flickr提供了“朋友”，“家庭”和“联系人”类别，让用户以他们觉得舒服的方式使用，包括标示为朋友的家伙其实是真正的家人和标示为家人其实是真正的朋友一样。

当你的Flickr联系人增长到100个左右时，“朋友”就会成为一个有用的工具，把人们更密切点地联系起来。这是因为你的朋友会出现在你个人主页的中心位置。此外，你可以根据这些不同分别设置查看权限。例如，一个大学生可能会设置他的私密相片只能由一个标示为家庭的密友清单访问。而他可能把实际的家庭成员标识为朋友或联系人。每个标签都是基于一套内置的假定设置，这可能适用或并不适用于用户的需求。不过，明确用户经历什么，而不管他们的标签是什么，这是相当有效的。

Twitter中的跟随者

Flickr上的朋友和家人

关系的要素

关系在web上就像在现实生活中一样重要。关系有3个关键的因素：

联系

让你的使用者可以分类他生活中的人们。这可以很简单，就像在说“我认识你”，或“我不认识你”，或者更复杂一点，“我们是大学室友，但我们已经有十年没说话了”。

团体

团体是另一种关系结构，它基于共同的兴趣或体验，而不是个人之间的联系。它们包括校友团体，工作组织和专业机构。

规矩

如果你套着雅马哈T恤走进摩托党酒吧，你很可能会被干掉，而游荡到某个星战论坛上说，“乔治·卢卡斯干掉了约瑟夫·坎贝尔（Joseph Campbell），他甚至没有做得很好”论坛将会在一个小时内爆发超过500个争论。我们称那些违反规矩的家伙为“巨怪”，这是专为他们准备的。要定好规矩并说明好违反它会导致的后果，比如超时或封号。

活动

矛盾：如果在一个网站上没有什么可干的，那么你的朋友在不在哪儿都无关紧要了。这网站不会比地址簿更有趣，也不会产生什么感情或交流。

解决方案：组织的活动只能由个人参与，但这却能大大增加团体之间的分享。

社会软件的第三个主要模式就是是社区活动。这就像是一个派对策划：你把人们聚集在一起，然后呢？让人高兴的是，人们有很多喜欢一起做的事情，如果你能让他们在聚在一起，给他们一些最基本的工具，他们就会开始交谈，分享和协作。

活动的要素

用户在你的网站上有多少的事情可以做，他们就会在那里消磨多少的时间和精力。活动的一些要素包括：

共享

送礼是一种原始的人类行为，它使我们联系在一起。如果一个人给其他人送礼，他会产生感激的心情，并期望得到回报。在网上社区的设定里，媒体的本质允许你保留任何文件的副本并发送给他人，于是送礼就变成了共享。共享能够收集人们的喜好，并允许他们互相交流。随着社区联系的加强，共享还能让他们彼此交换梦想，希望，机密，与恐惧。

交流

对话和沟通，这是社区的核心和灵魂。不管我们制造了多少软件，人们都会建立起他们之间的关系，并首先通过语言来强化这种关系。如果你没有提供给人们发言的地方，浏览社区就会像观看电视一样。

协作

社会软件被视为一种能让团队间彼此进行协作的工具。虽然“社会”的那一部分可能已经席卷了网络，仍然有大量的工具设计者关注如何帮助小群体完成他们的工作。

人类架构

人类是复杂的，而网络是动态的。越来越的创新和杰出的模式将被定义。然而，人们之间的联系和互动已经不是什么新问题了。亚历山大的模式语言里这么写道：

36.公开的程度

矛盾：人与人之间是有差异的，在一个居民区中他们选择居住地的不同是一个最基本的差别。

解决方案：明确区分三种住宅，位于那些寂静的闭塞区，或位于繁忙的街道上，抑或是或多或少的居于两者之间。确保通向那些在安静地区是道路是曲折的，并且这些房屋彼此间都是物理隔离的。确保更多的公共房屋处在有许多人整天来来往往地经过的繁忙街道上，而且房屋本身也是展示给路人的。而之间的房子就让它们位于他们之间的途中。让每个社区拥有大约同等数量的上述三种住宅。

这种模式描述了一个小镇的设计，但这可以适用于设计社会网络。Facebook上最初被抨击的功能已经成为其最流行的特性：新闻传播(news feed)。阅读新闻传播就像呆在城镇广场上，在这里你可以看到正在发生的事情，或与大家聊天。有些人希望生活在城市广场，这样他们就不会错过任何事情。有些人则喜欢居住在城市边缘，远离人群的窥探和压倒一切的现代化气息。社会结构的不断的挑战是寻求智能和微妙的方式，让人们拥有对不同程度公开性的的选择。（包括保护其他人的公开性）

如果我们牢记社会结构中的社会要素，我们便可以不断写出可以改变人们的生活并来给他们带来欢乐的软件。

PS：1. DEGREES OF PUBLICNESS 我看到有人译成“公众的角度”，但我觉得不是那个意思。

2. 这篇文章作者摘自她的 Information Architecture: Blueprints for the Web

信息架构专题整理

千鸟 — 2009-02-25 05:36:11

http://www.rexsong.com/webdesign/ia/

偶然看到网友对以前内容的推荐，感觉很不好意思。因为如果以现在标准评判，其实都是不及格定义，顶多算还有剩余价值的思考片段。在我工作时间范畴内，信息架构理论的应用远比交互设计广泛，因此在blog记录的实践心得也更丰富。

在互联网产品设计中利用信息架构原理，主要是实现功能组织、界面组织、内容组织。甚至在多个网站之间也可以利用类似思想做数据打通，实现真正的网站群，例如Google产品线就是以搜索为中心的发散结构。但我个人认为在实际工作探讨中应该少提概念，把问题落到实处，注意凡事慎言“架构”，避免曾经凡事都“交互”的误解。

信息架构也分行业的专业应用，在垂直领域设计中更重要。设计师的价值就在于能创造出别人无法企及的高度，因此我一直强调设计的技术含量，强调自己设计自己用。也因此，唯一的学习方法是疯狂实践，转化知识并积累常识。借用最近推荐文章中某句话结尾——一个终日在电视机旁的看“会动的图画”的两脚动物是不会有原创性的。

豆瓣相关讨论组
http://www.douban.com/group/ia/（奥美同学创建）
http://www.douban.com/group/iachina/（Van老师创建）

相关话题：信息架构的概念源地址：http://blog.rexsong.com/?p=5226

Web 分析与信息架构

stan — 2009-02-13 12:31:10

译者：UCD翻译小组，Stan
校审：Douis Li，Angela
原文地址：http://web.fumsi.com/go/article/manage/3460

信息架构始终关注网站对目标用户的易用度和使用频度。对大部分的部门来说，很少会要求我们提供可用性或用户体验方面的数据，但我们经常会收到其他一些部门提出的这样的要求，“我需要知道今年我们网站的访问量，以及和竞争对手的对照数据。”

不是人们不在意网站的易用性，而是一般来说网站的报告数据模糊不清，尤其在站点可用性测试的实施上或目标群体接受方式上。更有力而易懂的方式是报告出站点的访问量在去年上升了百分之几：硬数据更加确凿，而且比其他业界公认的度量方式更优。

Web分析可以得到与用户行为有关的定量的结果，这被用来给站点表现建立基准点以及给管理层提供报告。但是，既然web分析数据显示出人们在网站上的行为，那么分析数据就应当用于产生并引导更多定性用户研究方法。比如焦点小组或可用性测试，它们能告诉我们用户行为的产生原因。更重要的是，你可以使用这些web指标对整体的商业行为提供更多的定性测量。

在我的工作中，我不停的想办法让我的客户们去关注人们在其网站上的行为，并鼓励他们“象用户一样思考”。在一个完美世界中，我会持续不断地与网站访客保持接触－他们会参与焦点小组和可用性测试，以便我们的每一步动作都能被网站的目标人群所认可。一厢情愿地想下去，我会知道...通过web分析，你可以实时观察用户在你网站上的行为，每天24小时，每周7天。即便不去亲自接触，一个公司也可以系统化地掌控网站访客们的需求和兴趣。

一个信息架构师应该关注web分析，因为这可以拓宽你研究的范围。举个例子，如果你想改进网站一个特定的部分，理想情况下，你会拜访你的目标用户做一些面谈，构建一个原型，并且让用户来测试它。即使你的研究预算很富裕，你也只能够观察到网站的一部分，和用户群中某几类用户。Web分析是基于整个用户群、整个网站的调查研究。通过分析，就有了识别问题和情况的方法，而这些问题和情况你可能从未听说或关注过。

在我的研究方法中，Web分析已经不再是一个工具而已。虽然我可能会通过焦点小组去获取所探讨的问题的处理意见，或者通过可用性测试去观察站点特定区域的性能表现，但我还会通过分析去发现那些可能被忽略的部分。研究的另一个功用就是分析报告中的发现能对网站的信息架构和内容策略产生影响，也能够为后续的研究铺平道路。

很多设计师对web分析都有畏惧感，是因为他们被这些数字和分析中存在的复杂性吓倒了。我想分享一点小秘密给你---不需要把自己当作一个统计专业人员去使用和理解web分析。你真正需要的，是成为一个好的描述者---可以说大多数的信息架构师就是这样子的---因为web分析告诉你的是网站在过去发生的故事。

故事情节包括了人们如何到达你的站点，他们在网站上寻找什么，看到了什么，没看到什么，以及这些是如何变化的。作为信息架构师，我们需要翻译并诠释那些分析数据所透露出来的故事，并与那些需要知道那些故事的人进行沟通。不需要专门讲述数据后面的故事，这是web分析被低估的原因之一。数据本身没什么意思，而是一旦你添加了背景，故事便变得鲜活起来。

把这些数据翻译成为故事，也就脱离了web统计不可避免的不确定性。在我的案例中，因为我不能够用cookies或者页面跟踪代码去跟踪用户，所以相对而言，我的数据精确度比我期望的要差，这是因为日志文件分析方法的造成的。即使是这些有限的数据，我依然能够讲述一个故事，从中看到一个大的场景和过去的趋势，帮助网站所有者明智地设计站点架构、内容战略和其他事情的优先顺序。

知道Web分析不能告诉我们什么，和知道它能告诉我们什么一样重要。第一，当你比较一个站点和另外一个站点的时候，统计是没什么用的。这是因为，大多数时候，没有一模一样的分析程序，没有方法保证他们使用相同的算法来分析日志和流量。第二，web分析数据能讲述在一个站点上人们在做什么，而不是为什么这样做，所以去应用分析数据去确认和指导更多的定性的用户研究方式显得尤为重要。

说到某个流量图形成的原因，客户常常会推测出一个完整的场景，这表明他已经把网站和数据紧密地联系起来了，尽管这很让人兴奋，但离开统计数据去主观臆断却是很危险的。为了帮助他们找出用户这样做的原因，你必须提醒客户要做额外的研究，去研究站点访问者的想法和动机。

我在这里所唠叨的只是如何开始使用web统计数据来指导你信息架构和网站设计的一些方法。

第一步：检查站点

就像任何项目一样，你应该做的第一件事情是检查你正在分析的站点。目的是当你看分析报告的时候，你需要对网站有一个初步的了解，这样你才能把握将来要着手改造的网站的背景。你应该问自己的一些问题，下面这些可能你已经看到过了：

谁是站点的目标用户？
从用户角度来看，网站上那些是关键页面？
从商业的角度来看，那些是关键页面？
网站的使命是什么？
网站的目标是什么？
从技术的角度来看，URL的结构是什么？页面是如何生产的？

第二步：检查统计报告的正确性性

如果站点使用了一个托管的分析方案，那么大部分事情都会帮你照顾到了。但是，当你无法使用托管的分析方案时，你要保证软件安装正确。你大可以自己来做这些事，但你必须对服务器日志和网站的配置有些技术性理解。

不确定的是，诸如非人工访问，应该排除在报告之外，确保数字的尽可能的正确。如果你有一个豪华阵容，搭建一个分析报告服务，并可以接触到负责生成报告的那个人，那么你能够控制这些事情。如果不能，你必须亲自检查报告确保没有问题。你所看到的那些数字有可能存在10％至70％的错误，就看你的报告有多么“干净”。

这些事情应该排除在报告之外：

搜索机器人，蜘蛛，和其他非人工访问者------如果你看站点访问量中最高的是”crawl-66-249-65-83.googlebot.com_Mozilla/5.0 (compatible;Googlebot/2.1; http://www.google.com/bot.html)”，那么你知道这些没有被排除。
注意：即使一个管理员已经从你的报告中排除了机器人和蜘蛛，这并不意味着从此就清洁一片。精确度是需要不断提高的，定期的保持报告的清洁度才是。
内部访问------内部访问者的IP地址应该被排除在外。举个例子，如果你正在看” ENERGY STAR”的统计，那么所有的从” ENERGY STAR”员工和客户发出的访问应该在排除在报告之外。

第三步：快速阅读报告

现在你熟悉了站点，并知道了报告的分析正确，通读分析报告，可以得到对报告内容和整体趋势的概览。基于你对站点的了解，访问页面排行和其他指标是你期望看到的么？

第四步：趋势环比

下一步，并列查看不同月份报告的一个数值，感知其趋势。有一些流量趋势是周期性的，比如，工作日的流量比周末的流量大，或者是夏天月份的流量比其他季节流量低。是有相同的页面一次又一次的出现么？有页面做的不错却没有被监测么？

第五步：让负责沟通、公关、推广的团队成为你新的最好的朋友

如果你还没有接触到负责为网站做沟通和推广的人，那么分析报告是一个好的理由督促你去接触他们。这些人能够告诉你关于推广活动的情况，这些可能会影响流量。他们还能随时让你了解当前新闻和热点事件，以及能让人们有计划地访问网站的信息氛围。

还有，市场和对外沟通的人员会成为你的拥护者，因为你的分析报告表明了他们和其他成员做的有多棒。

第六步：着眼关键指标

直到这点，说了一圈，都是报告之外的事情，但还没有讲包含在报告中实际数据的事情。一个统计报告包含了无数的数据，但是在看的时候，你怎么会知道那些需要重点关注？在我的报告中，这些指标是最常用的：

访问量和页面浏览量
在这里，你不要只注意列表上有什么，还要看没什么。从你对网站的了解来看，这些信息应该是普遍存在但偏偏没有的么？信息架构并不是空中楼阁──我们总是会考虑用户需求和业务需求的。举个例子，比如PV，通常来说更多的PV是一件好事情，因为人们对你网站的内容非常感兴趣，但也有可能是人们在你的网站上浏览了很多页面，却找不到他们要看的东西。
站点导航的表现
看看访客们是否去了你想让他们去的地方。当我发现从首页或一级频道页面访问时，都不可能到达访问量最高的一个页面，我就决定要重新设计这个站点了。
进入页面和离开页面
看一下，访问者离开的页面是不是我们预期的那个页面，比如是一个表单填充页面（而不是一个布满链接的页面），或者在一个没有预料到的地方离开，比如在一个多页面组成的过程中。
关键字
从统计报告中，你能够得到关键字，包括用户在站内搜索和其他搜索引擎使用的词语，同时这些搜索结果会让访问者对你的站点产生访问。重要的是，你不仅要看统计报告里面呈现的条目，而且还要看没有呈现的词语条目。这2种类型的条目都提供了一个窗口，通过它可以看到你网站访问者的词汇表，还能够知道用户是如何看待你的站点内容的。
来源
去看看那些引导用户访问过来的站点也是很重要的。有以下一些原因：对于你的商业目标来说，导入站点也许是潜在的合作伙伴；对于你的内容来讲，需要找到前面那些站点的用户是那些；对用户贡献内容的站点的增长来说，还要寻找站点用户参与的其他那些站点，才可以到达最广泛的用户群体。
转换率
在一个站点里面，任何一个多页面的过程都能够测量，以确定人们在从头到尾的使用过程中的转换百分比。

第七步：清晰的描述数据和下一步的工作

最后这步，可能是最重要的一步，就是要清晰的呈现你的分析结果并使之可操作。作为分析师，对于数据挖掘越深越需要谨慎，你不能用细枝末节迷惑大众，因为这样弊大于利。在报告开始的摘要部分，列出了一些兴趣点和一些建议提高的组合，这对于那些没有兴趣去看图表的人来说，是最实质的内容。

我尝试去使用摘要来讲述一个故事，是关于网站和它的访问者的。是什么样的行为产生了网站的流量？这些访问者从什么地方来？一旦他们来到站点，会做什么？他们在寻找什么？这些指标，在之前的报告中曾经被嘲笑不已，都是相同的指标，但只有当你把这些指标编成一个故事并讲述出来的时候，你才能让更多的人理解。

只有你抓住了发现的一些关键点，才能对下一步工作提出一些建议。比如有些建议，去观察在一些特定的方面，一个新的发现是一个趋势的开始还是一个偶然现象；还有可以去引导用户浏览网站的某一部分并深入其中。即使你的建议微不足道，但重要的是让人们知道了他们能够提高和改善站点的表现，或知道如何去获得更多的信息。你能做的当然不仅仅如此，开始你的Web分析吧，在以用户为中心的设计中，这将开辟一条崭新的道路。

---------------------------------------------------------------------
Hallie Wilfert 是SRA国际组织的高级信息架构师，SRA国际组织是一个技术和战略顾问公司，在弗吉尼亚州阿灵顿，她在那里工作主要负责政府客户。先前，Hallie是美国国家科学院医学院新媒体主管。作为一名信息架构师，她致力于在满足客户需求的同时，尽量为用户而倡导。

Hallie 在American Studies取得学士学位，曾就读于加利福尼亚大学伯克利分校、马里兰大学学院公园。Hallie还是信息架构协会和UPA成员。她曾在2008信息架构峰会和2008国际UPA会议演讲，议题是在用户为中心设计中整合Web分析。