微信小游戏视觉设计基础：从层级到整套规范
编写与来源核查日期：2026-10-31。本文面向微信小游戏界面设计初学者。建议先读本文，再完成从零设计一套界面的实战；遇到空间安排问题，参照布局设计研究。
本文的配色、尺寸和风格均为原创教学方案，不是微信平台规定，也没有经过微信真机或用户测试。图解采用可编辑 SVG；其浏览器显示不代表小游戏支持直接加载同样的 SVG。游戏中的导出与实现见素材格式和设计交付。
1. 先定义画面要帮助玩家做什么
视觉设计既要建立题材氛围，也要帮助玩家辨认、判断和操作。以原创练习“果园配对”为例：玩家翻开两张牌寻找相同水果，在机会耗尽前完成八对。局内最需要看清的是卡牌内容、剩余机会和配对进度，不是游戏标志或装饰树叶。
开始画图前，为当前界面写三句话：
- 主要任务：找出下一对水果。
- 必须知道：还剩几次机会、已经完成几对。
- 画面气质：温暖、清楚、轻松；用圆角卡片、浅奶油底和深绿色表达。
把“轻松”转换成能检查的选择：减少背景纹理对比、使用较大的稳定轮廓、保留卡片间隔。不要把“更可爱”当作唯一修改要求。局内与通关弹窗可以有不同的情绪强度，但使用同一套形状、字体和色彩含义。
练习产出：一张任务卡和一张风格板。风格板只收集与微信小游戏任务相关的形状、色彩、字体与材质，并记录参考图来源；不要直接拼贴他人的按钮当最终素材。
2. 构图与层级：先安排注意力
先用灰色方块画线框，不加水果插画。把信息分为：主要内容、辅助说明、装饰背景。比较它们的面积、位置、明暗和间距，再加颜色。
| 需要解决的问题 | 在果园配对中的处理 | 检查方法 |
|---|---|---|
| 一眼先看哪里 | 棋盘居中并占主要面积；机会和进度靠近棋盘 | 去掉颜色后仍能看出玩法区 |
| 什么是一组 | “剩余机会”标签与数字放进同一信息块 | 不会把机会数字误认成关卡编号 |
| 哪个操作优先 | 结算中主按钮使用实色，返回使用描边 | 能解释两个按钮的后果和主次 |
| 装饰是否干扰 | 树叶留在边缘，避开卡牌轮廓与关键数字 | 在满牌、翻牌和配对完成时都不抢信息 |
对齐也在表达关系。标题、说明和按钮共享左边线，通常比各自随意居中更容易形成一组；棋盘与单一结果弹窗则可以围绕中轴组织。先为组件内部选择对齐方式，再让页面按统一边距排列。
不要用固定“黄金比例”替代任务分析。扩大标题会挤压棋盘；扩大每张卡牌则需要减少间隙或其他内容。遇到空间不够时，先删去局内不必要的入口，再讨论缩小所有元素。空间取舍见五类玩法原型。
3. 色彩：先给颜色分配职责
先定义背景、表面、文字、主操作和风险提示，再决定具体颜色。下面是一组可直接用于练习的实色值；水果本身可以有多种颜色，但不应挤占界面操作的色彩含义。
| 语义名称 | 色值 | 用途与限制 |
|---|---|---|
background | #FFF8EB | 页面浅奶油背景，不承担可点击含义 |
surface | #FFFFFF | 信息块、卡面与弹窗底色 |
text-primary | #243B2E | 关键标题、机会数字和正文 |
text-secondary | #59665A | 规则、辅助说明；重要条件不能靠透明度弱化 |
action-primary | #276345 | 主按钮和配对完成标记，按钮文字用白色 |
accent | #F2BC57 | 果园装饰和奖励底板，文字仍用深色；不用作白字小按钮 |
danger | #A83D32 | 低机会提醒与错误说明，同时附文字或符号 |
border | #788777 | 需要可辨认的卡片、次按钮边线 |
disabled-surface | #E0E6DC | 不可操作按钮底色，配深色原因说明 |
一个颜色可以参与多个场景，但同一种操作含义应保持稳定。 本例主按钮为绿，不代表所有绿色装饰都能点击；可操作性还需要按钮轮廓、位置和文案共同表达。低机会使用“仅剩 3 次”加警示符号，不能只把原数字改红。
对比度怎么用
对比度衡量前景与背景的明暗差，不等于“颜色不同”。按 W3C 的 sRGB 相对亮度算法，白字与 #276345 的对比度约 7.1:1，深文字 #243B2E 与奶油背景约 11.4:1。这些值只适用于指定的实色组合，不证明描边字、缩小字、半透明遮罩上的文字必然清晰。
W3C 对网页普通文字给出 4.5:1、大号文字 3:1 的参考门槛，并列有例外。本文借用它检查微信小游戏的关键文字，不将它写成微信审核要求，也不把设计坐标字号直接对应 CSS 大字标准。算法与适用条件
实际检查时将文字放在最复杂、最亮和最暗的游戏背景上；动态场景应截取多个状态。背景变动太大时，加稳定底板往往比加多层发光更容易控制。禁用文案、广告条件和失败原因也应能在实际显示尺寸下辨认。
练习产出：语义色表、实色对比度记录，以及同一弹窗的正常与低机会状态。再做一次灰度查看，确认配对完成和未完成仍可区分。
4. 字体与排版：建立少量稳定的级别
先选一套字形清楚、授权适合项目的中文字体，检查数字、标点和缺字回退。标题可以有性格，局内机会数字、按钮条件和规则说明则应稳定。字体授权要逐项查看；“能下载”不等于允许随游戏分发。
本例以 750 × 1334 设计坐标起稿，以下全部是设计单位，不是屏幕物理像素、CSS px 或通用触控标准。
| 文字样式 | 字号／行高 | 用途 |
|---|---|---|
| 展示标题 | 48／64，粗体 | 首页游戏名、通关结果 |
| 分区标题 | 36／48，粗体 | 弹窗标题、关卡名称 |
| 关键数值 | 40／52，粗体 | 剩余机会，保持数值区域宽度稳定 |
| 正文／按钮 | 32／44，常规或中粗 | 操作名称、规则正文 |
| 辅助说明 | 28／40，常规 | 可选说明；关键复活条件优先使用正文级 |
若画面等比显示为 375 单位宽，32 的设计字号只剩约 16 的显示大小；仍需在目标设备看清晰度，不能因设计稿放大后清楚就通过。这里的 375 只是换算示例，不是所有微信设备的窗口宽度。
中文长标题优先换行、调整文案或扩大内容区，避免不断缩小字号。数字从 9 变成 10、进度从 0/8 变成 8/8 时，不应推动旁边按钮。正文按实际字体检查基线、字面高度和描边外扩，工程设置见文字排版。
练习产出：一张五级文字样式表；用最长标题、“暂无可用广告，请稍后重试”和最大机会数检查换行。
5. 间距与尺寸：让重复关系可复用
采用 8、16、24、32、48 的间距刻度作为本例起点，含义是减少无意的尺寸差异，不是要求所有位置都被 8 整除。750 宽页面左右各留 48，4 列卡牌间隔 16，则每张卡牌宽：
棋盘可用宽 = 750 - 48 × 2 = 654
卡牌宽 = (654 - 16 × 3) ÷ 4 = 151.5
保留小数比随意累加误差更合理；最终像素对齐由渲染方案与显示倍率检查。不要把一排卡牌各自取整后，留下越来越大的尾部偏差。
组件内部的间距表达内容关系：按钮图标与文字间隔可以是 16，弹窗说明与下一组操作间隔可以是 32。页面外边距和按钮内边距不必相同。圆角也应分级，例如按钮 24、卡牌 20、面板 32，避免随手拖到每个控件都不同。
棋盘卡牌热区随实际卡片矩形布置，相邻热区不重叠。暂停符号本身可以小，但要有足够的独立点击范围；视觉缩放动画不要同步缩小逻辑热区。手指操作最终由微信真机任务验证，不能从设计单位推断已达可用尺寸。参照输入与交互。
6. 图标与插画：先辨认，再增加细节
本例八种水果应具有不同轮廓，例如苹果、梨、香蕉、葡萄、草莓、橙子、西瓜和樱桃。红苹果与红草莓不能只靠色相区分：苹果的整体轮廓、草莓的尖端和籽点应在最终卡牌尺寸下可辨认。
将图标放进统一的构图框，规定主体占比、光源方向、描边粗细和底部阴影。香蕉细长，不能只按图片宽度机械缩放，否则比圆形橙子显得过小；通过视觉重量调整，但仍保持安全内边距。
| 元素 | 本例的统一规则 | 要避免的问题 |
|---|---|---|
| 水果主体 | 大轮廓、少量高光、正上方偏左光源 | 一部分写实、一部分扁平，辨认负担不同 |
| 功能图标 | 一致的线宽与端点，复杂含义配标签 | 用礼盒图标同时代表领取、广告和商店 |
| 完成标记 | 勾选加“已配对”语义，轮廓保留 | 仅降低透明度，让玩家以为图片没加载 |
| 暂停与返回 | 位置和含义稳定，弹窗写清退出后果 | 图标看似关闭，实际清空整局进度 |
绘制图标可以用矢量工具；涉及纹理再用位图工具。3D 渲染也可以产生二维素材，但这不是完成本例的前置能力。导入 SVG、PNG 或其他格式时，分别确认设计工具与微信小游戏运行时的能力，不能只看扩展名。
练习产出：八种水果的轮廓稿和实际尺寸对照。遮住颜色后请读者辨认，再记录混淆项；这是待执行练习，不是本项目已取得的测试结果。
7. 材质与风格：用可重复的规则表达题材
“果园”不要求每个面板都铺木纹。本例选取奶油纸面、绿色操作、圆润水果三种主要语言。背景仅放低对比叶片，卡牌使用白面和轻阴影，按钮用深绿实色；通关时才增加金色星点。
| 风格决策 | 示例规则 | 改动时要一起检查 |
|---|---|---|
| 形状 | 面板大圆角，卡牌中圆角，所有图标端点圆润 | 按钮状态、弹窗和卡背是否一致 |
| 描边 | 深绿灰细边，不给每段文字重复描边 | 亮背景上控件边界是否消失 |
| 光影 | 左上光源，一层底部阴影 | 按下态是否仍像同一材质 |
| 装饰密度 | 局内低，结果页适度增加 | 机会数字和下一步是否被遮挡 |
先完成一个“标准样板”：一张卡牌、一个主按钮、一个弹窗。用它们拼出两张页面后，再批量生产素材。如果两张页面只能靠分别修图保持好看，说明规则还不足以复用。
8. 组件状态：把视觉规范变成操作语言
主按钮至少覆盖正常、按下、不可用和加载中。按下态可以下移视觉内容并减弱阴影；不可用态保留标签并解释原因；加载时文案改成“正在准备…”，同时阻止重复提交。不要用同一种灰色同时表示“选中”和“不能点”。
卡牌使用不同状态：背面、第一张翻开、两张比较中、配对完成。比较中暂时不接受第三张卡片；配对完成保留轮廓和勾选。按钮状态与业务状态不必共用一张巨大的状态表，但转换条件必须对齐。按钮案例有更完整的输入处理说明。
动效同样要有规范：例如按压 80ms、翻牌 180ms、结果淡入 200ms、比较停留 600ms，均为练习起点，未通过用户测试。翻牌可能影响辨认，比较停留可能影响记忆，调整时应一起检查。切后台、打开暂停或减少动效时，最终牌面和业务结果不能依赖动画是否播完。
9. 交给下一位设计师或程序前检查什么
- 色彩按语义命名；正文、按钮和风险提示在实际背景上可辨。
- 字体来源和授权已记录，文字样式与长文案处理有规则。
- 图标在最终显示大小下可辨，含义不只由颜色表达。
- 圆角、间距、描边、光源与阴影可复用。
- 按钮和卡牌状态齐全，加载和失败原因有可读文案。
- 装饰、文字、按钮背景分别交付；必要文字保持动态。
- 九宫格边距、热区、最大内容和导出倍率有说明。
- 目标设备、实际微信窗口与真机未验证项分别列出。
完成这些内容后，进入完整界面实战。遇到某项不确定时，保留问题记录，不必为了“统一风格”掩盖未定义的行为。
10. 来源与进一步阅读
| 来源 | 支持的内容 | 适用于微信小游戏的方式 |
|---|---|---|
| W3C 文字对比度说明 | 明暗对比、阈值、sRGB 算法和例外 | 借作可读性校准；不等于微信规范或整套无障碍认证 |
| Figma 组件变体与交互 | 同一组件组织多种外观与交互状态 | 用于设计稿和原型；实际小游戏状态仍由工程实现 |
| Cocos 3.8 九宫格图像 | 保留边角、伸缩中部的资源方式 | 约束按钮与面板背景的设计交付；本项目未完成引擎验证 |
颜色与尺寸表、果园视觉方案和本章图解均为本站原创教学设计。资料核查日期为 2026-10-31；当前没有玩家偏好、误触率或商业指标结论。