A7.15.1Functional level研究设计
功能层描述系统能做什么，与用户目标直接对应
别名: 功能层模型 · functional model · black-box model · 能力层
概念解释
心智模型可以停留在不同的分辨率上。功能层（functional level）是最浅的一层，只回答"这个系统能做什么"，把系统当作一个黑箱，只关心它对外呈现的能力与用户目标之间的对应关系——比如"这个软件能把文字转成语音"——不涉及内部由哪些模块构成，也不涉及底层如何实现。
机制
功能层之所以能单独成立、并且经常是唯一被需要的一层，是因为多数用户的目标本身就是任务导向的："我要达成 X"。只要模型能准确预测"做操作 A 会不会达成 X"，任务就能完成，不需要知道 A 背后经过了几个模块的哪几步处理。功能层模型的信息密度最低、抽象程度最高，对应的认知负荷也最低——这正是为什么它能被最大范围的用户群体（从新手到专家）共同持有，而更深的层级往往只有部分用户具备。
怎么研究
- 范式：能力清单核对——请用户列出他们认为系统能做的所有事情，与产品实际功能清单比对，缺漏项和臆测出的多余项都反映功能层模型的边界。
- 方法论注意点：功能层模型的测量容易被"用户此刻恰好想起来"这种偶然性干扰，静态问卷统计出的能力清单会低估用户实际知道的能力，需要结合任务情境下的自然探索行为交叉验证，而不只是让用户凭空回忆。
边界
- 功能层模型足够支撑任务的前提，是任务路径单一或由系统自动引导——一旦任务需要用户自己组合多个功能来完成一个更复杂的目标，仅有功能层模型不足以规划路径，这时更深一层的组织关系信息变得必要。
- 对高度可定制、允许深度配置的系统，功能层模型可能严重低估用户的真实需求空间：用户满足于"知道有这个功能"，却判断不出这个功能能不能被组合出自己真正想要的效果。
怎么落地
- 功能的命名与入口应该直接对应用户的目标描述（"给文档加密"而不是"启用加密模块"），让功能层模型可以直接从界面文案里建立，不需要用户先理解内部术语再倒推出对应的目标。
- 验证办法：新用户首次浏览产品后，让其用自己的话复述"这个东西能帮我做什么"，与产品实际能力清单比对，覆盖率低的部分说明入口命名或呈现方式没有对齐用户的目标语言。