Back to Details

information-architecture-navigation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Information Architecture Navigation

信息架构导航

Purpose

目标

Help an agent make information easier to find, navigate, and understand. Treat information architecture as a product system made from organization, labeling, navigation, search, metadata, content structure, and wayfinding. Optimize for user tasks and comprehension before visual styling.
帮助Agent让信息更易于查找、导航和理解。将信息架构视为由组织方式、标签、导航、搜索、元数据、内容结构和寻路功能构成的产品系统。优先针对用户任务和理解性进行优化，再考虑视觉样式。

When to use this skill

何时使用该技能

Use this skill when the user asks you to:
  • Critique or redesign navigation, menus, breadcrumbs, tabs, sidebars, search, filters, faceted browsing, category pages, documentation structure, content hubs, settings IA, onboarding flows, product dashboards, or information-dense pages.
  • Create an information model, sitemap, taxonomy, label set, navigation model, content grouping, search UX, metadata schema, or IA style guide.
  • Improve findability, discoverability, wayfinding, content hierarchy, cross-linking, or search result quality.
  • Translate a content inventory or product feature set into a usable structure.
  • Implement IA-related frontend components such as nav landmarks, search forms, breadcrumbs, filters, result lists, menus, tabs, and content templates.
当用户要求你完成以下任务时，使用本技能：
  • 评审或重新设计导航、菜单、面包屑、标签页、侧边栏、搜索、筛选器、分面浏览、分类页面、文档结构、内容中心、设置信息架构、引导流程、产品仪表板或信息密集型页面。
  • 创建信息模型、站点地图、分类体系、标签集、导航模型、内容分组、搜索UX、元数据架构或信息架构风格指南。
  • 提升可查找性、可发现性、寻路体验、内容层级、交叉链接或搜索结果质量。
  • 将内容清单或产品功能集转化为可用结构。
  • 实现与信息架构相关的前端组件，如导航地标、搜索表单、面包屑、筛选器、结果列表、菜单、标签页和内容模板。

When not to use this skill

何时不使用该技能

Do not use this skill as the main skill when the user is only asking for:
  • Visual styling, brand expression, color, illustration, or motion with no navigation/findability impact.
  • Persuasive marketing copy that does not involve content structure or labels.
  • Backend search ranking algorithms, database indexing, or IR tuning beyond UX-level requirements.
  • Pure content writing unless structure, headings, labels, or navigation are part of the task.
当用户仅提出以下需求时，不要将本技能作为主要技能使用：
  • 不涉及导航/可查找性影响的视觉样式、品牌表达、色彩、插画或动效设计。
  • 不涉及内容结构或标签的说服性营销文案。
  • 超出UX层面需求的后端搜索排名算法、数据库索引或信息检索调优。
  • 纯内容写作任务，除非结构、标题、标签或导航是任务的一部分。

Core principles

核心原则

  1. Design for finding and understanding together. A structure that helps users locate information should also help them understand what the product contains, where they are, and what they can do next.
  2. Start from users, content, and context. Do not design from the company org chart alone. Inspect user tasks, actual content, business constraints, platform constraints, governance, and vocabulary.
  3. Support multiple paths when content is multidimensional. Use hierarchy for stable, mutually exclusive structures; use facets, tags, search zones, and contextual links when users approach the same content from different angles.
  4. Make the invisible IA explicit. Metadata, controlled vocabularies, aliases, result tuning, redirects, and editorial best bets shape the user experience even when users cannot see them.
  5. Use labels as promises. Every label should accurately predict the content or action behind it. Prefer familiar user language over internal terms or clever branding.
  6. Give users a sense of place. Every screen should answer: Where am I? What is here? Where can I go? What just changed? How do I get back?
  7. Treat search as a system, not a box. Search includes the indexed content, query entry, suggestions, spelling/synonym support, result presentation, ranking/sorting/filtering, no-results recovery, and analytics.
  8. Structure content from the bottom up. Headings, chunks, metadata, related links, and content templates should help users who enter deep from search, notifications, external links, or social sharing.
  9. Document decisions for reuse. IA must be maintained. Capture label rules, taxonomy rules, metadata fields, navigation placement rules, and exceptions in a style guide or design-system guidance.
  10. Accessibility is part of findability. Semantic structure, headings, landmarks, keyboard operation, visible focus, readable labels, and screen-reader names are IA requirements, not polish.
See references/principle-cards.md for each principle as a reusable card.
  1. 兼顾查找与理解的设计。帮助用户定位信息的结构，同时应帮助他们了解产品包含的内容、当前所处位置以及下一步可执行的操作。
  2. 从用户、内容和场景出发。不要仅依据公司组织架构进行设计。需考察用户任务、实际内容、业务约束、平台限制、管理规则和用户词汇。
  3. 为多维内容提供多种路径。层级结构适用于稳定、互斥的内容；当用户从不同角度访问同一内容时，使用分面、标签、搜索区域和上下文链接。
  4. 让隐性信息架构显性化。元数据、受控词汇、别名、结果调优、重定向和编辑推荐等，即使用户不可见，也会影响用户体验。
  5. 将标签视为承诺。每个标签都应准确预测其背后的内容或操作。优先使用用户熟悉的语言，而非内部术语或花哨的品牌用语。
  6. 为用户提供位置感。每个页面都应回答：我在哪里？这里有什么？我可以去哪里？刚刚发生了什么变化？如何返回？
  7. 将搜索视为一个系统，而非一个输入框。搜索包含索引内容、查询输入、建议、拼写/同义词支持、结果展示、排序/筛选、无结果恢复和数据分析。
  8. 自下而上构建内容结构。标题、内容块、元数据、相关链接和内容模板应帮助从搜索、通知、外部链接或社交分享直接进入深层页面的用户。
  9. 记录决策以便复用。信息架构需要维护。将标签规则、分类规则、元数据字段、导航放置规则和例外情况记录在风格指南或设计系统文档中。
  10. 无障碍是可查找性的一部分。语义结构、标题、地标、键盘操作、可见焦点、可读标签和屏幕阅读器名称是信息架构的要求，而非锦上添花的优化。
查看 references/principle-cards.md 获取可复用的单条原则卡片。

Default recommendations

默认建议

Use these defaults unless the user's product context makes another choice clearly better.
除非用户的产品场景明确需要其他选择，否则使用以下默认方案。

Product goal

产品目标

Default to organizing around the user's primary tasks and mental model, then reconcile business priorities second.
Override when the product is a regulated, archival, legal, or reference system where formal domain structure is the user expectation.
Ask before overriding: "Is this product primarily task-driven, reference/lookup-driven, commerce-driven, or compliance/archive-driven?"
默认围绕用户的核心任务和心智模型进行组织，其次协调业务优先级。
当产品是受监管的档案、法律或参考系统，且用户预期遵循正式领域结构时，可覆盖默认方案。
覆盖前需询问：“该产品主要是任务驱动型、参考/查询驱动型、商务驱动型还是合规/档案驱动型？”

Audience and vocabulary

受众与词汇

Default to plain, familiar, user-centered labels. Use internal terminology only when the target audience already uses it.
Override when the audience is expert, regulated, or domain-specific and precision matters more than beginner familiarity.
Ask before overriding: "Who is the primary audience, and what terms do they already use for these concepts?"
默认使用简洁、易懂、以用户为中心的标签。仅当目标受众已在使用内部术语时，才使用内部术语。
当受众为专家、受监管群体或特定领域用户，且精确性比初学者的易懂性更重要时，可覆盖默认方案。
覆盖前需询问：“主要受众是谁？他们对这些概念已使用哪些术语？”

Navigation model

导航模型

Default to a small global navigation, local navigation for deep sections, contextual links for related content, and breadcrumbs when hierarchy is deeper than two levels.
Override when the product is a single-purpose app, a flat marketing site, or a workflow where progress navigation matters more than place navigation.
Ask before overriding: "Do users usually browse by category, perform a task step-by-step, search for a known item, or compare/filter many items?"
默认采用小型全局导航、深层区域的本地导航、相关内容的上下文链接，以及当层级超过两级时的面包屑。
当产品是单一用途应用、扁平化营销网站或进度导航比位置导航更重要的工作流时，可覆盖默认方案。
覆盖前需询问：“用户通常按类别浏览、分步执行任务、搜索已知项目，还是比较/筛选多个项目？”

Hierarchy depth

层级深度

Default to broad-and-shallow enough to expose major choices without overwhelming users. Avoid deep trees unless categories are stable and predictable.
Override when the domain naturally requires hierarchy, such as documentation, file systems, policies, or catalog taxonomies.
Ask before overriding: "Are the categories stable and mutually exclusive, or do items naturally belong in multiple groups?"
默认采用宽而浅的层级，在不使用户感到 overwhelm 的前提下展示主要选项。避免过深的层级，除非类别稳定且可预测。
当领域自然需要层级结构（如文档、文件系统、政策或目录分类体系）时，可覆盖默认方案。
覆盖前需询问：“这些类别是稳定且互斥的，还是项目自然属于多个组？”

Content grouping

内容分组

Default to one dominant organizing principle per view: task, topic, audience, lifecycle, chronology, geography, format, or alphabetic. Do not mix schemes in the same menu unless sections are clearly separated.
Override when a landing page intentionally offers multiple entry modes, such as "By role," "By task," and "By topic."
Ask before overriding: "Which entry mode matters most for this user at this moment?"
默认每个视图采用一种主导组织原则：任务、主题、受众、生命周期、时间顺序、地理位置、格式或字母顺序。除非各部分清晰分隔，否则不要在同一菜单中混合多种方案。
当登录页有意提供多种入口模式（如“按角色”“按任务”“按主题”）时，可覆盖默认方案。
覆盖前需询问：“此时对该用户来说，哪种入口模式最重要？”

Labels

标签

Default to concise text labels with nouns for destinations and verbs for actions. Pair icons with text for primary navigation.
Override only when space is severely constrained and icons are universally recognized, tested, and accessible.
Ask before overriding: "Does the product already have validated terminology or a controlled vocabulary I should preserve?"
默认使用简洁的文本标签，目的地用名词，操作用动词。主导航搭配图标与文本。
仅当空间严重受限且图标是普遍认可、经过测试且无障碍的情况下，才可覆盖默认方案。
覆盖前需询问：“产品是否已有经过验证的术语或需要保留的受控词汇？”

Search

搜索

Default to adding search when content is large, dynamic, heterogeneous, or when users often know the thing they want. Provide a simple search box first, with scoped search or filters when content types differ.
Do not add search merely to compensate for poor organization. Fix labels, grouping, and metadata first.
Ask before implementing search-heavy UX: "What content should search cover, and are there content types that should be searched separately?"
当内容量大、动态变化、异构，或用户通常知道想要的内容时，默认添加搜索。先提供简单的搜索框，当内容类型不同时，再添加范围搜索或筛选器。
不要仅为弥补糟糕的组织而添加搜索。应先修复标签、分组和元数据。
实施重搜索UX前需询问：“搜索应覆盖哪些内容？是否有需要单独搜索的内容类型？”

Facets and filters

分面与筛选器

Default to facets when users need to narrow many items by stable attributes such as type, topic, date, location, audience, status, price, format, owner, or compatibility.
Override when the set is small, the attribute data is unreliable, or filtering would create empty/meaningless combinations.
Ask before adding facets: "Which attributes do users actually use to decide among results?"
当用户需要通过稳定属性（如类型、主题、日期、位置、受众、状态、价格、格式、所有者或兼容性）缩小大量项目范围时，默认使用分面。
当集合规模小、属性数据不可靠，或筛选会产生空/无意义组合时，可覆盖默认方案。
添加分面前需询问：“用户实际会使用哪些属性来筛选结果？”

Metadata and controlled vocabulary

元数据与受控词汇

Default to a lightweight controlled vocabulary for high-value fields, plus aliases/synonyms for common user language.
Override when content is low-volume, short-lived, or manually curated enough that formal vocabulary management would add more overhead than value.
Ask before formalizing vocabulary: "Who will maintain terms, aliases, metadata fields, and deprecated labels after launch?"
默认对高价值字段使用轻量级受控词汇，为常见用户语言添加别名/同义词。
当内容量小、生命周期短，或人工管理足够成熟，正式词汇管理反而增加负担时，可覆盖默认方案。
正式化词汇前需询问：“上线后谁将维护术语、别名、元数据字段和废弃标签？”

Responsive and cross-channel behavior

响应式与跨渠道行为

Default to preserving the same conceptual structure across web, mobile, and other channels while adapting presentation and interaction to each device.
Override when channel context changes the user's task, such as quick mobile lookup versus desktop bulk management.
Ask before changing IA across channels: "Do users need the same tasks on every platform, or does each platform support a different job?"
默认在网页、移动端和其他渠道保留相同的概念结构，同时针对每个设备调整展示和交互方式。
当渠道场景改变用户任务时（如移动端快速查询 vs 桌面端批量管理），可覆盖默认方案。
跨渠道修改信息架构前需询问：“用户是否需要在每个平台完成相同的任务，还是每个平台支持不同的工作？”

Accessibility

无障碍

Default to WCAG-aware semantic structure, visible focus, keyboard navigation, accessible names, text alternatives for icons, valid heading order, and state announcements for dynamic search/filter changes.
Do not ask whether accessibility matters. Ask only when a legal or internal compliance target must be named.
默认遵循WCAG标准的语义结构、可见焦点、键盘导航、无障碍名称、图标文本替代、有效标题顺序，以及动态搜索/筛选变化的状态通知。
无需询问无障碍是否重要。仅当需要指定法律或内部合规目标时才询问。

Frontend state

前端状态

Default to making navigation, search queries, selected filters, sort order, and pagination shareable/restorable in URLs for web products.
Override for privacy-sensitive, ephemeral, or native-only contexts.
Ask before overriding: "Should users be able to share, bookmark, or return to this exact filtered/search state?"
默认让网页产品的导航、搜索查询、选中的筛选器、排序顺序和分页状态可在URL中共享/恢复。
当涉及隐私敏感、临时或仅原生场景时，可覆盖默认方案。
覆盖前需询问：“用户是否应该能够共享、书签或返回此精确的筛选/搜索状态？”

Required user questions

必问用户问题

Ask only when the answer changes the IA. Recommend a default in the question.
Use a 
question
tool or equivalent for these cases:
  1. Goal ambiguity. If the user has not supplied the product, feature, user task, or content domain.
  2. Audience ambiguity. If labels or taxonomy depend on specialist versus general-public vocabulary.
  3. Navigation model uncertainty. If it is unclear whether users browse, search, filter, compare, or complete a sequence.
  4. Content/model uncertainty. If you need to know content types, metadata, scale, lifecycle, or ownership.
  5. Search scope uncertainty. If adding or redesigning search and the indexed content is not defined.
  6. Governance uncertainty. If the recommendation requires ongoing taxonomy, metadata, redirects, or editorial maintenance.
  7. Platform/accessibility constraints. If the implementation differs substantially across web, native, kiosk, voice, or assistive technology contexts.
  8. Legacy constraints. If migration, existing URLs, analytics, SEO, or design-system compatibility may constrain the structure.
Do not ask routine questions such as whether labels should be clear, whether the design should be accessible, or whether users should understand navigation. Apply the default.
Use the question-tool-ready prompts in references/decision-prompts.md.
仅当答案会改变信息架构时才询问。在问题中给出默认建议。
在以下情况使用
question
工具或等效工具：
  1. 目标模糊。如果用户未提供产品、功能、用户任务或内容领域。
  2. 受众模糊。如果标签或分类体系依赖于专业术语还是通用词汇。
  3. 导航模型不确定。如果不清楚用户是浏览、搜索、筛选、比较还是完成序列任务。
  4. 内容/模型不确定。如果需要了解内容类型、元数据、规模、生命周期或所有权。
  5. 搜索范围不确定。如果添加或重新设计搜索，但未定义索引内容。
  6. 管理规则不确定。如果建议需要持续的分类体系、元数据、重定向或编辑维护。
  7. 平台/无障碍约束。如果在网页、原生应用、自助终端、语音或辅助技术场景中的实现差异较大。
  8. 遗留系统约束。如果迁移、现有URL、数据分析、SEO或设计系统兼容性可能限制结构。
不要询问常规问题，如标签是否应清晰、设计是否应无障碍或用户是否应理解导航。直接应用默认方案。
使用 references/decision-prompts.md 中适用于提问工具的提示语。

Workflow

工作流程

A. Critique existing IA or UI

A. 评审现有信息架构或UI

Inspect in this order:
  1. User goal and entry point. Identify the user's job, prior context, and likely entry route: homepage, deep link, search result, notification, ad, bookmark, or internal workflow.
  2. Content inventory and content types. List the main objects, actions, metadata, states, and relationships visible or implied.
  3. Organization scheme. Determine the dominant grouping principle. Flag mixed, overlapping, or org-chart-driven groupings.
  4. Hierarchy and structure. Check whether the depth, breadth, sequence, and parent-child relationships match user expectations.
  5. Labels and language. Evaluate clarity, consistency, specificity, distinctiveness, and vocabulary fit.
  6. Navigation and wayfinding. Check global, local, contextual, supplemental, and process navigation. Verify that the screen answers "where am I, what is here, where can I go?"
  7. Search and discovery. Inspect query entry, scope, suggestions, results, filters, sorting, ranking cues, snippets, empty/no-results states, and recovery paths.
  8. Metadata and invisible IA. Identify missing fields, synonyms, aliases, content ownership, redirects, result tuning, and analytics needs.
  9. Accessibility and keyboard behavior. Check semantic landmarks, headings, links/buttons, focus order, menu behavior, ARIA names, and dynamic announcements.
  10. Frontend feasibility. Check URL/state persistence, component reuse, responsive behavior, performance, localization, and design-system fit.
  11. Prioritize fixes. Separate blocking findability problems from polish. Recommend the smallest structural change that solves the user's task.
Output critiques as: finding → evidence → impact → recommendation → implementation note.
按以下顺序检查：
  1. 用户目标与入口点。确定用户的工作、先前场景和可能的入口路径：首页、深层链接、搜索结果、通知、广告、书签或内部工作流。
  2. 内容清单与内容类型。列出可见或隐含的主要对象、操作、元数据、状态和关系。
  3. 组织方案。确定主导分组原则。标记混合、重叠或基于组织架构的分组。
  4. 层级与结构。检查深度、广度、顺序和父子关系是否符合用户预期。
  5. 标签与语言。评估清晰度、一致性、特异性、独特性和词汇适配性。
  6. 导航与寻路。检查全局、本地、上下文、补充和流程导航。验证页面是否回答“我在哪里，这里有什么，我可以去哪里？”
  7. 搜索与发现。检查查询输入、范围、建议、结果、筛选器、排序、排名提示、摘要、无结果状态和恢复路径。
  8. 元数据与隐性信息架构。识别缺失字段、同义词、别名、内容所有权、重定向、结果调优和数据分析需求。
  9. 无障碍与键盘行为。检查语义地标、标题、链接/按钮、焦点顺序、菜单行为、ARIA名称和动态通知。
  10. 前端可行性。检查URL/状态持久化、组件复用、响应式行为、性能、本地化和设计系统适配性。
  11. 优先修复项。区分阻碍可查找性的问题与优化项。推荐解决用户任务的最小结构变更。
输出评审结果格式：发现 → 证据 → 影响 → 建议 → 实施说明。

B. Create or redesign an IA

B. 创建或重新设计信息架构

Proceed in this order:
  1. Clarify the product problem. Identify primary users, top tasks, content scope, business goals, platform, constraints, and success signals.
  2. Choose the simplest useful structure. Prefer a clear hierarchy for simple/stable domains; add facets/search/contextual links only where content scale or user behavior requires it.
  3. Define content objects. Name each object type, required fields, optional metadata, states, owners, and relationships.
  4. Pick organization schemes. Choose task/topic/audience/etc. per view. Avoid mixing schemes unless you create distinct entry sections.
  5. Draft hierarchy and navigation. Produce primary nav, local nav, breadcrumbs/process steps, contextual links, and supplemental aids.
  6. Draft labels. Use user vocabulary, consistent grammatical patterns, and distinct labels. Include aliases for common alternate terms.
  7. Design search/discovery. Define searchable content, zones, query support, filters/facets, result snippets, sort order, and empty states.
  8. Design bottom-up structure. Add page templates, headings, related links, metadata, "next best" links, and content chunks for deep-entry users.
  9. Validate against scenarios. Walk through at least three tasks: known-item lookup, exploratory browsing, and recovery from a wrong turn/no result.
  10. Specify frontend behavior. Define semantic markup, URL state, keyboard behavior, focus management, loading/error/empty states, and analytics events.
  11. Document governance. Note who maintains labels, taxonomy, metadata, redirects, and search tuning.
Output design recommendations as a structured IA proposal, not a decorative layout.
按以下顺序进行：
  1. 明确产品问题。确定主要用户、核心任务、内容范围、业务目标、平台、约束和成功指标。
  2. 选择最简单的有用结构。对于简单/稳定领域，优先选择清晰的层级结构；仅当内容规模或用户行为需要时，添加分面/搜索/上下文链接。
  3. 定义内容对象。命名每个对象类型、必填字段、可选元数据、状态、所有者和关系。
  4. 选择组织方案。为每个视图选择任务/主题/受众等方案。除非创建不同的入口区域，否则避免混合方案。
  5. 草拟层级与导航。生成主导航、本地导航、面包屑/流程步骤、上下文链接和辅助工具。
  6. 草拟标签。使用用户词汇、一致的语法模式和独特的标签。为常见替代术语添加别名。
  7. 设计搜索/发现。定义可搜索内容、区域、查询支持、筛选器/分面、结果摘要、排序顺序和空状态。
  8. 设计自下而上的结构。为深层入口用户添加页面模板、标题、相关链接、元数据、“下一步最佳”链接和内容块。
  9. 按场景验证。至少演练三个任务：已知项目查找、探索性浏览、错误路径/无结果恢复。
  10. 指定前端行为。定义语义标记、URL状态、键盘行为、焦点管理、加载/错误/空状态和分析事件。
  11. 记录管理规则。注明谁负责维护标签、分类体系、元数据、重定向和搜索调优。
输出结构化的信息架构提案，而非装饰性布局。

Decision framework

决策框架

Choose hierarchy when

选择层级结构的场景

  • Content has clear parent-child relationships.
  • Users expect a table-of-contents, policy, documentation, file, or catalog structure.
  • Items mostly belong in one place.
  • The path itself helps users understand the domain.
  • 内容有明确的父子关系。
  • 用户预期目录、政策、文档、文件或目录结构。
  • 项目大多属于一个位置。
  • 路径本身帮助用户理解领域。

Choose facets when

选择分面的场景

  • Items can be described along multiple independent dimensions.
  • Users compare, narrow, and combine attributes.
  • Content volume is high enough that flat lists are unhelpful.
  • Metadata quality can be maintained.
  • 项目可沿多个独立维度描述。
  • 用户进行比较、缩小范围和组合属性。
  • 内容量足够大，扁平化列表无帮助。
  • 元数据质量可维护。

Choose search when

选择搜索的场景

  • Users often know the name, ID, keyword, location, or attribute of the target.
  • Content changes too quickly for manual navigation alone.
  • The content set is too large or heterogeneous for browsing alone.
  • Search logs can be used to improve labels, synonyms, and result tuning.
  • 用户通常知道目标的名称、ID、关键词、位置或属性。
  • 内容变化太快，仅靠手动导航不足。
  • 内容集太大或异构，仅靠浏览不足。
  • 搜索日志可用于改进标签、同义词和结果调优。

Choose contextual navigation when

选择上下文导航的场景

  • Users enter deep pages from search or external links.
  • Related content is more useful than a full hierarchy.
  • A workflow needs "next step," "related," "also applies to," or "learn more" links.
  • Content models can reliably express relationships.
  • 用户从搜索或外部链接进入深层页面。
  • 相关内容比完整层级更有用。
  • 工作流需要“下一步”“相关”“也适用于”或“了解更多”链接。
  • 内容模型可可靠表达关系。

Choose supplemental navigation when

选择补充导航的场景

  • Users need overview, alternative access, or recovery tools.
  • The system has long-tail content or multiple audiences.
  • A-Z indexes, sitemaps, guides, glossaries, onboarding tours, or wizards reduce cognitive load.
  • 用户需要概览、替代访问或恢复工具。
  • 系统有长尾内容或多个受众。
  • A-Z索引、站点地图、指南、术语表、引导 tour 或向导可降低认知负荷。

Practical rules

实用规则

  • Each navigation region needs a clear purpose. Do not duplicate the same links in multiple regions unless repetition helps orientation or task completion.
  • Do not expose all taxonomy levels at once. Reveal depth progressively.
  • Keep sibling labels parallel in grammar and granularity.
  • Use category labels that describe the group, not marketing priorities.
  • Avoid "Resources," "Solutions," "Learn," and "More" unless the contained items are genuinely coherent and users can predict what belongs there.
  • Place high-frequency, high-value tasks in visible navigation; do not hide them behind search, footers, or catch-all menus.
  • Use breadcrumbs for location in hierarchy, not as a record of the user's click history.
  • Use tabs for peer views of the same object, not for unrelated destinations.
  • Use filters to narrow a result set, not as primary navigation across unrelated sections.
  • Provide result counts and active filter summaries when filtering.
  • Always provide a recovery path for empty states and no-results states.
  • Use analytics as evidence, not as the only source of truth. Pair search logs and click data with user research or task analysis.
  • Document deprecated labels and redirects during migrations.
  • 每个导航区域需要明确的用途。除非重复有助于定位或任务完成，否则不要在多个区域重复相同的链接。
  • 不要一次性暴露所有分类层级。逐步展示深度。
  • 同级标签在语法和粒度上保持一致。
  • 使用描述群组的类别标签，而非营销优先级。
  • 避免使用“资源”“解决方案”“学习”“更多”，除非包含的项目真正连贯且用户可预测内容。
  • 将高频、高价值任务放在可见导航中；不要隐藏在搜索、页脚或全能菜单后。
  • 面包屑用于显示层级位置，而非用户的点击历史记录。
  • 标签页用于同一对象的同级视图，而非无关目的地。
  • 筛选器用于缩小结果集，而非跨无关区域的主导航。
  • 筛选时提供结果计数和活动筛选器摘要。
  • 始终为空状态和无结果状态提供恢复路径。
  • 将数据分析作为证据，而非唯一的真相来源。将搜索日志和点击数据与用户研究或任务分析结合。
  • 迁移期间记录废弃标签和重定向。

Accessibility and inclusion requirements

无障碍与包容性要求

  • Use semantic landmarks: 
    header
    , 
    nav
    , 
    main
    , 
    aside
    , 
    footer
    , and descriptive 
    aria-label
    values when multiple nav regions exist.
  • Use a logical heading hierarchy that reflects the content structure, not just visual size.
  • Use real links for navigation and real buttons for actions.
  • Provide visible focus states and predictable keyboard order.
  • Menus, comboboxes, tabs, accordions, and disclosure navigation must follow expected keyboard patterns.
  • Do not rely on icon-only navigation for primary tasks unless accessible text labels are present and the icon meaning is validated.
  • Make search inputs programmatically labeled. Use 
    type="search"
    when appropriate.
  • Announce dynamic result updates, filter changes, loading, and errors with appropriate live regions when the page does not reload.
  • Ensure labels and instructions do not rely only on color, position, or shape.
  • Maintain readable target sizes and spacing across touch devices.
  • Support localization: avoid labels that break when translated, and expect category order, alphabetical indexes, and sort logic to vary by locale.
  • 使用语义地标：
    header
    、
    nav
    、
    main
    、
    aside
    、
    footer
    ，当存在多个导航区域时使用描述性
    aria-label
    值。
  • 使用反映内容结构的逻辑标题层级，而非仅视觉大小。
  • 使用真实链接进行导航，真实按钮执行操作。
  • 提供可见焦点状态和可预测的键盘顺序。
  • 菜单、组合框、标签页、手风琴和展开式导航必须遵循预期的键盘模式。
  • 不要依赖纯图标导航完成主要任务，除非存在无障碍文本标签且图标含义已验证。
  • 为搜索输入提供程序化标签。适当使用
    type="search"
    。
  • 当页面不刷新时，使用适当的实时区域通知动态结果更新、筛选变化、加载和错误。
  • 确保标签和说明不仅依赖颜色、位置或形状。
  • 在触控设备上保持可读的目标尺寸和间距。
  • 支持本地化：避免翻译后失效的标签，考虑类别顺序、字母索引和排序逻辑因地区而异。

Frontend implementation guidance

前端实施指南

Semantic structure

语义结构

  • Primary navigation: 
    <nav aria-label="Primary">
    containing lists of links.
  • Breadcrumbs: 
    <nav aria-label="Breadcrumb"><ol>...
    with the current page identified by 
    aria-current="page"
    .
  • Search: 
    <form role="search">
    or a labeled search form, with a visible label or accessible name.
  • Results: use headings, list semantics, result titles as links, meaningful snippets, metadata, and source/type indicators.
  • Filters/facets: use fieldsets/legends for groups, checkboxes for multi-select facets, radios for exclusive options, and buttons/links for applying/removing filters depending on behavior.
  • Pagination: use navigation landmarks and 
    aria-current
    for current page.
  • 主导航：
    <nav aria-label="Primary">
    包含链接列表。
  • 面包屑：
    <nav aria-label="Breadcrumb"><ol>...
    ，当前页面用
    aria-current="page"
    标识。
  • 搜索：
    <form role="search">
    或带标签的搜索表单，包含可见标签或无障碍名称。
  • 结果：使用标题、列表语义、结果标题作为链接、有意义的摘要、元数据和来源/类型指示器。
  • 筛选器/分面：用fieldset/legend分组，多选分面用复选框，互斥选项用单选按钮，根据行为用按钮/链接应用/移除筛选器。
  • 分页：使用导航地标，当前页用
    aria-current
    标识。

Responsive behavior

响应式行为

  • Preserve conceptual navigation across breakpoints.
  • Do not hide essential primary tasks in a mobile drawer without an equivalent visible path.
  • For complex side navigation, collapse sections while preserving current location and search/filter access.
  • Keep filter state visible or easily resumable on mobile.
  • 在断点间保留概念导航。
  • 不要将核心主任务隐藏在移动端抽屉中而不提供等效的可见路径。
  • 对于复杂侧边导航，折叠部分同时保留当前位置和搜索/筛选访问权限。
  • 在移动端保持筛选状态可见或易于恢复。

State and URLs

状态与URL

  • Encode search query, selected facets, sort, pagination, and active category in the URL for shareable web states unless privacy or security prevents it.
  • Use canonical URLs and redirects during IA migrations.
  • Keep route names and slugs stable, readable, and aligned with labels where possible.
  • 除非隐私或安全限制，否则将搜索查询、选中的分面、排序、分页和活动类别编码到URL中，以便网页状态可共享。
  • 信息架构迁移期间使用规范URL和重定向。
  • 保持路由名称和slug稳定、可读，并尽可能与标签对齐。

Componentization

组件化

Create reusable components for:
  • Primary navigation
  • Section/local navigation
  • Breadcrumbs
  • Tabs for object subviews
  • Search form
  • Suggestions/autocomplete
  • Result list/card
  • Facet/filter group
  • Active filter chips
  • Empty/no-results states
  • Related-content modules
  • Content templates with metadata slots
创建可复用组件：
  • 主导航
  • 区域/本地导航
  • 面包屑
  • 对象子视图标签页
  • 搜索表单
  • 建议/自动完成
  • 结果列表/卡片
  • 分面/筛选器组
  • 活动筛选器芯片
  • 空/无结果状态
  • 相关内容模块
  • 带元数据插槽的内容模板

Performance and maintainability

性能与可维护性

  • Do not render huge navigation trees or facet lists unbounded; virtualize, paginate, group, or search within long lists.
  • Lazy-load secondary navigation only if the current location remains clear.
  • Cache taxonomy and vocabulary data carefully, with invalidation for editorial updates.
  • Instrument search queries, no-results queries, filter usage, top exits, and navigation dead ends.
  • 不要无限制渲染庞大的导航树或分面列表；对长列表进行虚拟化、分页、分组或内部搜索。
  • 仅当当前位置保持清晰时，才懒加载二级导航。
  • 谨慎缓存分类体系和词汇数据，编辑更新时失效缓存。
  • 监控搜索查询、无结果查询、筛选使用情况、顶级退出点和导航死胡同。

Quality checklist

质量检查表

Before finalizing an IA recommendation, verify:
  • The structure supports at least one known-item task, one exploratory task, and one recovery task.
  • Primary navigation represents user priorities, not only internal departments.
  • Labels are distinct, predictable, and consistent.
  • Content can be found by more than one path when user mental models differ.
  • Deep-entry users can orient themselves without visiting the homepage.
  • Search has defined scope, indexed fields, result presentation, and no-results recovery.
  • Facets use reliable metadata and do not produce many meaningless empty states.
  • Accessibility semantics and keyboard behavior are specified.
  • Frontend state, URLs, responsive behavior, and design-system reuse are addressed.
  • Maintenance responsibilities are explicit.
Use the full checklists in references/checklists.md.
在最终确定信息架构建议前，验证：
  • 结构至少支持一个已知项目任务、一个探索性任务和一个恢复任务。
  • 主导航代表用户优先级，而非仅内部部门。
  • 标签独特、可预测且一致。
  • 当用户心智模型不同时，内容可通过多种路径找到。
  • 深层入口用户无需访问首页即可定位自己。
  • 搜索有明确的范围、索引字段、结果展示和无结果恢复机制。
  • 分面使用可靠的元数据，不会产生大量无意义的空状态。
  • 指定了无障碍语义和键盘行为。
  • 解决了前端状态、URL、响应式行为和设计系统复用问题。
  • 维护职责明确。
使用 references/checklists.md 中的完整检查表。

Common mistakes to avoid

需避免的常见错误

  • Designing a sitemap before understanding user tasks and content types.
  • Treating the homepage or main menu as the whole IA.
  • Copying the organization chart into navigation.
  • Using brand slogans or internal project names as labels.
  • Adding search as a substitute for fixing taxonomy and labels.
  • Exposing advanced search controls before users need them.
  • Creating too many top-level items or too many hierarchy levels.
  • Mixing topic, audience, task, format, and lifecycle labels in the same undifferentiated menu.
  • Relying on hover-only menus.
  • Failing to design no-results and empty states.
  • Forgetting redirects, aliases, and deprecated terms during migrations.
  • Ignoring bottom-up IA inside content templates.
See references/anti-patterns.md for the full anti-pattern list.
  • Creating a taxonomy without governance.
  • 在了解用户任务和内容类型之前设计站点地图。
  • 将首页或主菜单视为整个信息架构。
  • 将组织架构复制到导航中。
  • 使用品牌口号或内部项目名称作为标签。
  • 添加搜索以替代修复分类体系和标签。
  • 在用户需要之前暴露高级搜索控件。
  • 创建过多顶级项或过多层级。
  • 在同一无区分菜单中混合主题、受众、任务、格式和生命周期标签。
  • 依赖仅悬停菜单。
  • 未设计无结果和空状态。
  • 迁移期间忘记重定向、别名和废弃术语。
  • 忽略内容模板内的自下而上信息架构。
查看 references/anti-patterns.md 获取完整的反模式列表。
  • 创建无管理规则的分类体系。

How to explain recommendations to the user

如何向用户解释建议

Explain IA recommendations in task-centered language:
  • Start with the user problem: "Users need to compare plans by price and feature without knowing internal product families."
  • Name the structural choice: "Use a task-first primary nav and faceted comparison on the listing page."
  • State why it helps: "This supports both browsing and narrowing without forcing one category path."
  • Mention tradeoffs: "This requires reliable metadata for plan type, audience, and feature set."
  • Give the implementation implication: "Persist selected filters in the URL and expose them as accessible checkbox groups."
  • Identify validation: "Test with known-item lookup, exploratory browsing, and no-results recovery."
Avoid saying "this is best practice" without tying it to the user's task, content, and constraints.
以任务为中心的语言解释信息架构建议：
  • 从用户问题开始：“用户需要在不了解内部产品系列的情况下，按价格和功能比较套餐。”
  • 说明结构选择：“使用任务优先的主导航和列表页的分面比较功能。”
  • 说明帮助：“这支持浏览和缩小范围，无需强制单一类别路径。”
  • 提及权衡：“这需要套餐类型、受众和功能集的可靠元数据。”
  • 给出实施影响：“在URL中保留选中的筛选器，并将其作为无障碍复选框组展示。”
  • 指出验证方式：“通过已知项目查找、探索性浏览和无结果恢复进行测试。”
避免在未关联用户任务、内容和约束的情况下说“这是最佳实践”。