微信小游戏布局设计研究：从玩法到完整界面体系
研究日期：2026-10-31。研究对象仅限微信小游戏；竖屏为主，横屏单独讨论。阅读顺序：本文建立方法 → 案例分析核对证据 → 评审清单用于设计与改版。
1. 研究结论与证据边界
视觉设计初学者可以先读视觉设计基础，掌握色彩、文字、图标与组件规范。读完本文后，通过果园配对实战将布局方法落实到整套界面，完整顺序见设计阅读路线。
布局首先是在有限屏幕内安排玩家的下一次决策。 先确定玩家看什么、判断什么、在哪里操作，再决定资源条、菜单、活动入口和装饰的位置。把一张成熟游戏截图的四周按钮搬过来，容易继承它的拥挤，却没有继承它的玩法、用户阶段与经营目标。
本研究得到五条可用于方案评审的判断，均为设计归纳，尚未通过本项目的用户实验验证：
- 核心玩法应先获得可用空间。 棋盘需要可辨认的格子；益智关卡需要完整路径；实时动作需要危险预判空间。三个问题不能用同一套“中间放角色”的模板解决。
- 布局需要分配空间，也需要分配时间。 局内、结算、升级和活动领取可以承载不同信息；减少局内常驻入口，有时比缩小按钮更有效。
- 场景内信息和固定界面各有职责。 顾客的订单气泡适合跟随顾客，总资源适合固定显示。强行统一会增加寻找成本或遮挡。
- 固定位置有助于建立操作预期，新增功能应有收纳规则。 屏幕变长、系统解锁或出现活动时，优先延展场景、滚动内容或展开分组，避免频繁移动常用按钮。
- 漂亮的静态稿不足以证明布局成立。 满资源、长文案、失败、广告返回和最短支持屏幕，往往比理想状态更能暴露问题。
1.1 三种论据怎样区分
| 标记 | 可以支持的结论 | 不能支持的结论 |
|---|---|---|
| 平台事实 | 微信官方接口返回什么、配置表达什么 | 哪一种布局必然提高留存或收入 |
| 界面观察 | 指定来源、版本图片中可见的分区、形状、文字与位置 | 未录制的操作行为、全部流程、现版界面 |
| 设计建议／推导 | 基于任务和观察提出的候选方案、取舍与验证方法 | 已证明的用户偏好或商业效果 |
本次采用资料研究、项目内原图查看及原创线框推导，没有登录这些游戏进行微信真机测试，也没有获取留存、点击率、误触率或广告收益数据。素材的版本、来源和缺口见案例证据表。文中布局图全部为原创示意，非产品原图；尺寸示例为设计练习参数，非微信平台规定。
2. 从核心循环推导布局，先于美术风格
2.1 先写一句玩家任务
将“做一个三消首页”改写成“玩家辨认遮挡物、选择一个物件，并判断暂存槽是否还能容纳它”。第二句话已经指出三个空间需求：可辨认的物件区、可命中的目标和持续可见的容量反馈。
每个界面至少写清四项：本屏任务、做决定前必须知道的信息、主要操作、完成后去哪里。同一屏允许多个操作，但必须能说明当前阶段的优先顺序。可逆的选中与不可逆的消耗，应在位置、文案和反馈上体现差别。
| 玩法结构 | 主要决策 | 应优先保护的空间 | 必要的邻近关系 | 典型代价 |
|---|---|---|---|---|
| 棋盘／消除／合成 | 选哪件、放哪里、还能放多少 | 可辨认的棋盘或物件区 | 目标与棋盘，容量与道具 | 棋盘过大使目标离操作太远；过小使识别和拖放困难 |
| 关卡益智 | 这一步会改变哪些路径或规则 | 完整可推演的局面 | 当前规则、撤回与重试 | 全图缩小会损害辨认；裁掉区域可能改变解题条件 |
| 放置养成 | 领什么、升什么、下一步做什么 | 当前成长目标与核心动作 | 资源差额、收益变化与升级按钮 | 同屏成长系统越多，入口和比较成本越高 |
| 模拟经营 | 哪个对象需要处理、怎样提升经营 | 场景热点及其状态 | 对象与气泡、升级与成本 | 气泡拥挤；场景滚动与固定菜单争夺手势 |
| 动作／生存 | 危险在哪、往哪走、何时释放能力 | 角色周围与移动方向的可见范围 | 生命与危急反馈、控制与即时反馈 | 大控件便于操作但遮挡；小控件腾出视野却增加误触 |
同一款微信小游戏可以包含多类结构。例如，经营游戏中的合成棋盘应按棋盘规则布局，装修界面再按场景预览规则布局。分类单位是当前决策场景，不必强迫整个产品只套一种模板。
2.2 布局选择的设计树
先判断是否持续实时操作：是，则先保护视野与操控；否则判断局面是否必须完整可见：是，则先保护全局推演；其余再判断决策围绕固定网格、场景对象，还是成长条目展开。最后才安排导航和商业入口。
这个顺序用于确定主约束。例如，有网格的动作游戏仍然要先解决实时危险的辨认，不能因为“有格子”就优先套用棋盘面板。
3. 空间模型：场景、玩法、信息与操作分层
图中的颜色是职责标记，正式界面不必采用同样配色。
| 层 | 设计责任 | 约束规则 |
|---|---|---|
| 装饰背景 | 氛围、题材、空间连续感 | 允许延展或裁切；不要把必要提示画进可能被裁的背景 |
| 核心玩法／场景 | 棋盘、路径、角色、经营对象 | 明确哪些区域必须可见、哪些可以滚动、哪些允许被手指遮住 |
| 常驻信息 HUD | 目标、生命、容量、必要资源 | 显示与当前决策相关的读数；与背景建立稳定对比 |
| 操作与导航 | 主要动作、道具、返回、系统切换 | 定义热区、优先级和位置稳定性；与系统胶囊分别避让 |
| 临时反馈与弹窗 | 获得奖励、比较装备、暂停、失败 | 定义是否阻断、下层是否暂停、如何退出和返回 |
3.1 先画保护区，再安排入口
在空白线框上先标出：系统避让区、玩法必见区、手指遮挡区、固定操作区和临时反馈区。随后安排具体内容。这样，“新增活动按钮”会成为一次有成本的决策：它占用了哪里，是否压住路径或状态，有没有合适的次级页面。
安全区只解决部分系统遮挡问题，不代表区域内的任何位置都适合放按钮。右上角胶囊还需独立避让，手掌和手指也会遮住内容。单手习惯、左右手和握持姿势需通过目标用户测试确定，不能用一张固定“拇指热力图”替代验证。
3.2 固定界面、场景附着与按需展开
三种方式可以组合：
- 固定界面适合跨场景比较的资源、生命和导航。优点是容易找，代价是持续占据空间。
- 附着于对象的界面适合订单、可收取状态和选中标记。优点是关联清楚，代价是随镜头移动，密集时会互相遮挡。
- 按需展开适合技能说明、装备比较和低频系统。优点是释放常驻空间，代价是多一次展开，可能降低发现率。
当场景中多个气泡重叠，可按当前选择显示详情、聚合远处状态、把重要对象导向任务列表。不能只缩小所有气泡，否则视觉拥挤可能变成点击困难。
4. 五类玩法的布局原型
4.1 棋盘、消除与合成：先保证辨认和落点
候选结构：顶部目标与剩余步数／能量，中部棋盘，紧邻棋盘的容量或选中反馈，底部道具与次要操作。订单很多时可横向滚动，但应说明当前优先订单，避免“看不见的目标”要求玩家反复切换。
先确认最小可辨认单元，再决定行列数。图标需要区分轮廓、阶段和数量；只改变颜色，可能无法区分相近合成等级。拖拽时，抓取物可相对触点偏移，并显示落点轮廓；偏移距离需实测，过大会降低位置对应感。
容量槽代表失败风险时，应持续可见，填满前后保留相同位置。道具应和物件拾取区有明确间隔，剩余次数、锁定和广告获取状态不能只靠角标颜色表达。局面已改变后，玩家仍应看得清刚才发生了哪次合成或消除。
适用条件：主要选择发生在固定棋盘或中央物件区。取舍：加大棋盘可能挤压目标和道具，保留大量订单则会压缩单格。验证：满格、最大图标相似度、拖到边缘、快速连点、没有可合成项。
4.2 关卡益智：保护推演关系
候选结构：关卡标识与简短规则在上，完整谜题居中，撤回、重试、提示构成明确工具区。界面尽量区分“看懂规则”和“执行一步”两个阶段，教程可在首次遇到规则时附着说明，理解后收起。
完整可见不是把任意大关卡缩成邮票。若最小对象已经无法辨认，应在关卡设计阶段限制尺寸，或明确采用可平移／缩放的规则，并提供全局概览与当前位置。解谜中的遮挡可能改变可推演信息，因此滚动和裁切都要作为玩法决策审批。
适用条件：玩家需要比较非相邻区域、预想多步后果。取舍：全图可见限制局面规模；放大观察会增加记忆成本。验证：玩家能否解释当前目标、撤回影响哪一步，以及提示是否暴露过多信息。
4.3 放置养成：让收益与下一步动作相邻
候选结构：核心角色／重复动作是视觉中心；主要成长目标和操作靠近；常用系统形成稳定底部导航；活动和低频系统有统一收纳区。
“战力提升”只给一个闪动数字，未必足以支持升级选择。比较时应同时交代当前状态、预期变化、资源成本与不足差额。资源短缺反馈尽量在原按钮附近出现，避免跳到另一页面后玩家忘记原目标。
新手初期、系统解锁后和长期玩家可以有不同信息量，但常用按钮的位置应尽量稳定。可逐步启用预留位置或在已有分组中新增项目，而不是解锁一次就重排整个底栏。活动可按剩余时间、是否有可领取项等规则组织，红点的含义应一致。
取舍：收纳减少拥挤，也会降低新活动的曝光；大角色强化成长感，也占用比较数据空间。验证：能否从一次领取或升级顺利回到原循环，是否出现领完一个又被多个弹窗截断。
4.4 模拟经营：场景本身承担信息架构
候选结构：固定资源概览＋场景对象热点＋任务入口＋底部管理工具。可操作建筑、顾客、家具通过一致的形态或状态标记表达可交互性，不要求玩家逐个试点。
镜头移动时，对象气泡应跟随对象，固定菜单保持稳定。对象移出屏幕后，可以在任务列表或边缘指示中保留重要状态；不必把所有对象都变成常驻按钮。进入装修模式后，经营操作应暂停或明确降级，底部选择与场景预览建立对应，取消后恢复原视角。
取舍：场景反馈更直观，但高密度时气泡会挤压美术和命中空间；聚合列表更可控，却减弱空间感。验证：多顾客同时请求、建筑被菜单遮住、拖动场景误选家具、购买不足和预览取消。
4.5 动作与生存：视觉空间也是反应时间
候选结构：角色及危险来向构成玩法保护区；高频操控占明确触摸区；生命、关键能力和波次维持稳定位置；低频成长选择在安全节点展开。
设计时同时标注控制区、手指遮挡区、敌人接近方向和伤害提示。把血条放得很近可以减少视线移动，却可能淹没在特效里；固定 HUD 更清晰，却可能要求玩家移开视线。需要用真实战斗片段判断，静态稿无法证明两者谁更好。
升级选择、暂停和恢复是布局的一部分：如果选择会阻断操作，应规定暂停规则；返回战斗时给出明确恢复提示，避免玩家尚未重新握好设备就受到伤害。这是候选设计规则，是否采用及等待时间由玩法验证决定。
取舍：更大的操控热区能提高容错，也占用视野；全屏拖动提供操作自由，却会与菜单和场景点击冲突。验证：多方向敌人、危险贴边、双指操作、误触菜单、广告或微信前后台切换后的恢复。
5. 完整界面体系：将信息放到合适的阶段
流程图是一种候选信息架构；直接开局的小游戏可省去大厅，持续经营或放置产品可能没有离散的每局结算。
| 界面 | 玩家最需要回答的问题 | 布局重点 | 常见失败与修正 |
|---|---|---|---|
| 进入／加载 | 是否正在进入、需要多久、失败怎么办 | 进度或阶段反馈、必要重试 | 假进度或长时间空白；显示真实阶段及可恢复路径 |
| 首页／大厅 | 继续哪里、当前有什么值得做 | 继续／开始主入口、必要资源、明确导航 | 活动图标围满四周；按任务与频率分组 |
| 关卡选择／地图 | 我在哪、下一关在哪、为什么锁住 | 当前节点、可达路径、解锁条件 | 长地图每次回顶部；保留当前位置与滚动上下文 |
| 局前准备 | 是否准备好、还缺什么 | 当前配置、必要差额、开始操作 | 升级和开始同权重；明确当前决策 |
| 局内 | 当前目标、风险、下一步 | 核心玩法、必要信息、高频操作 | 常驻低频系统；迁移到暂停或局外 |
| 成功／失败结算 | 发生了什么、获得什么、还能怎么做 | 结果、基础奖励、下一步；失败时说明可选路径 | 奖励动画遮住操作或广告和普通领取含混；分阶段呈现并清楚标识 |
| 成长／背包／装备 | 哪个更好、消耗多少 | 列表与详情的对应、差异和成本 | 只显示总战力；把变化项、代价与操作放在一起 |
| 奖励／活动弹窗 | 为什么出现、能否稍后处理 | 触发理由、主要动作、可发现的退出 | 关闭后继续弹下一层；合并领取或延后到合适节点 |
5.1 导航要同时表达位置和返回承诺
标签栏适合稳定且高频的并列目的地；局部页签适合同一对象的不同视图；地图适合有前后进度关系的内容。不要把有先后条件的成长路线伪装成完全平级的标签，也不要用关卡地图承担全部系统导航。
关闭一个面板后，玩家应回到合理上下文：原列表位置、选中对象、镜头位置或原关卡。是否保留未提交修改必须提前定义。对话框的“取消”和关闭应有一致后果，重要消耗不要只依赖点击遮罩关闭来处理。
5.2 弹窗需要拥有焦点，也要交还焦点
区分通知、轻反馈、可交互面板和阻断式对话框。获得少量资源可以用轻反馈；需要比较两个装备才适合面板；必须做决定的确认才阻断。多层弹窗应保持清楚的层级与退出顺序，反馈粒子不应遮住关键数字或关闭热区。
定义从触发到退出的完整状态：进入中 → 可操作 → 提交中 → 成功／失败 → 返回。进入动画未结束时是否接受点击、连续点击是否重复提交、失败后能否重试，都会改变界面布局和可见反馈。
6. 注意力、密度与视觉语言
6.1 确定视觉主次，控制同时争抢注意力的元素
尺寸、明暗、饱和度、位置、留白与运动都会改变显著性。若所有活动图标都在跳动，即使主按钮很大，也可能没有稳定的视觉中心。先用灰度线框比较分组、间距和面积，再增加配色和装饰。
可先采用“当前任务—必要读数—次要功能—背景装饰”的优先顺序，然后按具体玩法调整。紧急生命警告可以临时上升为首要信息；商店页中的商品比较也可以成为当前任务，不能把某个元素永久定义成第一层。
6.2 信息密度不是按钮数量一个指标
同样十个入口，按含义分组并具有稳定位置，可能比散落在四边的六个闪动入口更容易理解。评审时分别观察：
| 密度维度 | 如何记录 | 可尝试的调整 |
|---|---|---|
| 空间占用 | 在指定状态截图上标注遮挡区、可操作区与必见区 | 移位、聚合、滚动、改到另一个阶段 |
| 选择复杂度 | 玩家完成任务要区分哪些相似选项 | 分组、名称补充、默认推荐并说明依据 |
| 注意力竞争 | 同时闪动、倒计时或浮动的对象 | 降低常驻动效，按紧急程度调度 |
| 理解成本 | 无说明时能否解释图标、数值、红点 | 统一含义，补文字或按需说明 |
不要把布局面积直接当作注意力或点击概率；没有眼动或行为实验时，只能记录空间占用与设计假设。
6.3 文字、图标和材质共同建立层级
同类资源、同类消耗、同类交互采用稳定视觉语法。主要操作需要能与装饰区分，禁用状态仍应可读并说明原因。红点不能同时代表“有奖励”“有新商品”“可升级”和“推荐观看广告”，否则玩家无法预测点击结果。
数字单位、溢出和换行必须设计：长昵称、资源大数、负收益、倒计时结束和按钮两行文案都要有规则。轮廓、标记和文字可以补充颜色；错误、品质或阵营不宜只靠红绿区分。题材材质与花纹尽量留在背景层，关键读数有稳定底色。
7. 操作与可读性：从原型参数到真机证据
7.1 分清视觉大小和点击热区
图标可以小于命中区域，但相邻热区不应产生含混重叠。扩大透明热区时仍需考虑层级和手势冲突，不能只看按钮视觉边缘。连续拖动区域应明确与滚动、长按、场景选择的优先关系。
作为通用触控参考，W3C 的 WCAG 2.2 最小目标说明给出 24×24 CSS px，并列出间距等例外；增强目标说明为 44×44 CSS px，也有例外。它们是网页可访问性参考，不是微信小游戏官方按钮尺寸要求，也不能直接等同于引擎设计稿像素。
本研究建议在原型中以可见逻辑尺寸约 44×44 的独立高频按钮作为起点，随后按真实显示比例、设备和任务测试调整；棋盘格、路径点等与玩法直接相关的目标需单独验证。示例：750 宽设计稿映射到 375 逻辑宽窗口时，88 个设计单位才约等于 44 个窗口逻辑单位；设备像素比影响渲染清晰度，不能据此再缩小热区。
7.2 读得清要在真实背景和状态中检查
W3C 的文字对比度说明以普通文字 4.5:1、大号文字 3:1 为参考门槛，并有例外；本文借它校准关键文字，未对小游戏作 WCAG 合规认证。对移动场景、描边字和半透明底板，应检查最不利背景，不能只测设计稿中的纯色样例。
字号没有一个适用于所有微信小游戏的固定值。先在目标显示大小下检查长标签、资源数、帮助文字和弱提示；若需要反复凑近辨认，优先减少内容或调整结构。字体放大后仍要能找到关闭与主操作，不能用截断隐藏关键成本或条件。
8. 屏幕适配：定义重排规则
8.1 微信平台事实怎样转化为设计约束
| 平台依据 | 官方可确认的信息 | 对设计稿的影响 |
|---|---|---|
| wx.getWindowInfo | 有窗口、屏幕、像素比等信息；安全区按竖屏正方向定义，部分机型可能不返回 | 明确坐标系和缺失时的兼容方案；安全区不能靠固定截图推断 |
| wx.getMenuButtonBoundingClientRect | 返回右上角胶囊矩形，以屏幕左上角为原点 | 给胶囊单独保留避让空间；安全区内也可能与胶囊冲突 |
| wx.onWindowResize | 可以监听窗口尺寸变化 | 定义变化后哪些元素重排、哪些保持大小，重新核对命中 |
| 小游戏配置 | deviceOrientation 配置横竖屏方向 | 项目先决定支持方向，再评审对应结构；支持横屏不等于已有横屏设计 |
以上页面于 2026-10-31 成功获取正文核对。wx.getWindowInfo 标注基础库 2.20.1 起支持，胶囊接口 2.1.0 起支持，窗口变化监听 2.3.0 起支持；目标基础库和客户端仍需项目核对。本文只取与布局直接相关的能力，不展开接口实现教程。
8.2 为每个区域写适配契约
| 区域 | 保持什么 | 允许怎样变化 | 不足时的处理 |
|---|---|---|---|
| 背景与装饰 | 题材与主视觉连续感 | 延展、裁切非必要装饰 | 先减少装饰，而非先缩小操作 |
| 棋盘／谜题 | 格子比例、规则关系、可辨认性 | 在允许范围内等比缩放、调整外部间距 | 检查最小单元；必要时改变关卡规模或采用明确的视图操作 |
| 资源与目标 | 必要字段和含义 | 数值缩写、有限换行、分组 | 低优先内容进入详情；避免隐藏局内必要条件 |
| 主操作 | 可读标签、可靠热区 | 随安全边界移动、横竖屏换位 | 调整周边布局，不能随全部内容无限缩小 |
| 列表与弹窗 | 标题、退出与提交可达 | 内容区滚动，最大宽高约束 | 固定必要操作，滚动详情；明确内容是否还有下半段 |
不要预先指定所有区域必须占屏幕多少百分比。比例是内容与约束共同计算后的结果。一个用于评估的简化模型是：
可用高度 = 窗口高度 - 顶部保留带 - 底部保留带
玩法区上限 = 可用高度 - 目标区 - 道具区 - 必要间距
正方形单格边长 = min(棋盘可用宽度 / 列数, 玩法区上限 / 行数)
顶部保留带已综合安全边界与胶囊避让时，不要再把同一部分重复相减；复杂布局可以采用矩形避让而非整条顶部保留带。横屏需先将相关坐标变换到统一的当前视图坐标，不能直接照搬竖屏安全区字段。
演算示例，全部数值为自定练习参数：窗口 375×667，顶部／底部保留带分别为 54／24，目标区 64，道具区 72，必要纵向间距总计 32，左右边距各 16。棋盘可用宽为 343、高为 421；7×8 棋盘的单格上限是 min(343÷7, 421÷8)，即 49。若可用纵向高度减少 100，单格上限约 40.1。此时应评估缩短目标区或收纳次要内容能否保持辨认，而不是默默接受更小的格子。
8.3 横屏应重新组织信息
横屏动作玩法常需要双手控制与横向预判；横屏棋盘可以把目标和工具移到侧边，保留棋盘比例。是否更好取决于玩法、握持和视线移动，本文没有跨设备实测支持优劣排名。
横屏检查两侧系统边界、胶囊、双手遮挡、侧栏宽度和文字换行。支持两个方向时，保持操作含义、对象对应与退出逻辑一致；位置可以变，玩家需要重新理解的规则应尽量少。底层适配原理可继续阅读屏幕适配；Cocos 项目可参考 3.8 多分辨率文档，实际引擎版本由工程核对。
9. 奖励和广告入口：把选择与后果表达清楚
本节是设计建议，不代替微信最新运营规则。普通领取、额外激励和付费购买应通过名称、图标、成本和位置建立可预期的区别，避免用同样的“领取”让玩家进入不同流程。
| 时机 | 合适的布局目标 | 需要同时设计的状态 |
|---|---|---|
| 局外额外奖励 | 基础收益和可选额外收益清楚可比 | 加载中、可观看、暂无广告、已领取 |
| 失败后可选复活 | 当前失败、继续条件与重试后果清楚 | 中途关闭、播放失败、奖励确认、恢复操作 |
| 道具不足 | 解释缺少什么、补充途径和返回承诺 | 补充成功后回到原对象，重复点击不重复消耗 |
| 多个活动待领取 | 将奖励组织成可理解的任务集合 | 合并展示、逐项结果、领取失败与稍后处理 |
微信 RewardedVideoAd.onClose 提供 isEnded 表达是否完整观看。由此可知，“回到游戏”本身不足以代表奖励已满足条件；设计应区分完整观看、中途关闭和失败。具体奖励判定、兼容和一致性由工程处理，本文只定义玩家可见状态。
可选奖励应显示获取条件，额外收益应说明是总量还是增量；例如“额外 +100”比含混的“翻倍领取”更容易在数字变化后核对。若普通重试也是设计允许的路径，应保持可发现。用延迟出现、伪装关闭或在刚触摸的位置突然替换按钮，可能增加误触，不能将这种误触直接解释为真实意愿。
10. 从研究到方案：建议工作流程
- 任务与状态表：为当前界面写任务、必要信息、主操作、去向和异常状态。
- 灰度线框：标出系统避让、玩法必见和触摸区域，至少比较两种结构；先不依赖美术掩盖问题。
- 全流程原型：串起进入、操作、结算、成长和返回，写明各处恢复的上下文。
- 适配契约与压力稿：覆盖短屏、长文案、满格、多个活动、无广告、加载失败等状态。
- 视觉规范与交付：定义层级、组件状态、图标含义、间距和可伸缩规则，关联实际设计稿。
- 微信真机与用户任务验证：记录完成率、误触、寻找时间及中断恢复；发现问题后回到对应约束修改。
建议每个候选方案附一张决策记录：问题是什么、保留了什么、牺牲了什么、证据是什么、怎样验证。示例见评审清单中的改版记录。
11. 下一步研究与资料索引
本次最需要补充的是指定版本微信实机的完整操作记录：目前公开图能说明局部分区，却不足以覆盖所有产品的结算、弹窗队列和广告返回。下一轮应按案例采集表补齐，不能把文中候选流程当作已观察的产品行为。