信息架构(Information Architecture, IA)= 怎么组织、分类、命名一个网站/App 的内容,以及内容之间怎么关联的整套实践。注意它不是一张图、不是一个工件,而是一个持续优化的过程——内容会变、用户会变,IA 也跟着迭代。
一个生活类比:IA 之于网站,就像一栋大楼的空间规划。用户进门看到的指示牌、电梯按钮(= 导航)只是冰山一角;背后还有一整套"哪个房间放什么、楼层怎么分"的全套蓝图(= IA 结构),以及一套"每个物品贴什么标签、怎么归类"的编目系统(= 分类法)。三者协同,大楼才好用。
这 6 篇按三条主轴读:
(1) IA 是什么 + 三个核心模型 —— 把"可见导航 / 底层 IA 结构 / 分类法"三层分清,再辨析"IA vs 网站地图"(最常被混为一谈的两个词)。
(2) 结构怎么搭 —— 内容到底是摊平(扁平层级)还是分层埋深(深层层级)?这是 IA 的第一个硬决策。
(3) 导航与内容页怎么落地 —— 左侧垂直导航什么时候用、分类法怎么从零构建、以及一个高频踩坑的具体页面(隐私政策/使用条款页)怎么救。
一、IA 是什么:三个核心模型 + 它和网站地图的区别
IA 抽象难定义,NNGroup 把它拆成三个模型来理解。关键在于分清"用户能看到的"和"团队内部用的",以及"组织内容"和"组织概念"。
| 模型(EN / 中) | 是什么 | 前台/后台 | 类比(大楼) | 用户能看到吗 |
|---|---|---|---|---|
| 可见导航 Visible Navigation | 指引用户"我在哪、能去哪"的 UI:菜单、链接、面包屑(breadcrumb)、折叠面板(accordion) | 前台 Front Stage | 指示牌、电梯按钮(只看到有限区域) | 能,且直接交互 |
| 底层 IA 结构 Underlying IA Structure | 全站所有关键页面/屏幕 + 相互关系的完整地图,团队据此设计导航、决定内容归属 | 后台 Back Stage | 全套建筑蓝图(整栋楼,不止当前楼层) | 看不到,但比可见导航详细完整 |
| 分类法与元数据 Taxonomies & Metadata | 描述每条内容特征、并把相似内容关联起来的逻辑分类体系(概念图) | 后台(偶尔以筛选/搜索建议露头) | 物品的"标签编目系统" | 基本看不到,部分以筛选/搜索建议形式呈现 |
三者的分工与关系(必背):
| 维度 | 可见导航 | IA 结构 | 分类法 |
|---|---|---|---|
| 服务对象 | 用户(操作入口) | 设计团队(规划工具) | 系统(内容关联/检索) |
| 强调什么 | 直观、简单,贴用户心智模型(mental model) | 全面、逻辑 | 逻辑精准、概念关系 |
| 组织的是 | 路径 | 内容(content) | 概念(concept) |
| 技术化程度 | 最低 | 中 | 最高、最广 |
心法:可见导航追求"符合用户怎么想",分类法追求"逻辑上分得准"——这两个目标常常打架,所以才需要把它们拆成不同的层各管各的,而不是用一套结构硬扛两个需求。Why:用户脑子里的分类(比如把"退货"归到"我的订单")和逻辑上最干净的分类(把"退货"归到"售后政策")不一定一致;导航迁就前者,分类法服务后者,各取所长。
IA vs 网站地图(Sitemap):最常见的混淆
很多人把"画个网站地图"当成"做 IA"。错。NNGroup 用一个同心圆讲清楚:IA 是最外圈的整套活动,网站地图只是最内圈的一个产物。
| 圈层(由外到内) | 名称 | 包含什么 |
|---|---|---|
| 外圈 | IA 活动 IA Activities | 内容清单 Content Inventory(识别归类所有内容)+ 内容审计 Content Audit(评估保留/移除/更新)+ IA UX 研究(卡片分类 Card Sorting、树测试 Tree Testing,摸清可发现性与组织方式)+ 分类法与标签 Taxonomies & Tags |
| 中圈 | 网站结构规划 Plan Website Structure | 内容组织(怎么分组、分层)+ 导航设计 |
| 内圈 | 网站地图 Site Map | 可视化内容层级与页面关系 + 当规划/沟通工具 |
| 对比维度 | 信息架构 IA | 网站地图 Sitemap |
|---|---|---|
| 本质 | 抽象的整体实践/过程(分类、命名、可发现性、导航逻辑) | 具体的视觉工件(一张层级图) |
| 覆盖面 | 全:含用户研究、内容分类、标签设计 | 窄:只展示页面层级和流向 |
| 关注点 | 标签、分页、搜索栏、面包屑等细节 | 不关注具体导航组件或命名 |
| 用途 | 规划整体内容架构(持续优化) | 跟团队/利益相关者沟通、规划 |
NNGroup 自己的网站地图示例:用颜色编码层级——蓝色节点 = 一级信息,绿色 = 二级对象,黄色 = 三级对象,直观呈现 nngroup.com 的内容层次。
反例/陷阱:只交付一张网站地图就宣称"IA 做完了"。网站地图不含内容分类、不含用户研究细节、不含命名逻辑——它是 IA 的产物之一,不是 IA 本身。两者都不是一锤定音,会随用户研究和网站迭代不断调整。
二、第一个硬决策:扁平层级 vs 深层层级(Flat vs Deep Hierarchies)
内容确定后,第一个结构性决策是:顶级类别摊多宽、往下埋多深。这是个权衡,没有绝对优劣。
| 维度 | 扁平层级 Flat | 深层层级 Deep |
|---|---|---|
| 顶级类别数量 | 多(一眼看到所有主类) | 少(顶层简洁) |
| 层级深度 | 浅 | 多层子类 |
| 交互成本(点击次数) | 低,少点几次就到 | 高,路径长 |
| 可见性 | 强,范围一目了然 | 低,整体结构不易掌握 |
| 主要风险 | 信息过载:类别太多让人不知所措、可能跳过重要项 | 认知负担:少量类别硬塞大量内容→类别名模糊难懂 |
| 适合场景 | 需要快速查找 | 信息密集、内容量大需分层管理 |
真实案例(数字必记):
| 网站 | 结构 | 具体数字 |
|---|---|---|
| 新西兰政府网站 | 扁平 | 15 个顶级类别,方便快速浏览 |
| 安永会计师事务所 Ernst & Young | 深层 | 只 5 个顶级类别,但"服务"下有 11 个子类,"咨询"子类下又含 10 个进一步细分 |
心法 / 综合建议:① 避免极端——过于扁平(类别太多)或过于深层(埋太深)都出问题;② 适度扁平 > 适度深层——因为更多选项可见,用户更直观地理解网站提供什么;③ 用户研究是关键——通过用户测试和需求研究,摸清用户的内容认知模型和关心重点,再定结构。Why:可见性是用户建立"这网站有啥"整体认知的前提,扁平用可见性换交互成本,通常更划算;但"多扁平才不过载"必须靠测试找,不能拍脑袋。
三、导航落地:左侧垂直导航(Left-Side Vertical Navigation)什么时候用
垂直导航(导航栏竖排在屏幕左侧)特别适合内容多、分类广、还会持续增长的网站。它能容纳更多顶层分类、方便快速扫描,代价是占用页面空间。
为什么选垂直导航(4 个理由):
| 理由 | 机制 | 关键数据/例子 |
|---|---|---|
| 1 容纳更多分类、提升可发现性 | 不受水平空间限制,能显示更多具体、高信息气味(information scent)的分类,不必缩短名字或减少数量;用户不用先点泛泛的顶层再找具体内容 | 阿伯尔餐厅(Abel)轻松容纳 13 个全球导航类别 |
| 2 支持未来扩展 | 加新分类不用重设计整个导航 | 适合大学、政府、医疗等内容不断增长的机构 |
| 3 更易快速扫描 | 用户视线偏向左侧,80% 注意力集中在屏幕左半部分;垂直列表一眼获取更多信息,比水平来回移动高效 | —— |
| 4 用户熟悉易用 | 桌面应用里非常常见,用户已习惯 | Slack、Gmail 都用左侧垂直导航 |
挑战(2 个):① 占用更多空间——压缩内容区,小屏/平板尤甚;② 超长菜单藏重要项——分类被挤到"页面折叠(the fold)"以下(屏幕外),要滚动才看到。
内容/装饰比(content-to-chrome ratio)案例:Nua 自行车旧设计用左侧垂直导航,内容与界面元素比约 5:1;重新设计改水平导航后,同屏尺寸下比例升到 12:1——可见导航里顶级类别少多了,但内容空间大幅增加。反观 IBM Watson Studio:在超大显示屏上,垂直导航对内容/装饰比影响可忽略,因为左右两侧本就加了留白(或深色背景空白)。
5 条最佳实践:
| # | 实践 | 怎么做 / Why | 反例 |
|---|---|---|---|
| 1 | 左对齐并设计得醒目 | 放屏幕左侧(适合从左到右阅读的语言);用颜色/边框与页面其余区分;避免右侧导航(用户对右侧关注少,易错过) | 奥迪(Audi)设计系统用高对比深色背景确保左侧导航醒目易读 |
| 2 | 不重复导航 | 别同时用水平+垂直导航显示相同内容,造成困惑冗余 | BDO 咨询同时用水平栏 + 右侧汉堡菜单,两者项目完全相同(汉堡多了地点/事件/新闻),纯属多余 |
| 3 | 避免只用图标 | 图标必须配文字标签;只用图标增加认知负担,用户得猜或额外点击 | NOAA 默认只显图标,必须点击后才看到分类名,徒增操作成本 |
| 4 | 优化超长菜单 | 把最重要选项放可见区;不太重要的放菜单底部;必须长菜单时再提供搜索/筛选作补充查找方式 | Sunglass Hut 旧方案文本居中对齐,形成参差边缘,削弱了垂直列表的扫描优势 |
| 5 | 移动端适配 | 垂直导航能自然适配移动端,只需调布局细节,无需大改 | heywoodgolf 的垂直导航从桌面到移动只做少量改动即适配 |
反例(整体):埃森哲(Accenture) 把广泛的信息空间全藏在单一"服务"类别下,人为限制顶级类别数量——结果特定咨询领域可查找性降低、交互成本增加(用户被迫逐个打开顶级类别浏览、确认不合适再退出)。这正是"为了顶层好看而牺牲可发现性"的典型病。
四、分类法 Taxonomy:后台的"标签编目系统"怎么从零建
分类法(Taxonomy)是 IA 的后台结构,用一套规范的元数据规则把内容打标签、建立逻辑关系,弥补可见导航系统可能遗漏的内容关联。网站上每条内容都用一个或多个分类法术语标记,后端据此把用户引向相关内容。
三大核心特征:
| 特征 | 含义 |
|---|---|
| 受控词汇 Controlled Vocabulary | 一个有限的、预定义的术语集合,供内容创作者标记新内容时使用 |
| 层级结构 | 术语按父子关系排列(如"汽车"下有"个人用车""共享用车") |
| 不可扩展性 | 内容创作者不能随意新增术语,只能用既定的 |
分类法能干什么(3 大用途):
| 用途 | 机制 | 真实例子 |
|---|---|---|
| 构建内容关联 | 基于分类法做相关内容推荐(比导航里高层级分类精准得多) | NN/g 网站的相关文章推荐,来自详细分类法而非导航的高层分类 |
| 支持分面导航 Faceted Navigation | 用户同时应用多个筛选维度,精准定位,不必深钻繁琐层级 | 美国国会图书馆左侧搜索方面:主题、部分/馆藏、原始格式等多维筛选,由强大的分面分类法实现 |
| 改进搜索建议/结果 | 系统据分类法推荐更准的术语或优化结果 | 世界银行:用户输首"欧洲人口…",系统建议首选术语"人口,总数,欧盟"及相关类别 |
分类法 vs 其他元数据工具(复杂度递增):
| 工具 | 支持的关系 | 复杂度 / 用途 |
|---|---|---|
| 分类法 Taxonomy | 主要是父子关系;可单一层级,也可分面(多维度) | 基础 |
| 叙词表 Thesaurus | 父子 + 同义关系(等价术语)+ 关联关系(相关但不同) | 中;解决术语一致性、提高检索完整性 |
| 本体论 Ontology | 最多种语义关系(位置、属性、状态等) | 最复杂;用于技术领域、描述复杂知识的多维信息 |
图示辅记:① 北极熊在分层分类法里只按单一"亲子/类-成员"关系归类;② 同一辆车在分面分类法里,每个属性(共享/个人/载货)各有一个独立的小层级,允许细粒度特征组合;③ 本体论能超越亲子关系,捕捉北极熊的保护状况、栖息地等其他属性关系。
怎么构建分类法(8 步流程):
| 步骤 | 做什么 |
|---|---|
| 1 内容清点与审计 | 确定要组织的内容及范围 |
| 2 参考现有分类法 | 查行业标准分类法可否复用/修改(可上 BARTOC.org 找资源) |
| 3 定义核心概念 | 从内容、用户数据(如搜索日志)、业务需求中提取概念 |
| 4 评估术语 | 确保术语与用户需求相关,避免孤立或覆盖过窄的术语 |
| 5 选首选术语与替代术语 | 用户会接触到的术语,优先选信息清晰、用户友好的 |
| 6 构建概念关系 | 定义父子关系和关联关系 |
| 7 迭代与审核 | 与利益相关者、主题专家(SME)一起完善,确保适用性 |
| 8 应用 + 维护 | 给内容打标签、培训内容管理者;建立定期审查机制(增/合/删术语) |
心法:分类法是"后台基础设施",用户基本看不到却决定了搜索、推荐、筛选好不好用。Why:它的价值恰恰在于"逻辑精准"——把可见导航做不到的细粒度内容关联,在后台用受控、稳定的术语体系兜住。反例隐含:让内容创作者随意造标签(违反"不可扩展性"),术语很快漂移失控,关联和检索全废——这就是为什么分类法必须受控 + 有维护机制。
五、一个高频踩坑页面:隐私政策/使用条款页的 5 大错误
隐私政策(Privacy Policy)和使用条款(Terms of Use)页常被当成"法务交差",忽视用户体验,导致晦涩难懂、难导航,反而损害用户信任。NNGroup 总结 5 类常见错误 + 优化方向。
| # | 错误 | 问题表现 | 优化建议 | 正例 / 反例 |
|---|---|---|---|---|
| 1 | 语言晦涩或过于模糊 | 满是法律术语,用户读不懂或觉得公司在隐瞒 | 用通俗语言;给具体示例(如列出与第三方共享的数据类型 + 政策链接);提供简化概要 + 保留详细条款备查 | 正:LinkedIn 含通俗书面摘要 + 视频摘要链接 + 全页"解释"。反:Ameren 被用户吐槽"宽泛不严谨,等于说'我们可以为所欲为'" |
| 2 | 缺乏政策概述 | 只显更新时间,不说更新了什么 | 页顶给简明概述(范围、关键点、最近更新);附更新内容简要总结,不只给日期 | 正:eBay 专设页面汇总所有政策 + 简要概述,研究参与者评价"非常简单,问题都能在这页回答"。反:Forever 21 大段无摘要文本,被认为"给律师看的" |
| 3 | 排版不佳 | 字体太小、大段文字无分隔、全大写 | 字体至少 14pt;合理分段、加粗重点;避免全大写;确保移动端+桌面端都易读 | 正:Google 移动+桌面页被赞"容易""直截了当"。反:Instagram 移动端长窄文本列浪费空间;Spotify 条款全大写,用户问"为什么全是大写字母?" |
| 4 | 导航功能不完善 | 缺有效目录,难快速定位具体内容 | 提供清晰目录 + 链接到具体章节;用左侧导航或折叠菜单简化长内容查找 | 正:Eventbrite 法律条款页先按受众分类、再按主题分类,清楚知道每项政策适用谁。反:Eventbrite 自己的隐私政策页内目录虽有功能却无信息线索(no information scent)、无法有意义地导航 |
| 5 | 信息不在预期位置 | 用户习惯在页脚或设置页找政策链接,有些网站没按此布局 | 在页脚统一加政策链接;在相关功能页(如通知设置)提供该功能相关的政策摘要+链接 | 正:Facebook 多途径可达(主菜单/设置菜单/隐私快捷页顶部和底部)。反:Clear Care Web 应用登录后无页脚,参与者找不到隐私政策,最终诉诸搜索仍无果 |
心法:透明性是关键——政策页要以用户为中心,用简洁的语言和设计增强可读性。一个设计良好的政策页不只满足法律要求,还能提升用户对品牌的信任。Why:这页天然是"低体验默认值"(法务主导、术语堆砌),所以它是检验一个团队"是否真把 IA 原则贯彻到边缘页面"的试金石——上面 5 条几乎都是前面 IA/导航/分类/排版原则在一个具体页面上的集中落地。
源自 NNGroup Topics / Information Architecture - 信息架构(6 篇)。可用性原则(10 大启发式、可发现性/可查找性、信息气味)与可用性测试方法见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估);导航与系统组件的平台级规范见 Apple HIG 交互模式 Patterns(25 个流程模式 · 上手/输入/反馈/媒体/系统协作)。图片(IA 三模型示意、nngroup.com 网站地图、国会图书馆/世界银行分面导航、车辆分层 vs 分面分类法、北极熊本体论、各导航与隐私政策页截图、NOAA 图标视频)与原档保留在 sources。