提出方：Mukiik
最后更新：2026-11-01
一、适用范围
本规范适用于涉及界面布局、信息展示、操作反馈、页面跳转及弹窗流程的策划案。
此类文档必须同时提供界面原型图、显示信息的数据来源、用户操作后的交互结果，使程序、UI及测试人员能够据此完成制作与验收。
命名、提出方标记及数据字段定义遵循策划文档规范，存放、导航与附件管理遵循文档存储与管理规范。界面类独立文档采用本规范的结构；作为功能策划案的一部分时，将以下要求纳入对应章节，不重复维护已有数据定义。
二、文档基本结构
策划案应包含以下内容：
- 功能目的与界面入口。
- 界面原型图。
- 界面元素与显示规则。
- 显示信息的数据来源。
- 操作行为与交互流程。
- 界面状态与异常处理。
- 验收要点及待确认事项。
三、界面原型图要求
必须随文档附上原型图，不得仅通过文字描述界面。
原型图应明确：
- 界面主要区域、信息层级及控件位置。
- 标题、文本、图片、列表、按钮、页签等元素。
- 页面入口、返回入口及关闭方式。
- 与主流程相关的弹窗、展开区域及切换后的界面。
- 空列表、未解锁、不可操作等影响布局或操作的关键状态。
原型图中的元素须标注编号，并与文档中的说明逐一对应。例如：UI-01 玩家昵称、UI-02 领取按钮、POP-01 奖励弹窗。
原型图不要求达到最终美术品质，但必须能准确表达布局和操作关系。引用外部原型时，应提供可访问的链接及对应版本；核心界面须在文档中附图，便于直接查阅。图片及可编辑源文件放在所属主题的 assets/ 中，并通过相对链接引用。
四、界面元素与显示规则
每个界面元素均应说明“显示什么、何时显示、如何显示”。以下表格仅说明填写方式，不代表已确定的业务设计。
| 元素编号 | 元素名称 | 显示内容 | 显示条件 | 表现规则 |
|---|---|---|---|---|
| UI-01 | 玩家昵称 | 当前玩家昵称 | 始终显示 | 超过规定长度时省略，明确最大长度 |
| UI-02 | 领取按钮 | “领取”或“已领取” | 满足对应任务状态 | 可领取时高亮，已领取时置灰 |
| UI-03 | 奖励列表 | 奖励图标与数量 | 存在奖励配置 | 明确排序、换行及滚动规则 |
涉及数值或文本时，还应明确单位、精度、取整方式、时间格式及超长处理。涉及列表时，应明确排序规则、默认选中项和最大显示数量。
不得使用“正常显示”“按常规处理”等无法直接实现和验收的描述。
五、显示信息的数据来源
界面上所有动态信息，必须标明来自哪个配置表、接口、运行时数据或计算规则。
| 元素编号 | 显示信息 | 来源类型 | 表／接口与字段 | 关联或计算规则 | 刷新时机 | 缺失处理 |
|---|---|---|---|---|---|---|
| UI-01 | 玩家昵称 | 接口 | 填写接口名及昵称字段路径 | 当前登录玩家 | 打开界面时 | 显示约定占位内容 |
| UI-03 | 奖励图标 | 配置表 | 填写奖励表、道具表及字段名 | 通过道具ID关联图标资源 | 奖励数据变化时 | 显示默认图标并记录问题 |
填写要求：
- 配置表来源：写明表名、字段名、查询条件及跨表关联关系，并提供所属仓库、项目内路径及工作表名称（如适用）。
- 接口来源：写明接口名称或路径、所需请求参数及响应字段路径。
- 计算结果：写明输入字段、计算公式、取整规则及边界处理。
- 固定内容：注明文案、资源路径或本地化键值。
- 刷新规则：说明在进入界面、切换页签、操作成功或其他事件发生时更新。
尚未确定的表或接口必须标记“待确认”，同时写明所需数据、责任人及确认节点，不得将临时名称当作已确定方案。尚未落地的文件路径标注“计划路径，文件尚未创建”。
六、操作行为与交互流程
每个可操作元素都必须说明：点击哪里、在什么条件下生效、执行什么、最终出现什么结果。
| 操作对象 | 触发方式 | 前置条件 | 执行逻辑 | 成功结果 | 失败或不可操作反馈 |
|---|---|---|---|---|---|
| UI-02 领取按钮 | 单击 | 任务已完成且未领取 | 发起领取请求，等待期间禁止重复提交 | 刷新奖励与任务状态，打开POP-01 | 显示失败原因，恢复可操作状态 |
交互说明须覆盖：
- 点击反馈：选中、高亮、置灰、加载状态等。
- 数据变化：是否提交请求、修改状态、消耗或获得资源。
- 跳转结果：目标页面、携带参数及返回后的落点。
- 弹窗结果：弹窗编号、展示内容、按钮功能及关闭方式。
- 操作结束后的界面：刷新哪些内容，是否保留页签、筛选条件和滚动位置。
- 重复与异常操作：连续点击、请求超时、操作中关闭界面时如何处理。
复杂流程应补充流程图，将条件分支和各分支的最终结果表达完整。
七、弹窗说明要求
每个弹窗应单独提供原型和说明，至少包含：
- 触发条件及弹窗用途。
- 标题、正文、动态信息及其数据来源。
- 各按钮的文案、操作逻辑与执行结果。
- 是否允许点击遮罩、返回键或关闭按钮退出。
- 关闭后返回的位置，以及是否刷新原界面。
- 与其他弹窗同时触发时的显示顺序或互斥规则。
涉及确认操作时，应明确何时真正提交操作，以及取消或关闭是否产生任何数据变化。
八、状态覆盖与验收
设计者应检查并说明适用的界面状态：正常、加载中、无数据、加载失败、未解锁、条件不足及操作完成。无需支持的状态应注明原因。
验收标准按“前置条件 → 操作 → 预期结果”编写，明确显示内容、状态变化及操作反馈，使结果能够直接判断通过或失败。
提交前须确认：
- 原型图、元素编号与文字说明一致。
- 所有动态信息均能追溯到具体数据来源或明确的待确认项。
- 所有可点击区域均有完整的操作结果说明。
- 所有弹窗均有入口、按钮逻辑及退出规则。
- 成功、失败及边界情况均有明确反馈。
- 测试人员能够依据文档判断显示内容和操作结果是否正确。
文档完成标准：实施人员无需自行猜测“数据从哪里来”和“点击之后会怎样”。 影响实现或验收的待确认项关闭后，方可作为对应部分的定稿依据。