怎样理解信息架构？
42 个回答
信息架构是我学习交互设计中最迷糊的知识点，通过网上搜索和同行交流我发现这也不是我一个人的困惑。更神奇的是很多在网上写信息架构的人要么自己还不懂什么是真正的信息架构要么就是根本不会表达，上来就给我画一张思维导图，稍微有点良心的作者还给你展示一下卡片分类，总之这些文章都是半斤八两，仅仅把产品的导航菜单就当作信息架构，真是误人子弟。
数据结构比导航重要
就按目前的行业发展来说导航设计直接抄袭都不会产生很大的体验问题，倒是一些关键信息的结构，是产品的成败。
以网易云音乐举例，用户可以创建歌单，歌单内有歌曲，歌曲和歌单都可以被用户写评论，同时歌曲有演唱者。用户可以创建多个歌单，在不同的歌曲、歌单下写评论，演唱者创作了很多歌曲。任意一个用户访问其中一个节点可以顺藤摸瓜找到其他节点。这是一张网络，远不是一个树形思维导图可以表达的。正是这张网络让用户在歌单和评论之间流连忘返互动频频，造就了网易云音乐作为年轻人音乐社区的成功，网易云音乐五个底部 Tabbar 导航是什么决定不了产品的成败。
以上这些节点之间的关联关系，一般在信息、计算机等理工专业的《数据库设计》课程中有教授。这种理清各个概念之间的图表称为E-R图（Entity Relationship Diagram，实体-联系图），这种图表提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
在实际工作中这个图表一般有高级产品经理或者后端程序员绘制，明明是设计信息架构中非常重要的一环，很多初级产品经理和设计师却从未听过，也未系统考虑过。
导航结构和页面信息结构不一样
我在指导初级设计师画思维导图时，经常听到的困惑是：信息架构的思维导图中每个节点的定义是什么？我到底该把导航上的文案还是界面上每个元素写在节点里呢？
这时候我就不得不和他们解释：摆放家具的时候不要考虑冰箱第二层放什么，在整理冰箱食物的时候也不要去想怎么摆放家具。 分开两张图来画不就得了。
我第一次看网上文章学信息架构也很纳闷这些作者是怎么能把导航结构和页面元素画在一张思维导图里的。
说实在的，我至今也画不出来。
信息架构的组成部分
有一本名为《建筑设计的永恒之道》的书，意外地在互联网行业也很有名，其中有一段非常经典的话：
不想像事件发生的场所，就不能想象任何方式的事件；不想像自己睡在哪，我就不能想象睡眠。不能想象哪里发生了什么，就不可能想到那个地方。不想象床、性行为、睡眠，起床——我就不能想象起居室
人在现实生活中的活动必然发生在某个场所，相似的我们在虚拟世界里的活动也必然发生在屏幕的某个界面里。
现实世界和虚拟世界是有很多相似之处的。如果我们现实生活中场所的设计和摆放有问题，人也很难理解和活动。以一个厨房举例，要设计厨房之前，我们先梳理在厨房内进行的活动和接触家具的顺序。
再梳理之后，我们权衡之后为活动安排最方便的路线，就得到了厨房家具的摆放顺序（注意我之前所说的，这时候别去考虑冰箱里哪几层放什么食材的事情）。这在室内设计中称为动线设计，类比于互联网则是导航设计。
不是所有的事情都适合在现实世界中做，要不然也不会出现互联网公司估值比很多实业公司还高的事情。
如果我们建设一个如下图所示的场所，现实世界如果要实现这些需求，不晓得要装多少台电梯才能让观众在不同的作品之间方便浏览，不知道要每天发行多少套简报才能让观众知道有新作品发行。
而这些需求如果使用互联网的超链接跳转和关注推送机制，就方便高效得多。
以上这个现实世界和互联网类比的例子，是为了引出信息架构的知识框架，通过查阅信息架构相关资料，如果我们用现实世界的超市类比互联网产品中信息架构的对应知识，信息架构至少包含如下内容：
- 超市的内部路线和指示牌 —— App 的导航结构
- 超市的布局结构（包裹寄存处在前，收银台在后）—— App 的功能结构层级
- 超市商品的分类方式（比如西红柿属于水果还是蔬菜？） —— App 内的内容分类方式
- 超市分类的名称（叫生鲜区还是蔬菜水果区） —— App 内各个功能的命名（标签系统）
- 超市的商品货架放置方式（上层是绿叶蔬菜下层是果实蔬菜） —— App 内的界面布局
- 不知道路或者商品寻问超市导购员 —— App内的搜索
这些知识点光拿出其中一个就要学习很久，更不可能用一张思维导图就表达这些内容，而且国内并没有哪个岗位能负责所有信息架构方方面面的设计。往往设计师画导航和界面布局，产品经理和程序员规划功能结构和搜索系统，运营负责内容分类方式。
推荐阅读
为了论证思维导图不等于信息架构我闲扯了很多，遗憾是我也没有精力和能力写一套完整的信息架构教材，幸运的是有其他大佬可以，接下来给大家推荐一些很不错的信息架构学习资料。
米兰理工大学信息架构课程笔记
这是我的老乡呆头咸鱼所作，她之前是淘宝交互设计师，再之前之在意大利米兰理工大学读服务设计研究生时写了一些课程笔记，期间恰好就有信息架构的课程。信息架构本来是国外舶来的术语，自然国外的课程会更系统科学，课程笔记分为四章：
- 《信息架构概述》，链接：https://mp.weixin.qq.com/s/pR0Q_uP1nlOggcDSGN0JNg
- 《信息架构 ontology（本体论）》，链接：https://mp.weixin.qq.com/s/dsbOidLgAMXJrdqi2a20QQ
- 《信息架构 taxonomy（分类学）》，链接：https://mp.weixin.qq.com/s/AUlMAQ-0ZXx-6ojNtmdc7w
- 《信息架构 choreography（编排）》，链接：https://mp.weixin.qq.com/s/3XcmBMrQX0CuW-P-EM_xqA
Hozin 的信息架构系列文章
Hozin 是我认识的大佬，在互联网行业从业超过 16 年，更难得是如此大佬仍然愿意和初学者交流，他应该是hi国内发表信息架构文章最多的人，以下提供他公众号的专题链接
《交互系统新概念设计》
这本书中文译名云里雾里，还以为新概念是什么英语教材。原著英文名是《Conceptual Design for Interactive Systems》，既然有 Conceptual Design 那肯定涉及到信息架构，这本书非常系统而且有具体的实例操作如何从信息概念开始逐步设计出用户能理解的界面。
我放一些网友拍的书籍截图大家就知道这书绝对是干货。
这篇适合交互设计或者对交互设计感兴趣的小伙伴们看。所以我就不解释信息架构是什么了。今天写一下产品信息架构的思考。
任何产品都有信息架构，或繁杂或简单。在文中讨论的时候，我大致把信息架构分为两种来例证。一种是比较简单的信息架构，例如大多ToC产品，微信、QQ音乐、腾讯视频等；一种是比较复杂的信息架构，例如大多ToB产品，运维类产品、客户关系管理系统、业务支撑系统等。我把第一种称为“轻架构”产品，第二种称为“重架构”产品。
轻架构产品，需要提供给用户一个简单明了的信息架构，让用户使用方便、体验流畅。轻架构产品不能让用户迷路，不能带来太多的学习成本，面对海量普通用户要做到可用且效率高。轻架构产品可以通过做减法来聚焦。
重架构产品，需要提供功能完备、结构严谨的信息架构，让用户能通过操作流程以使用各个功能。这样的架构会带来一定的学习成本，有些重架构产品甚至需要对使用人员进行培训。重架构产品的用户群体一般比较聚焦。重架构产品很难通过做减法来聚焦，而是需要对海量功能进行合理整合、灵活布局来聚焦核心用户场景。所以对重架构产品，信息框架更难，且更重要。
我在华为的设计工作包括轻架构产品和重架构产品。
设计轻架构产品的好处是轻松、愉快，用户一般容易共感感知，甚至用户就是你自己。难点在于突破和创新。
设计重架构产品的好处是对交互设计师是一次磨练交互技能的好机会，信息架构越复杂，对交互设计的要求就越高，锻炼效果越好。难点在于，重架构产品需要对业务的理解透彻，业务理解门槛高，海量功能不能做精简，用户是陌生群体需要用户研究的支持才能理解用户，信息结构复杂导致交互设计难度高、错误率高、费力。设计重架构产品对全局观的要求非常高。
下面我会根据Jesse James Garrett在“用户体验要素：以用户为中心的产品设计”书中关于信息结构的分类为维度，讲述一下这些结构在用户体验设计的信息架构设计中的作用，并会举一些真实案例来讨论如何使用这些结构以帮助思考。
1，层级结构 hierarchical structure
“在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。”
这是最常见的一种方式，树状图、家族图谱等，都是这个路线。这个路线蛮符合大自然的。这个结构相信大部分设计师都使用过，所以普通场景不做过多讨论。这里我想重点讲的是层级结构的一种平衡式使用方式。
什么是平衡式使用方式呢？这个也是我最近想出来……首先我们知道，层级结构可以带来两种设计思路。
第一种，从上到下。从产品主要愿景，一步一步细分到每个功能特性。
第二种，从下到上。从对用户有价值的功能特性开始，一步一步往上倒推到产品灵魂。
如果你读了我上一篇关于设计流程的思考，这两种方式就是战略层、范围层双向的方式。
第一种很容易理解，战略定了一个大方向，管理层传达并指导，执行层输出，一步一步分解任务直到任务量清晰、执行后得到产品结果。
第二种在重架构产品中使用的不少，例如一个给中国电信客服做的ToB产品，得先了解客服人员每天工作的任务流、操作流、所需模块集合，然后倒推规整为一个一个功能模块，再倒推形成一个系统。
最近我做重架构产品，第二种方法用的蛮多。是有点费脑子，但是嘿嘿，我研究生博弈论这门课是A+呢不怕不怕。lol
这两种方式都有缺陷。
我举一个近期的设计例子，是一个重架构产品，首先，产品的战略层已经确认，换言之，从上到下是合理的思路；但是，产品过于复杂且功能特性多、合作部门跨度大，这时看上去从下到上才是正解。
问题就出现了。如果从上到下分解，到了底层功能特性太多且不合使用逻辑，就紊乱了。如果从下到上倒推，功能特性有组合逻辑，但是到了顶层，产品灵魂又很难对上最开始战略层制定的方向。
怎么办呢？再看一下这个图：
我把战略层的第一点，最高父节点，称为大将；把底层众多的功能特性称为小兵。现在的问题是，大将下达指令，小兵凌乱；小兵自行组合，大将不能接受结果。所以我想，应该使用最高父节点和底层节点中间的那些点，我称为队长。队长整理小兵，形成合力的队伍，队长对大将负责，在队长层合力融合，最终完成军队的战斗力合成。
这就是我对平衡式使用方式的思考过程。从上到下不行，从下到上也不行，就从中间动手。我们把海量的功能特性与系统架构师确认好，然后通过用户访谈对我们针对的目标用户进行测试，让他们对海量功能特性进行认知并分组。这时候，一个经过系统架构师和目标用户验证的中层结构就定好了。这时候“队长”已经产生。此时，再思考战略层对产品特质、灵魂的定位，顺推合理的中层结构，这时，另一群“队长”也产生了，他们是能实现战略层（父节点）要求的。然后两组“队长”开始融合，从中间出发，对上对下各做调整和妥协，最后得到一个统一信息架构。这个结果的重点是中层结构“队长”。这个中层结构向上能满足战略层的要求，向下能满足底层海量特性功能的实现。
问题解决了。
交互设计需要精进的一个点，就是解决复杂信息结构。解决复杂信息结构的过程和结果，会直接影响交互设计师的设计执行力和设计影响力。
2，自然结构 organic structures
“自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。如果你想要鼓励自由探险的感觉，比如某些娱乐或教育网站，那自然结构可能会是个好的选择；但是，如果你的用户下次还需要依靠同样的路径，去找到同样的内容，那么这种结构就可能会把用户的经历变成一次挑战。”
这样的模式在现在的ToC产品越来越多（特别是游戏娱乐产品）。它符合轻架构产品的浏览式形态。
有一种经典的区分用户场景的维度是：任务式、浏览式。
任务式的特点：完成任务、快、准确、效率，例如查询某个航班到达的时间。
浏览式的特点：碎片、时间充裕、逛、发散、不聚焦、注意力吸引式，例如漫无目的地刷微博、看知乎。
自然结构很适合轻架构产品的浏览式形式。因为第一，重架构产品，ToB产品，如果用户需要靠浏览靠猜来使用产品特性完成任务，那肯定结果是不好的，用户会崩溃；第二，ToC产品一般就有两种形态，如果不是任务式，那很有可能就是用户在无聊，需要进入浏览式。
当然，完全自然结构的设计方式很少（不知道最近很火的秘密算不算）。大部分ToC产品应该是任务式和浏览式并行的。所以自然结构，应该是绑定其他信息结构来思考。
例如腾讯视频。自然结构肯定是应该考虑绑定层级结构来思考。用户进入视频产品，可能的一种使用方式是，用户心里已经有一个明确的思路，找2014年美国电影看，所以用户进入种类选择，选择电影，选择美国电影，选择2014年，然后进行浏览。这个可以算是先层级结构思考、后自然结构思考。如果用户是在家里喝茶，想看看视频，但是没有任何目的，打开了视频产品，那他们就是进行浏览式操作，这个时候自然架构就产生价值。用户在首页进行无逻辑浏览，从首页某个电视剧点入，看看详情，不感兴趣，从该电视剧的推荐点击到下一个电视剧，然后不感兴趣，然后从这个电视剧的主演想到他正在演出的一个电视真人秀，又跑去综艺里浏览。
每个产品对层级结构和自然结构的偏重是不同的。例如电商类产品，大部分人去天猫是有明确购买目的的，这个时候任务类操作会更重要；但是有没有完全没有购买目的，就是想去天猫花点钱或者找点折扣产品呢？肯定有，但是可能不如第一种用户多。
所以在信息架构设计中，我认为自然结构会是一个重要思考点，因为我们设计师要时刻记得，用户不是理性的，他们很多时候的操作和想法会呈现随机状态。但是自然结构不是唯一的，必须有层级结构、线性结构、矩阵结构等其他信息框架来配合和约束，才能让这个产品的整体信息架构完整、可用、有效。
3，线性结构 sequential structures
“线性结构来自于你最熟悉的线下媒体。连贯的语言流程是最基本的信息结构类型，而且处理它的装置早已被深深地植入我们的大脑中了。书、文章、音像和录像全部都被设计成一种线性的体验。在互联网中线性结构经常被用于小规模的结构，例如单篇的文章或单个专题；大规模的线性结构则被用于限制那些需要呈现的内容顺序对于符合用户需求非常关键的应用程序，比如教学资料。”
线性结构比较容易理解。更多呈现在帮助文档、产品故事讲述等场景。就不多描述了。
这里我想重点提一下就是线性结构是另外一种练习交互设计逻辑的方法。一个极端是复杂信息架构（层级、自然、矩阵等），另一个极端就是线性结构。如何用连贯的语言方式讲述一个故事，但是不能进行跳转和穿插，要一条线把思路讲清楚，反而不是一件简单的事情。
所以交互设计需要锻炼两个极端的信息架构描述方式。一个是复杂信息架构，充满了层级、跳转、补充、交叉；一种是极简的线性架构，一根主线讲清楚一个故事，甚至是复杂的故事。
4，矩阵结构 matrix structure
“矩阵结构允许用户在节点与节点之间沿着两个或更多的“维度”移动。由于每一个用户的需求都可以和矩阵中的一个“轴”联系在一起，因此矩阵结构通常能帮助那些“带着不同需求而来”的用户，使他们能在相同内容中寻找各自想要的东西。举个例子来说，如果你的某些用户确实很想通过颜色来浏览产品，而其他人偏偏希望能通过产品的尺寸来浏览，那么矩阵结构就可以同时容纳这两种不同的用户。然而，如果你期望用户把这个当成主要的导航工具，那么超过三个维度的矩阵可能就会出现问题。在四个或更多维度的空间下，人脑基本上不可能很好地可视化这些移动。”
这个结构非常好理解。这里想讲的是，现在大部分设计团队的KPI评估方式，就是矩阵结构。一方面，向业务线负责，以设计支撑产品商业成功；一方面，向设计线负责，以设计专业经验支撑团队专业影响力建设和技能成长建设。设计师如何平衡这个矩阵结构管理方式，是设计师成长的关键点之一。
设计师做完一个产品，一定要回头从信息架构层开始往下想，这个产品信息架构你做了什么样的创新、调整，产生了什么价值。不要仅仅拘泥于做界面元素的规范、设计细节问题解决沉淀等。因为信息架构，是交互设计大局观的最好锤炼基石。
谢谢阅读！：）
thanks,
yoyo