A7.15.2Structural level研究设计
结构层描述功能之间如何组织与关联，是完成复杂任务的路径依据
别名: 结构层模型 · structural model · task path · 功能拓扑
概念解释
结构层（structural level）比功能层深一层：它回答的不是"系统能做什么"，而是"这些能做的事情之间是怎么组织、关联、依赖的"——比如"要导出报表，得先建立数据源，再配置字段，最后才能导出"这种功能之间的先后与依赖关系。用户完成需要组合多个功能的复杂任务时，实际依赖的正是这一层信息。
机制
结构层之所以构成独立的一层，而不是功能层自然延伸出来的东西，是因为知道系统能做 A、能做 B，并不自动意味着知道 A 和 B 之间有没有关系、谁依赖谁。这是关于功能间拓扑关系的知识，不能从单个功能的描述里推导出来，只能通过看到多个功能协同工作的过程、或者被显式告知才能建立。当任务本身要求规划路径（先做什么、再做什么）而不只是识别单点能力时，结构层模型才会被调用，此时即使功能层模型完全准确也不够用，因为它不包含顺序和依赖信息。
怎么研究
- 范式：路径重构任务——让用户完成一次复杂任务后，画出或口述自己认为的功能依赖关系，与产品实际的功能依赖结构比对，考察结构层模型的完整度与准确度。
- 方法论注意点：用户完成了任务不代表建立了正确的结构层模型——很多任务可以靠试错或跟随引导完成，只有让用户脱离界面独立复述结构，才能区分"记住了操作序列"和"理解了功能间关系"这两件事。
边界
- 结构层模型的必要性只在任务确实需要跨功能规划时成立——对功能单一、任务路径由系统强制线性引导的产品（比如向导式流程），用户不需要自己持有结构层模型，因为规划已经被系统代劳了。
- 结构层模型一旦形成，会比功能层模型更抗拒变化：产品重新组织了功能间的依赖关系（比如把原本必须先做的步骤变成可选），用户即便看到了新提示，仍可能按旧的依赖顺序操作，因为旧结构已经内化为路径习惯。
怎么落地
- 对需要多步骤组合完成的任务，应在界面里显式呈现步骤间的依赖关系（进度指示、前置条件提示），而不是只呈现每一步各自能做什么，让结构层信息可以从界面直接读出，不必靠用户试错拼凑。
- 验证办法：观察用户在没有帮助文档的情况下首次尝试多步骤任务，记录其因为搞错依赖顺序（比如试图跳过必要前置步骤）而受阻的次数与具体环节，定位结构层信息缺失的位置。