当用户「找不到东西」或需要设计/重构导航、分类、标签…

适用于信息「结构组织」本身是问题的时候（导航模式、分类法、标签命名、搜索与浏览、寻路与 IA 研究），而非流程顺序、文案或视觉呈现问题。

适用场景

解决思路

1. 先确认问题属于信息架构：只处理信息的结构组织（类别、层级、关系、标签）；若问题是流程顺序、措辞或视觉呈现，转交对应环节。
2. 按内容结构与用户任务选择导航模式并给出针对本产品的取舍分析：层级式（有清晰父子关系、重叠少）、枢纽-辐条式（任务模式分明的应用）、扁平式（≤7–10 项的小内容集）、分面式（属性丰富的大数据集）、仪表盘式（监控与概览，不适宜作为任务主导航）、顺序向导式（线性有依赖的流程）、全局+局部导航（规模化产品通常两者都要，并明确二者替代/嵌套/并列的关系）。
3. 设计分类法时遵循 MECE：类别互斥（一条内容归一个类别）、集合穷尽（一切都有归属），目标是减少重叠、消除孤儿项，而非理论纯粹。
4. 结合自上而下与自下而上：先由懂领域的人搭出逻辑完整的结构，再用卡片分类、搜索日志等用户数据校验修正。
5. 审慎使用多父级（polyhierarchy）：只在条目确实跨类别时有意使用；若几乎一切都需要多归属，说明类别划分本身有错。
6. 面向增长设计分类法：按未来规模（例如两年后的 30 个类目）先设计结构逻辑，即使当下只填充 3 个，让新增类目是「扩展模式」而不是「重构系统」。
7. 用研究验证分类法：树测试验证能否找到条目、首点测试验证顶层类目是否传达内容、反向卡片分类验证类目是否符合用户心智模型；统计可靠需 50+ 参与者。
8. 标签要说明「目的地」而不是「类别」：不要用 Resources、Account 这类含糊词，改成「帮助文档、教程与 API 参考」这类能预测内容的名字。
9. 用三种方法测试标签：5 秒测试（看导航 5 秒后问每项下会有什么）、完形填空测试（遮住标签看内容猜标签）、线上 A/B 测试标签变体对点击率/完成率/工单量的影响。
10. 规避常见标签失败：内部行话（团队叫 Workspace、用户叫 My projects）、含糊标签（Dashboard/Overview/Home 说不清区别）、重叠类别（Tools/Features/Products）、格式标签（Resources/Library/Hub 只描述容器不描述内容）。
11. 同时支持搜索与浏览两条路径：搜索用自动补全（减少输入、纠错、热门查询）、过滤器、分面检索、零结果恢复；浏览用类目与子类目、标签、策展集合（编辑推荐、本周热门）、最近浏览、相关条目。
12. 按用户专业度调整搜索/浏览比重：新用户不知道有什么、该怎么称呼，靠浏览；专家用户目标明确，靠搜索；只做搜索会惩罚新用户，只做浏览会惹恼专家。
13. 设计搜索与浏览的混合路径：先浏览到类目再在类目内搜索，或搜索后通过分面过滤继续浏览。
14. 把零结果当作设计问题而非边缘情况：提供 did-you-mean 建议、拼写纠正、更宽泛的类目建议、热门条目，以及明确的转浏览入口。
15. 用四个寻路问题检查方向感：我在哪（面包屑、导航激活态、页面标题、区块标题）、我能去哪（菜单、链接、CTA、相关内容，配合渐进披露）、我是否走对（进度指示、确认信息、一致模式）、我是否到了（落地内容与标签承诺一致）。
16. 排查用户迷路的六类原因：一次给太多选项（顶层超过 7–9 项）、不同区块模式不一致、缺少持久地标、没有明确的「首页」可退回、深层嵌套且无面包屑、标签与内容不符。
17. 把寻路线索当系统来设计：面包屑、激活态、页面标题、区块指示、上下文导航要共同强化「用户在哪、有哪些选择」这一信息。
18. 做卡片分类：开放式（参与者自建并命名类目，至少 15 人，用相似度矩阵与树状图分析）揭示自然心智模型；封闭式（30+ 人）检验既有类目是否直觉；混合式（预设类目+可新建）兼顾两者。
19. 做树测试：只给纯文本层级、无视觉无内容，用任务式提问（「你会在哪里找到 X？」），测量成功率与直接性（是否直抵或回溯），50+ 人。
20. 做首点测试：看用户为完成任务第一次点击哪里；首点错了会使整体任务成功率骤降，用它验证顶层导航类目是否传达内容。
21. 按顺序组合研究：先用开放卡片分类发现心智模型 → 据此起草分类法 → 用封闭卡片分类与树测试验证 → 上线后用首点测试打磨导航。
22. 分析搜索日志：本应可浏览却被高频搜索的条目说明 IA 失败；零结果搜索说明标签与用户词汇不匹配；热门查询应能干净地映射到顶层导航，映射不上就是 IA 缺口。
23. 做竞品与同类产品的 IA 分析：不为照抄（对方可能同样糟糕），而是了解用户已熟悉的惯例；在合理处沿用可降低学习成本，有意打破需有明确收益。
24. 按需组织交付物：IA 评估（哪里好、哪里坏、为什么，附研究/分析/支持数据）、站点地图与导航结构（含结构与交叉链接及关键决策依据）、导航规范（模式选择与取舍、全局/局部行为、响应式适配、各种状态）、分类法文档（类目定义、层级规则、多父级决策、扩展性说明、新内容如何归类）、标签指南（批准的标签与理由、命名约定、被否标签及原因）、搜索/浏览策略（何时搜何时逛、自动补全行为、过滤设计、零结果处理、浏览入口）、IA 测试计划（研究方法、参与者要求、任务场景、成功指标）、待解决问题。
25. 需要可视化时先向用户确认是否要 IA 图及其格式（HTML 默认、Figma、pencil.dev、不要），请求中已表明偏好则跳过提问；HTML 输出单个自包含代码块（无外链 CSS/字体/JS），包含给定的 token 样式块，用 sitemap-node / sitemap-node-primary / sitemap-node-action 三种节点状态与虚线子级缩进、可选 tab bar，且保留明暗双主题；Figma 输出需先加载 /figma-use 再调用对应 MCP 工具并按同样规则转译；pencil 输出用 open_document 新建、set_variables 设置 token、batch_design 插入结构。
26. 按用户心智模型组织信息，而不是按组织结构：不要让「Billing 属财务团队、Subscription 属产品团队」这类内部归属决定分类。
27. 用用户的词命名：数据库叫 user_preferences、接口叫 /settings、团队叫 configuration，但用户叫「我的账户」，就用用户的说法。
28. 用测试替代假设：设计师与产品团队会形成与用户背离的专家心智模型，看起来显然的东西对用户可能不可见，提交结构前先做卡片分类。
29. 不要迷信「越简单越好」：40 项的扁平结构比每层 5 项的三层结构更糟；简单指结构恰当，而不是层级最少。
30. 与相邻技能显式协作并说明「我不决定什么」：策略定义受众、调研提供卡片分类/树测试数据、旅程负责步骤序列、线框图负责结构在屏幕上的位置与突出度、文案负责标签用词、蓝图决定技术上可行的结构、评估做启发式检查、本地化处理跨市场差异。
31. 当产品快速扩张时主动重访 IA 而不是打补丁：为 50 条内容设计的结构在 500 条时失效、5000 条时崩塌，为创业公司 3 个类目设计的分类法无法服务企业级 30 个类目，事后改造比面向增长设计更难。
32. 当不同用户群体心智模型冲突时，按主要受众设计，用替代路径（搜索、交叉链接、快捷方式）支持次要群体，而不是强行造一个对所有人都勉强可用的结构。
33. 交付前自问：用户怎么想这些信息（而不是我们怎么想）？人们在搜什么本该能浏览到的内容？用户在哪迷路、回溯、放弃？内容翻倍后结构还成立吗？组织结构长什么样、我们是不是在无意中照搬它？这是测过的还是假设的？

适用边界 · 注意事项

• 当问题出在用户如何一步步走完流程（交 /journey）、页面上的排布与突出度（交 /wireframe）、文案用词（交 /articulate）、视觉呈现、技术架构（交 /blueprint）、导航组件无障碍实现或内容创作时，不要用本技能。
• 当结构本身没问题、只是流程走不通或页面不可读时，属于其他环节的问题，改结构可能白费功夫。
• 没有任何用户研究、搜索日志或支持数据、且不打算做验证时，做出来的 IA 只是内部假设的投影，风险高。