信息架构处理内容的组织、标签与关系
别名: IA · 内容结构 · organization labeling relationships
概念解释
信息架构（information architecture）处理的是内容本身如何被分成组、每组叫什么、组与组之间是什么关系。它的对象是内容集合，不是控件样式。Rosenfeld 与 Morville 把组织体系、标签体系和关系结构当作架构工作的本体：先决定「发票」和「对账单」算不算一类、对外叫「账单」还是「财务」、它们跟「合同」是父子还是相关，然后才谈菜单怎么画。导航和搜索是消费这套结构的通路，不能反过来冒充结构本身。
把信息架构理解成「画站点地图」会窄掉。站点地图只是层级的一种投影；分面、交叉链接、内容类型之间的引用，同样是架构要处理的关系。
机制
人不会记住整张结构图，而是从三件事推断「这里是什么地方」：哪些东西被放在一起（组织）、它们被写成哪个词（标签）、点进去会连到什么（关系）。三件事互相校准。同组却用两套叫法，组会在用户脑子里裂成两个概念；标签相同却没有关系可走，用户会以为点进去能到达对方，结果走进死路。架构失效通常不是「不好看」，而是这三件里至少一件与用户已有的分类习惯冲突，推断无法合拢。
关系不只是父子。顺序（教程第 3 步）、等价（同一政策的 HTML 与 PDF）、相关（这件商品的配件）会改变人下一步往哪走。只建层级、不建横向关系，内容会变成只能从上往下爬的树，跨主题的任务会被强迫绕路。
怎么研究
用内容建模和卡片分类分别检验组织和标签，用链接清单检验关系，不要一上来就测画好的界面。
- 范式：开放式卡片分类看用户自发分组；受控词表抽取看组织内部怎么命名；关系清单（parent / related / sequence）与真实任务路径对照。
- 自变量：分组方案、标签来源（用户用语 vs 内部用语）、关系类型是否被显式建出。
- 因变量：分组一致率、标签命中率、任务中走错关系边的次数。
- 方法论注意点：分类一致性高只说明组内像，不说明标签能被认出来，也不说明关系边能被用上。三件事要分开记分。树测试可以后续用来检验结构是否可走，但它测的是路径，不是「这套内容到底有没有被建模」。
边界
内容极少、任务单一的工具（一个计算器、一个手电筒）几乎没有「组织、标签、关系」可处理，硬套信息架构会把设置项分类得过细。强顺序的流程（结账、开户）主导结构的是步骤，不是内容分类；把步骤硬折成主题树，会让人找不到「下一步」。知识图谱和企业搜索里的关系比站点架构更密、更形式化，网站常用的父子加相关远不够描述，不能把那里的本体工程直接当成界面架构。
怎么落地
- 先按内容类型而不是按页面列清单：每类写清它属于哪组、对外叫什么、连向哪些其他类型。
- 组织、标签、关系分开开会，不要在同一张导航稿上同时改三类决定，否则改动无法回溯。
- 开放式卡片分类用真实条目，不用部门名；分类稳定后再冻结标签，最后才补「相关」和顺序关系。
- 验证：拿出一条真实内容，问未参与设计的人「它会被放进哪一组、你搜索时会键入哪个词、做完这件事下一步会去哪」。三问里任何一问答案分散，就还没有架构，只有一份菜单草图。