如何开展以用户任务为核心的信息架构审计

先审计代表性用户任务及其可行路线，再审计菜单，更不要一开始就重画站点地图。面对菜单拥挤、高退出页面和“内容难找”的投诉，团队应先选出一个对业务与用户都重要的结果，追踪用户从外部落地页、栏目页、登录区或站内搜索到达它的真实可能路径。这样才能分清问题究竟是内容缺失、入口缺位、标签含混、分组不合预期、上下文链接不足、搜索结果不佳，还是界面控件妨碍了使用。

信息架构审计首先要支持哪项决策？

审计首先要服务于一项边界明确、能够采取行动的决策，例如修复某个栏目、调整一组标签、为迁移准备结构依据，或判断现有证据能否支持更大范围的改版。把决定写在审计简报开头，并同时说明谁将使用结论、什么时间点需要作出选择、哪些改变目前可实施。若问题只写成“网站是否好用”，团队很容易收集大量意见，却无法判断哪类证据足以改变决定。

信息架构涵盖组织方式、标签与导航，其目的包括帮助人们找到信息、理解当前位置和可选路径，并完成预期任务。任务型审计因此检查的是选定任务所依赖的路线系统，而不是把内容清单、技术SEO检查、无障碍符合性评估或视觉改版混在一起。结论只适用于已声明的受众、设备、语言版本、权限、页面类型与旅程状态，不能泛化成一个抽象的“平均用户”。

• 决策：栏目修复、标签调整、迁移准备或改版论证。
• 范围：受众、任务、入口、设备、语言、权限与状态。
• 证据：分别记录已知事实、行为观察、专家检查和待验证假设。
• 交付：明确决策人、责任人、可实施边界与复测条件。

如何从证据建立有代表性的任务集？

代表性任务集要从用户需要达成的结果出发，而不是从现有菜单名称倒推。GOV.UK的研究指南建议先了解人们想做什么、目前如何完成、遇到什么问题，以及真正需要的结果。任务描述应采用用户能理解的情境与结果，不泄露目的地名称或预设路线；“确认某项服务是否适用于本机构”通常比“进入服务资格页面”更适合测试可发现性，因为后者已经把导航答案告诉了参与者。

分析数据、站内搜索日志、客服记录、既有研究、访谈、观察和一线人员都可以提供线索；没有来自用户的佐证时，内部意见仍应标为假设。高频不应成为唯一筛选标准，还要纳入后果较大、长期困难或服务不足的任务。Digital.gov记录的一项信息架构研究从既有研究形成真实任务场景，并在测试前评审了任务覆盖面；该案例说明了证据追溯的做法，但其中的具体任务数和参与者数不能当作通用门槛。

• 任务：用用户语言写清触发情境和需要达成的结果。
• 对象：记录受众、权限、语言版本及其他关键差异。
• 成功：定义应找到的内容、完成的动作或确认的状态。
• 出处：保存研究、日志、客服需求、观察或假设的来源。

任务—路线工作表应记录哪些内容？

工作表至少要把每项任务的证据出处、成功结果、真实起点、可行路线、沿途提示、观察行为、失败类型、修复建议和复测安排连成一条可追溯记录。起点不要默认设为首页：用户可能从搜索引擎进入内容页，从邮件链接落到活动页，从栏目页开始浏览，也可能直接使用登录后的工作区或站内搜索。每条路线都应通向同一个可验证结果，但允许存在不同且同样有效的完成方式。

WCAG 2.2成功准则2．4．5要求页面集合中的页面有不止一种定位方式，但流程结果页或流程步骤属于例外；相关链接、站点地图、搜索和完整导航是文档列举的技术。审计时应保留这一例外，不把“每页必须拥有若干入口”简化成机械规则。工作表的价值在于让检查、研究、诊断、优先级、责任分配和复测使用同一条证据链，避免建议在汇报阶段脱离原始观察。

1. 写明任务、受众、触发情境、成功结果与证据来源。
2. 列出外部落地、浏览、上下文链接和搜索等可能路线。
3. 逐点记录可见提示、预期目的地、实际去向及错误恢复。
4. 归类观察结果，注明证据强度、最小改动、责任人与复测。

任务型信息架构审计不问站点地图是否整齐，而问人们能否沿真实路线到达需要的结果，并留下可采取行动的证据。

如何检查完整路线，而不是孤立地看菜单？

完整路线检查必须从现实入口一直走到最终内容、操作或确认状态，并在每个决策点记录界面作出的承诺。依次查看外部落地页、全局与局部导航、栏目枢纽、页面分组、标题、面包屑或其他位置提示、上下文链接、站内搜索以及目的地。不要只问某个链接是否存在，还要问用户能否看见它、理解它会去哪里、判断自己到达了哪一层，并在选错后找到返回或替代路线。

Microsoft的指南建议从用户视角、常见任务和心智模型规划导航，并把准确、熟悉、简洁、便于扫读和可与相邻选项区分列为标签特征。WCAG 2.2成功准则2．4．6要求已有的标题和标签描述其主题或用途，从而帮助人们理解组织关系并找到信息。短并不天然等于清楚，审计应把标签与相邻选项、触发情境和实际目的地放在一起判断，检查用户预期是否在下一步得到兑现。

• 入口：现实起点是否提供可见且可信的下一步。
• 定位：用户能否识别当前位置、所处层级与后续选择。
• 恢复：错误选择后是否容易返回、改道或使用搜索。
• 一致性：重要路线在页面类型、设备、语言、权限和状态变化后是否仍可用。

跨页面检查还要区分一致性与完全相同。WCAG 2.2成功准则3．2．3关注重复导航机制相对顺序的一致性，除非变化由用户主动触发；它并不禁止局部导航或二级导航。只有当设备、语言、权限或旅程状态会实质改变可用路线时，才需要在这些情境中重复重要任务。看到用户使用搜索也不要立即判定浏览导航失败，因为搜索可能本来就是更符合其习惯的入口。

不同的不确定路线应选择哪种验证方法？

验证方法应由尚未回答的证据问题决定，而不是由团队最熟悉的工具决定。专家检查和既有行为数据适合定位可能的缺陷，却不能把检查者的担忧写成已经观察到的用户失败。Digital.gov把卡片分类描述为了解参与者如何组织内容的方法；在开放式分类中，还可以观察他们如何命名自己建立的分组。它适合研究分类与用语，但不能验证渲染后网站中的整条路线。

树测试可以隔离层级与标签对目的地可发现性的影响，揭示容易混淆的类别，却省略了渲染界面中的大量线索与控件。涉及真实导航、页面提示、上下文链接、搜索、错误恢复或最终完成时，应采用任务型可用性测试。NIST把可用性测试描述为让具有代表性的用户执行具有代表性的任务，证据可以包括完成情况、错误、用时、定性评论和满意度；具体审计只需选择能够回答当前决策的指标。

• 专家检查：寻找待验证缺陷，结论标为检查发现或假设。
• 卡片分类：回答内容怎样分组、类别采用什么语言。
• 树测试：隔离层级与标签是否支持找到目的地。
• 真实界面任务测试：观察完整路线、搜索、恢复与完成。

记录结果时，不要只保留成功率或平均用时。根据决策需要，可观察是否完成、是否求助、错误去向、返回与回溯、搜索词改写、对目的地的信心，以及参与者为什么作出某个选择。参与者走出的分歧路线及其解释，即使最终有人到达正确目的地，也可能暴露分组或标签中的歧义；但分歧本身不是失败，还要判断它是否属于有效替代路线，以及是否增加了与任务相关的困难。

如何把发现转化为局部修复或有依据的改版？

把发现变成行动，先准确归类失败，再选择证据支持的最小干预。不要把每个退出、错误点击或投诉都写成“导航问题”：所需内容不存在属于覆盖失败，现实入口没有可行路径属于入口失败，名称制造错误预期属于标签失败，内容放在意外位置属于分组失败。相同症状还可能来自定位提示、上下文链接、搜索结果、一致性或渲染控件，因此每项建议都应回指工作表中的具体观察。

• 覆盖：需要的内容、动作或状态缺失或不完整。
• 入口：常见起点没有可信的可行路线。
• 标签：提示无法准确描述目的地或用语陌生。
• 分组：目的地位置不合预期，类别边界含混。
• 定位：用户不知道身处何处、到了哪层或下一步是什么。
• 上下文链接：需要继续时缺少相关入口。
• 搜索：查询返回缺失、不相关、误导或难以判断的结果。
• 一致性：重复导航或功能的名称、顺序或行为无故变化。
• 交互：结构合理，但真实控件或页面设计妨碍使用。

排序时公开任务重要性、受影响受众、观察到的失败频率、后果、证据强度和修复依赖，不把判断藏在一个所谓通用的综合分数中。可选动作依次包括内容纠正、标签或链接修复、重新分组、搜索调优、栏目重构与整体改版，并为每项动作指定责任人和复测任务。只有当重要任务在相关情境中反复出现有观察证据支持的结构性失败，且局部修复难以解决时，审计才形成较充分的整体改版理由。

交付物应以复测决定收尾，而不是默认附上一张新站点地图。若证据指向局部标签、链接、内容、分组、搜索、一致性或交互缺陷，就先修复并重新执行受影响的任务与路线；若任务集、研究设计或结构取舍超出团队能力，应请有经验的信息架构师或用户研究人员参与。发现涉及无障碍问题时，应由合适的专业人员开展相应符合性评估，因为本审计及其中选取的WCAG检查不能证明整站达到无障碍符合性要求。