微信小游戏布局设计评审清单与验证模板
编制日期：2026-10-31。仅适用于本项目的微信小游戏研究。方法依据见研究主文档，产品证据见案例分析。本篇是待用于具体项目的工作模板，勾选状态和测试结果尚未填写。
1. 使用方法与问题优先级
先选定“哪个版本、哪类玩家、哪条任务、什么设备与状态”，再逐条检查。每个未通过项必须关联画面或复现步骤；没有检查条件时填“未验证”，不默认通过。无关项写“不适用＋理由”。
建议用四个阶段评审：任务和信息架构 → 灰度线框 → 视觉与全状态稿 → 微信真机及用户任务。后一个阶段发现前一阶段问题时，回到相应决策修改，避免只用换颜色修复空间结构问题。
| 级别 | 判断依据 | 示例 | 建议处理 |
|---|---|---|---|
| P0 阻断 | 核心任务无法继续，或必要操作不可达 | 关闭／提交被系统遮挡、弹窗无法退出 | 发布前解决并重测相关流程 |
| P1 严重 | 经常导致错误决策、显著误触或中断后无法合理恢复 | 广告中途关闭也显示已领奖、拖动触发付费入口 | 优先修复；验证触发条件与返回路径 |
| P2 一般 | 可以完成任务，但理解、寻找或比较成本明显 | 订单与棋盘来回寻找、长数字截断 | 按任务影响排序，比较候选调整 |
| P3 优化 | 不妨碍任务的视觉一致性或细节问题 | 装饰间距轻微不一致 | 在主要结构稳定后处理 |
优先级取决于实际后果与发生条件，不按控件大小决定。小关闭按钮造成流程阻断可以是 P0；醒目装饰的颜色不统一通常不是 P0。
2. 第一阶段：任务和界面体系
| 编号 | 检查问题 | 通过时应能提供的证据 |
|---|---|---|
| A01 | 本屏的玩家任务是否能用一句具体动作描述？ | 任务描述含目标、操作与完成条件，而非“首页”“养成页”等页面名 |
| A02 | 主要动作前需要的信息是否已列齐？ | 目标、当前状态、成本、限制、后果都有位置或明确的按需入口 |
| A03 | 主要约束是否按当前玩法确定？ | 棋盘辨认、谜题全局、成长比较、经营热点或动作视野的保护区 |
| A04 | 是否画出进入、选择、操作、结算、成长及返回？ | 流程图标明适用节点；直接开局或持续经营等例外有解释 |
| A05 | 大厅、局内与局外各承担哪些信息？ | 常驻入口清单有必要性与使用频率依据；低频入口有去处 |
| A06 | 导航关系是否表达平级、进度或对象详情的区别？ | 页面树、标签与地图关系一致，玩家知道自己在哪里 |
| A07 | 新手、系统解锁后和回访用户是否有对应状态？ | 至少三种信息量状态或不区分的理由；常用入口的位置规则 |
| A08 | 是否定义返回后保留什么？ | 选中、滚动、关卡、镜头、未提交选择与取消后果的说明 |
3. 第二阶段：灰度线框与空间分配
| 编号 | 检查问题 | 操作方法 |
|---|---|---|
| B01 | 核心玩法必见区是否先于外围入口分配？ | 标出必要对象、路径、危险来向；叠加所有常驻 UI 检查遮挡 |
| B02 | 安全区与微信胶囊是否分别处理？ | 使用真实窗口数据检查矩形；不能只画一个通用顶部刘海 |
| B03 | 手指和手掌遮挡是否被考虑？ | 在原型上叠加实际握持与触点轨迹，检查高频操作遮住的信息 |
| B04 | 关键读数与主操作是否建立清楚关系？ | 要求评审者指出当前目标、操作成本、结果反馈分别在哪里 |
| B05 | 固定 HUD、场景气泡和展开面板的职责是否清楚？ | 平移场景或切换对象，检查状态归属是否仍可理解 |
| B06 | 空间不足时是否有收纳与重排顺序？ | 逐步减小窗口，记录先缩间距、延展／裁装饰、收纳还是滚动 |
| B07 | 弹窗标题、退出与主要操作是否始终可达？ | 使用最长内容与最短支持窗口，滚到上下边界分别检查 |
| B08 | 新功能或活动是否有固定归属？ | 模拟增加两个入口，检查是否导致常用操作整体移位 |
| B09 | 可滚动区域与固定区域是否有清楚边界？ | 检查内容露出、滚动提示和末尾状态，避免把未看到误认为不存在 |
| B10 | 每种结构是否说明了代价？ | 至少记录一项被牺牲的空间、发现率或操作步骤及其验证方式 |
3.1 五类玩法的额外检查
| 结构 | 必查压力状态 | 重点看什么 |
|---|---|---|
| 棋盘／消除／合成 | 满格、相似物品、满槽、拖到边缘、快速连续操作 | 单元辨认、落点提示、容量可见、道具误触、变化后的对象定位 |
| 关卡益智 | 最复杂形状、远端规则关联、撤回后、提示展开 | 全局关系是否丢失；滚动／缩放是否改变解题所需信息 |
| 放置养成 | 多系统解锁、资源不足、多个红点、升级前后 | 成本和收益对应、入口含义、返回原对象、主循环方向感 |
| 模拟经营 | 多对象请求、镜头边缘对象、装修预览、取消选择 | 气泡重叠、对象归属、场景拖动冲突、模式退出与视角恢复 |
| 动作／生存 | 多方向危险、满特效、双指、暂停、切后台返回 | 视野、生命和危险可辨、操控冲突、恢复时是否有充分准备 |
4. 第三阶段：视觉、文字和组件状态
| 编号 | 检查问题 | 通过或失败的判据 |
|---|---|---|
| C01 | 灰度状态下分区与主次是否仍清楚？ | 可以辨认当前任务和主要动作；无需依赖所有控件同时高饱和 |
| C02 | 每种强调是否有一致含义？ | 红点、光效、选中框、锁与货币标识在相似场景中可以预测 |
| C03 | 动效是否遮住目标或争抢注意力？ | 同时出现的闪动与飘字经过最繁忙状态检查，必要读数仍可读 |
| C04 | 关键状态是否有颜色以外的表达？ | 选中、错误、品质与阵营可借文字、形状、标记区分 |
| C05 | 文字在最差背景上是否可读？ | 检查场景最亮／最暗区域、半透明底板和特效；关键文字有对比依据 |
| C06 | 长文案和大数是否有规则？ | 最长标签、昵称、倒计时、资源大数、负数均有可读样例 |
| C07 | 禁用状态是否说明原因与后续动作？ | 玩家能知道是锁定、资源不足、加载中还是暂无内容 |
| C08 | 选中、预览、消耗与提交是否始终指向同一对象？ | 快速切换条目时不会出现前一项预览配后一项操作 |
| C09 | 点击热区与视觉边界是否分别标注？ | 热区不产生含混重叠；遮罩、空白区域与事件层级有说明 |
| C10 | 组件是否覆盖必要状态？ | 默认、按下、选中、锁定、加载、提交、成功、失败按场景具备 |
| C11 | 进入／退出动画期间是否有输入规则？ | 连点、动画中点击和关闭后输入不会触发下层错误动作 |
| C12 | 轻反馈与阻断弹窗是否使用适当层级？ | 普通获得提示不强迫重复确认，关键决定又不会被轻易忽略 |
触控、对比度参考及适用边界见主文档第 7 节。W3C 的 CSS 像素参考不能直接贴到引擎设计稿上；任何内部尺寸目标都应说明最终显示比例。这里只校验设计证据，不将网页参考冒称为微信平台审核要求。
5. 奖励、广告与中断恢复
| 编号 | 检查问题 | 必查状态 |
|---|---|---|
| D01 | 普通获得、观看广告与付费是否可预期地区分？ | 标签、图标、消耗条件与进入后果；不能都只写“领取” |
| D02 | 奖励数字是否说明总量还是增量？ | 基础奖励、额外奖励、领取后账面变化能相互核对 |
| D03 | 激励入口是否覆盖不可用情况？ | 广告加载中、暂无广告、播放失败、中途关闭、完整观看 |
| D04 | 返回游戏是否被错误地等同于奖励完成？ | 依据实际完成状态显示“已领取”或未完成；中途关闭不伪造完成提示 |
| D05 | 返回后是否恢复合理上下文？ | 关卡、棋盘、选中对象、暂停状态和恢复提示有明确规则 |
| D06 | 其他允许路径是否仍可发现？ | 重试、普通领取、稍后处理等设计允许的操作在适当状态可见 |
| D07 | 提交期间是否防止重复操作且显示反馈？ | 重复触摸、慢网、重连和返回不会让用户误以为没有响应 |
| D08 | 奖励弹窗是否会连续截断主任务？ | 多个奖励同时到达时，队列、聚合和退出顺序经过评审 |
| D09 | 点击位置是否突然被替换成不同后果的操作？ | 动画结束、倒计时归零、新弹窗出现时检查误触风险 |
平台事实依据：微信激励视频关闭事件，正文于 2026-10-31 核查。完整观看字段支持区分状态；具体奖励一致性仍需工程实现与验证。上述检查是体验要求，未对具体产品是否符合运营规则作判断。
6. 第四阶段：适配与微信真机验证矩阵
矩阵中的具体设备与最小窗口由项目确定。推荐覆盖以下条件；不支持的方向或形态写清理由，避免拿“已在浏览器预览”替代“已在微信验证”。
| 条件 | 检查画面／任务 | 记录内容 |
|---|---|---|
| 最窄支持窗口 | 棋盘单元、长标签、资源条、关闭与提交 | 最小实际热区、换行、遮挡和点击结果 |
| 最短支持窗口 | 目标区＋玩法区＋操作区、最长弹窗 | 哪些内容滚动，必要操作是否仍可达 |
| 较长窗口 | 场景延展、底栏、空白与反馈位置 | 是否只是拉大间距，是否改变对象对应 |
| 不同系统边界 | 顶部胶囊、刘海、底部手势区 | 实际窗口／安全区／胶囊的来源与坐标转换 |
| 安全区字段缺失 | 兼容策略下的顶部与底部布局 | 采用的兼容依据和目标设备，不伪造平台返回值 |
| 横屏，如支持 | 两侧边界、操控区、侧栏、弹窗 | 重排后信息顺序、触点与视觉对应；不照搬竖屏坐标 |
| 左右手／不同握持 | 高频动作、连续拖动、双指操作 | 手遮挡、换手、误触；不能用通用热区图替代 |
| 微信前后台切换 | 局内、提交中、弹窗中分别切换 | 返回状态、恢复提示、资源与结果是否一致 |
| 网络与广告异常 | 提交慢、断网、无广告、广告关闭 | 反馈、取消／重试、上下文及领取状态 |
平台依据：窗口信息、胶囊位置、窗口变化，核查日期均为 2026-10-31。安全区的方向与缺失情况必须纳入验证。
6.1 用户任务脚本
不给“点右下角按钮”这种位置提示，使用玩家目标描述。新手和熟悉玩家分开记录，不把理解规则的时间全部归因于布局。
| 任务 | 给参与者的描述示例 | 观察重点 |
|---|---|---|
| 找到下一步 | “继续你刚才的进度。” | 首次选择、寻找过程、是否误入活动 |
| 完成核心动作 | “完成这个订单／解开这关／处理这位顾客。” | 必要信息是否能找到、对象对应、误触与求助 |
| 比较与成长 | “选择你认为合适的升级，并说明要消耗什么。” | 对成本、变化和结果的理解，不只记录点击成功 |
| 中断后恢复 | “处理这次失败，然后回到原来的任务。” | 能否区分可选奖励与普通路径、是否保留上下文 |
先用小规模定性试用发现阻断，再按风险补充设备与参与者。样本数量、代表性和阈值应在研究开始前记录；小样本不用于宣称总体转化提升。
6.2 指标定义，避免只比较审美偏好
- 任务完成率：独立达到预先定义完成条件的人次 ÷ 有效任务尝试次数；被提示后完成另列，不混入独立完成。
- 寻找时间：从任务呈现或状态稳定，到首次正确找到目标入口；计时起止一致，加载与等待时间单列。
- 误触：预先定义为命中非意图操作，记录触点、目标与后果；回头修改选择不必然是误触。
- 理解错误：参与者对成本、奖励或操作后果的描述与实际不一致，记录原话和当时画面。
- 中断恢复：能否回到指定上下文并继续任务，记录丢失的选中、位置、暂停状态或目标。
- 次要功能发现：用于防止收纳方案在降低拥挤的同时，使必要功能无法找到。
比较方案时尽量保持任务、内容量、设备和状态一致，并调整方案先后顺序以减少学习影响。报告原始人数与次数，不只给百分比；没有对照或充分证据时不宣称因果。
7. 问题与改版记录模板
复制以下字段填写。它是设计工作记录，不是自动评分系统；不建议把所有项目简单加总成“布局 90 分”。
问题编号／对应检查项：
产品与构建版本：
设备／系统／微信版本／窗口与方向：
用户阶段与任务：
触发步骤与当前状态：
原图／录像位置或时间戳：
直接观察（不夹带原因推断）：
影响与优先级：
原因假设及其他可能原因：
方案 A／方案 B：
选择依据、保留项与代价：
待验证指标及通过条件：
实际结果／未验证原因：
负责人／日期／下一步：
7.1 一个填写示例，非实测结果
假设问题：短屏线框中，道具区侵入棋盘最后一行。对应 B01、B06，原型参数采用主文档的演算示例。
候选 A：整体缩小。代价是单格和热区一起变小。候选 B：减少顶部装饰，把低频道具说明收进详情，保留道具与棋盘边界。代价是说明多一次展开。
验证计划：在项目实际支持的最短窗口中，检查最后一行可见性、点击命中、道具说明发现与长文案；视觉稿通过后再用微信真机验证。当前没有执行结果，不能写“B 提高准确率”。
8. 交付前的证据检查
- 每条平台结论有微信官方来源、核查日期与适用版本；获取失败的资料没有冒称已核实。
- 每张产品图说明平台归属、资料时间、原生／拼图／宣传加工性质与修改状态；未确认的版本明确标注。
- 静态观察没有被扩写成动效、点击后果、实机性能或用户行为事实。
- 每张原创线框标明“设计示意”，每个尺寸／比例说明是内部参数还是外部依据。
- 五类玩法与所有适用流程均有检查记录；不适用项有原因，缺证据项写“未验证”。
- 评审结果保留问题、后果、决策与代价，没有只有“好看／不好看”的结论。
- 本地文档检查、构建与浏览器验证单独记录；微信真机和用户测试分别列出实际完成情况。
需要从头理解方法时回到研究主文档；需要校准观察尺度时查看七个产品案例与证据边界。