Payoff Action Modeling — 付款行为建模

结果行动建模 在设计或完善任何用户达到有意义结果的UI状态之前使用此技能，用户需要了解发生了什么，存在什么，以及下一步该做什么。这适用于AI产品、CRUD系统、仪表盘、入门流程、导入、上传、报告工具、自动化工具、管理面板、项目管理工具、内容管理系统平台、部署或同步流程、协作审查系统和工作流产品。目标是回答：“现在用户已经获得价值或进展，他们可能会合理地想下一步做什么，以及每个操作应该放在哪里？”

核心输出 产生一个操作模型，包括：

主要结果：用户应该首先了解的结果、资源、状态或完成情况。 结果状态类型：完成、生成、工作空间、审查、交接、恢复或继续。 用户问题：从用户角度出发的现实问题，如“如果我想...怎么办”。 操作范围：结果、选择、项目、继续、导航、恢复或辅助。 意图压力：立即、上下文或延迟。 UI放置：主要CTA、次要操作、每项操作、行菜单、手风琴详细信息、批量工具栏、空/可选状态、状态区域、壳导航或下一个屏幕。 必需与可选：操作是否必须现在可见或可以延迟。 复制：短标签以用户面向结果的方式书写，而不是实现细节。

使用以下表格形状，除非用户请求其他格式：

类型 | 描述 --- | --- 完成 | 用户完成了一个流程、设置、入门步骤、任务、批准或配置。 生成 | 系统产生了一个结果，例如测试用例、内容、分析、推荐或文件。 工作空间 | 用户现在继续在项目、仪表盘、编辑器、板、列表或管理表面中工作。 审查 | 用户验证、批准、拒绝、比较、评论或验证结果。 交接 | 用户导出、共享、发布、传输、下载、同步或发送结果到其他地方。 恢复 | 用户修复、重试、恢复、回滚、解决错误或撤消更改。 继续 | 用户扩展工作流程、创建更多、重复使用不同的输入或启动下一个分支。

原则 结果清晰 用户应该在大约两秒内理解：

发生了什么 什么被创建、完成、导入、部署、同步、批准或更改 最高价值的下一个操作是什么 在执行操作之前在哪里检查详细信息

局部性原则 操作应该出现在它们影响的对象附近。项目操作属于行、卡片、文件、案例、记录、评论、任务或列表项附近。选择操作属于在选择存在后出现的工具栏中。破坏性操作应该保持上下文和可恢复性。改进、帮助、解释和AI操作应该出现在被改进或解释的对象旁边。全结果操作属于结果摘要或主要完成区域附近。

意图压力 根据紧急程度对操作进行分类：

立即：用户可能需要现在执行此操作来捕获价值或完成工作。 上下文：操作在用户检查特定对象、状态、错误或选择时很重要。 延迟：操作是有用的，但不应该与主要结果时刻竞争。

规则：

立即操作主导结果状态。 上下文操作保持在其对象附近。 延迟操作可以位于次要控件、菜单、详细信息、设置或后续屏幕后面。 高级操作不应超载第一次成功时刻。 * 操作密度管理 避免在用户成功或完成后立即让他们感到不知所措。更喜欢一个明确的主要操作而不是多个等效的CTA。保持工具栏紧凑，直到选择、过滤、审查或编辑模式使它们必要。不要在同一视觉层中堆叠继续提示、改进工具、升级提示和导出选项。显示足够的操作以支持动力，但不要太多，以至于结果成为次要的工具。

动力继续 UI应该回答：“用户如何在实现价值后自然继续？”继续操作应该在不替换主要成功状态的情况下扩展动力。创建另一个、生成更多、导入更多、添加团队成员、发布、再次运行、打开工作空间和审查下一个应该是可选分支。不要在成功后使继续成为强制性，除非产品流程真正需要它。保留当前结果，同时让用户分支、重复、改进或交接。范围分离