如何进行以任务为本的信息架构审计

在批准改版、迁移或重画网站地图前，先选出对业务与用户真正重要的任务，追踪人们从现实入口走向结果的每一条合理路线。菜单拥挤、高退出率或“资料很难找”的投诉只能指出值得调查之处；它们不能自行说明问题来自网站结构。缺失内容、含糊标签、错误分组、薄弱的情境链接、欠佳搜索结果和无法操作的控件，表面上都像“导航问题”，所需修补却完全不同。以任务为分析单位，团队才有办法把观察、诊断、决定和复测连成一条可审查的证据链。

这次审计究竟要支持哪一项决定？

审计首先要支持一项范围明确、可以采取行动的决定，例如修补某个栏目、调整标签、准备内容迁移，或判断现有证据是否足以支持更大规模的改版。信息架构涵盖内容组织、标签和导航，并应帮助人们找到信息、判断自己身处何处、看见下一步选择及完成任务。因此，本次工作应检查选定任务所依赖的路线系统，而不是笼统评判整个网站是否“整齐”或“现代”。

把适用范围写进审计简报：包括哪些受众、目标、起始情境、页面类型、设备、语言版本、权限和旅程状态，也要写明不包括什么。任务式信息架构审计不是内容清单、技术搜索引擎优化审计、无障碍符合性评估或视觉改版；这些工作可以分享发现，却回答不同问题。证据记录还应分开已知事实、行为观察、专家检查结果和未经测试的假设，避免会议上的信心被误写成用户证据。

• 决定：审计完成后，负责人必须能够批准、拒绝或排序什么行动？
• 范围：哪些受众、路线、页面、设备、语言、权限与状态会影响结论？
• 证据标准：什么必须来自用户观察，什么可暂列为专家判断或待验证假设？
• 边界：哪些内容、技术、无障碍或设计问题应交由另一项专业评估处理？

怎样从证据建立具代表性的任务集？

具代表性的任务集应从用户要取得的结果出发，并为每项任务保留证据出处。建立任务集时，应先弄清用户想完成什么、目前怎样处理、哪里受阻，以及他们真正需要的结果。任务句要采用用户认得的语言，却不可泄露网站现有目的地标签或暗示“正确”菜单。例如应描述所需结果和触发情境，而不是叫参与者点击某个栏目；否则测试只会证明他们能够照指示操作。

分析数据、站内搜索记录、客服需求、既有研究、访谈、观察及直接接触用户的员工都可提供线索，但非用户意见仍须标为假设。退出、重复查询或大量支援个案可以帮助定位问题，却不能单独证明用户意图、问题成因或正确修补方法。Digital.gov记录的一个信息架构案例从既有研究拟定现实任务，并在测试前检查任务覆盖面；该做法值得借鉴，但案例中的数量不可搬成通用门槛。

• 记录任务对应的受众、触发点、现实起始情境和明确完成条件。
• 同时纳入常见、后果重大、长期困难及服务不足群体的重要任务。
• 注明每项任务来自研究、行为资料、营运资料、员工观察还是待验证假设。
• 检查任务集是否只偏向容易量化、容易完成或最熟悉网站结构的人。

任务至路线工作表应该记录什么？

工作表应把每项有证据支持的任务，一路连接到预期结果、合理路线、检查提示、观察行为、失效诊断、最小改动和复测。先写成功结果与实际目的地，再列出现实入口：搜索引擎带来的落地页、栏目页、已登入区域、客服发来的深层链接或站内搜索。不要默认所有人从主页出发，也不要因为找到一条可行路径，便假定不同设备、权限或语言版本都能走同一路线。

每逢用户必须选择，就记录可见提示、提示产生的预期、实际到达页面，以及选错后能否认出问题并恢复。路线至少应覆盖浏览导航、页面内情境链接和站内搜索。WCAG 2.2成功准则2．4．5要求页面集合内的页面有多于一种寻找方式，但流程结果页或流程步骤可属例外；相关链接、网站地图、搜索和完整导航均是所列方法。这项检查只处理特定准则，不能取代完整无障碍评估。

任务式信息架构审计不问网站地图是否工整，而问人们能否沿现实路线到达所需结果，并留下足以采取行动的证据。

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

完整路线检查要从现实入口走到最终内容或操作，并在途中检查全局与局部导航、栏目枢纽、页面分组、标题、面包屑或其他位置提示、情境链接及搜索结果。Microsoft建议从用户视角、常见任务和心智模型规划导航，并把准确、熟悉、简洁、易扫描和可与相邻选项区分列为标签特质。实际检查时，重点不是标签有多短，而是它会否让相关受众对目的地形成准确预期。

用户还须能辨认自己到了哪一层、下一步能做什么，以及误入后怎样返回有效路线。WCAG 2.2成功准则2．4．6要求所提供的标题和标签描述主题或用途；成功准则3．2．3则要求重复导航机制保持相同的相对次序，除非变化由用户主动触发，而且并不禁止局部或次级导航。若设备、页面模板、语言、登入权限或流程状态会改变可用路线，就应在这些情境重复关键任务。使用站内搜索本身并不表示导航失败，搜索也可能是用户偏好的有效路径。

• 承诺：入口、标签与标题是否准确预告下一页的内容或操作？
• 位置：用户是否知道所在栏目、当前层级和仍可选择的方向？
• 一致：重复导航的名称、相对次序和行为是否可预测？
• 恢复：误入、无结果或权限不足后，是否有清楚而可操作的下一步？
• 完成：目的地是否真正提供任务所需的内容、状态或行动？

不确定的路线应该用哪一种研究方法验证？

验证方法应配合尚未解决的证据问题，而不是因为团队手上刚好有某种工具。专家检查和既有行为资料适合定位可疑位置，但检查者认为某标签含糊，不等于用户已经被观察到失败。若问题是用户预期怎样分组内容或怎样称呼类别，可用卡片分类；开放式分类也能观察参与者怎样为自建类别命名。不过，它不会验证已渲染页面中的导航、控件、情境链接或搜索路线。

若问题集中在层级和标签能否让人找到目的地，可用树状测试隔离这些因素，但它会省略大部分已渲染界面。若问题跨越页面提示、导航控件、搜索、恢复和最终完成，则应在实际或具代表性的已渲染网站进行任务式可用性测试。NIST把可用性测试描述为由具代表性的用户执行具代表性的任务，证据可包括完成情况、错误、用时、质化意见和满意度。即使部分参与者抵达目的地，分歧路线及其解释仍可能暴露含糊分组或标签。

• 专家检查：寻找可能失效的位置，但把结论保留为待验证判断。
• 卡片分类：回答预期分组和类别语言问题，不宣称完整路线已获验证。
• 树状测试：隔离层级与标签的可寻性，不评估完整页面设计。
• 任务式可用性测试：观察已渲染路线、控件、搜索、恢复与完成。
• 指标选择：只记录能支持决定的完成、求助、误入、回退、查询改写、信心与理由。

怎样把发现转成有限修补，或有根据的改版决定？

先准确分类失效，再选择证据支持的最小改动。覆盖失效表示所需内容、操作或状态不存在或不完整；入口失效表示常见起点没有合理路线；标签与分组失效分别涉及错误预期和位置不合心智模型；方向、情境链接、搜索、一致性与互动失效则各有不同责任人和修补方式。这样做可防止每个症状都被写成“重做导航”，也让内容、搜索、设计和平台团队知道自己应处理哪一段证据链。

排序时应公开任务重要性、受影响受众、观察到的失败频率、后果、证据强度和修补依赖，而不是把判断藏进一个看似客观的综合分数。没有单一路线指标或综合分数能独立决定是否改版；结论须连回指定用户、任务、情境和所需决策。可选行动从内容纠正、标签或链接修补、重新分组、搜索调校和栏目重整，到更广泛的结构改版，范围应随证据而扩大。

完成改动后，要重跑受影响的任务和路线，并比较原本失效是否消失、是否转移到另一入口，以及不同设备、语言或权限情境是否仍可完成。只有重要任务在相关情境反复出现有观察支持的结构性失败，而且局部内容、标签、链接、分组或搜索修补无法合理解决时，才形成较可信的全面改版理由。若团队无法处理研究设计或结构取舍，应请资深信息架构师或用户研究员参与；若发现涉及无障碍，应另请合资格专家执行适当评估，因为本审计和所选WCAG检查都不能单独证明全站符合性。

1. 为每项发现指定失效类型，并把证据强度与适用情境写清楚。
2. 用公开的任务重要性、受影响范围、后果、观察频率和依赖关系排序。
3. 指派最小可行改动的负责人、交付范围和需要重新检查的路线。
4. 复测后才决定关闭问题、继续局部修补，或把结构性证据升级为改版个案。