App设计规范不是把字号、色板和图标集中到一张表里，而是把“什么场景用什么样式、发生变化时怎么反馈、交付时如何验收”写成团队能重复执行的规则。真正有用的规范，应该让产品、设计和研发在同一个页面上对齐，而不是让设计师在每个页面重新猜一次间距和颜色。
下面用一个订单详情页贯穿说明：用户查看订单、发起支付、遇到处理中或失败、再次重试，最后完成退款。你可以在墨刀设计中整理页面和组件，再用真实内容检查规则。这样得到的不是抽象的视觉清单，而是一份可以评审、交付和继续维护的 App 设计规范。
先用真实任务划定规范边界
规范从任务开始，而不是从颜色开始。订单详情页至少包含以下状态：正常展示、支付中、支付成功、支付失败、无权限查看和订单已关闭。每个状态都应回答三个问题：用户现在知道什么？下一步能做什么？发生错误后怎样恢复？如果这些问题没有答案，单独规定按钮颜色也不能保证界面可用。
| 页面状态 | 用户需要看到的信息 | 可执行的下一步 | 验收依据 |
|---|---|---|---|
| 待支付 | 金额、截止时间、收货信息和订单号 | 支付、修改地址或取消订单 | 主按钮突出，金额与状态不会被截断 |
| 支付处理中 | 请求仍在进行，避免重复提交 | 等待结果或查看订单状态 | 按钮进入处理中，刷新后状态可恢复 |
| 支付失败 | 失败原因和是否扣款的说明 | 重试、换支付方式或联系客服 | 错误信息可读，输入内容和订单信息保留 |
| 无权限或已关闭 | 当前不能操作的原因 | 返回列表、申请权限或查看帮助 | 禁用状态与无权限状态能区分 |
这张状态表就是规范的边界。它能帮助团队判断哪些规则属于通用组件，哪些是业务页面的例外；也能避免把“所有按钮都用同一套样式”误当成一致性。
一条规范至少要写清四件事
每个规范项都建议按“用途、样式、状态、例外”记录。比如“正文使用 14px”只有样式，没有说明长文案、系统字体放大和窄屏如何处理，研发仍然需要反复询问。把这四项写完整，规则才有可执行性。
- 用途：说明它服务于标题、说明、金额、警告还是操作，避免同一颜色承担互相冲突的含义。
- 样式：记录字号、字重、行高、颜色、间距、圆角和资源格式等可以检查的值。
- 状态：覆盖默认、按下、选中、禁用、加载、成功和失败，说明状态变化的视觉与交互反馈。
- 例外：写清长文本、空数据、权限不足、主题切换和系统字体放大时允许怎样变化。
文字规范：先解决真实内容，再谈层级
文字层级通常分为页面标题、区块标题、正文、辅助说明和数据强调五层，但层级不是越多越专业。先把订单号、商品名、付款金额、截止时间和失败原因放入页面，再确定每一层的字号、字重和行高。这样能及时发现“规范样例很整齐，真实文案一放就溢出”的问题。
- 商品名称可以按卡片宽度限制行数，超出后提供完整内容的查看方式；付款金额、订单号和错误原因不宜直接裁切。
- 中文、英文和数字混排时，检查基线、字重和行高。品牌字体不可用时，明确系统字体回退，不用“默认字体”带过。
- 系统字体放大后，按钮、列表行和弹窗应能容纳文字。确需固定高度时，写明适用范围和溢出处理。
- 标题、辅助说明和状态标签的颜色要有语义差异，不能只靠变小或变浅来表示次要信息。
对于需要截断的场景，可以参考界面文字截断的处理方法，把截断规则、完整查看入口和可访问性要求一起写进组件说明，而不是只在视觉稿上画三个省略号。
色彩规范：用语义命名，不用颜色编号代替规则
颜色应按职责组织，例如品牌主色、主要文字、辅助文字、页面背景、边框、成功、警告和错误。名称最好表达语义，如“反馈／错误”或“文字／主要”，不要只写“红色 2”“深灰 1”。换主题或调整品牌色时，团队才能保持含义不变。
- 同一种状态在订单列表、详情页和弹窗中保持同一语义；成功、警告、错误不要在不同模块使用相反颜色。
- 错误提示同时提供文字或图标，不依赖红色单独传递信息；选中状态也应有勾选、边框或形状变化。
- 分别检查浅色卡片、深色背景和禁用控件上的文字对比，记录不适用的背景组合。
- 状态色不能替代操作层级。删除是危险操作，但是否使用高强调颜色要由当前任务和可撤销性决定。
图标规范：统一视觉语言，也保留可点击边界
图标规范应记录画布尺寸、线条粗细、圆角、视觉重心、命名和使用场景。能用矢量表达的图标保留矢量源文件，但交付格式应按实际平台和研发方案约定；PNG 是位图格式，不能把“矢量图”和“必须导出 PNG”写成同一个要求。照片与复杂插画也不需要强行矢量化。
图形尺寸和点击区域是两回事。关闭图标可以保持较小的视觉尺寸，同时放入更大的可点击区域，并与相邻操作留出间隔。默认、按下、选中和禁用状态要有可辨识的变化；未选中和禁用不能仅靠同一个浅灰色区分。
图标可以按底部导航、工具栏、列表操作等界面位置分类，也可以按功能图标和说明性图形分类。陌生或容易歧义的功能图标应配文字标签，装饰图形不能看起来像可点击按钮。
按钮规范：把优先级和状态写成矩阵
按钮层级由当前任务决定。订单详情页的“立即支付”是主操作，“修改地址”或“稍后处理”是次要路径，“取消订单”可能是危险操作。不要把所有动作都叫“确定”，按钮文案应直接说明点击后的结果。
| 按钮类型 | 适用场景 | 至少要定义的状态 | 交付时要说明什么 |
|---|---|---|---|
| 主要按钮 | 承接当前步骤最重要的下一步 | 默认、按下、处理中、成功、失败 | 前置条件、提交后去向、重复点击处理 |
| 次要按钮 | 保存草稿、返回、稍后处理 | 默认、按下、禁用 | 与主按钮的关系和替代路径 |
| 危险按钮 | 删除、清除、退出编辑 | 默认、确认、取消、完成 | 影响范围、是否可撤销、失败后的恢复方式 |
每个按钮还要说明不可操作的原因。单纯把按钮变灰会让用户不知道缺少什么条件；提交失败时应保留可恢复的输入，并给出下一步。可撤销的操作优先提供撤销路径，不要把每次点击都变成确认弹窗。
把规范落到组件、页面和交付物
规范写完后，按以下顺序落地到一个可评审的订单详情页。每一步都应产生可交付的结果，避免只留下截图。
- 建立规则清单：列出文字层级、语义色、间距、圆角、图标、按钮和状态，并给每项编号。
- 制作组件状态：为按钮、状态标签、订单卡片和错误提示分别补齐默认、加载、成功、失败和禁用状态。
- 填入真实内容：使用长商品名、真实长度的订单号、不同金额、空值和失败原因，检查换行、对齐和容器高度。
- 走完关键路径：在移动端和桌面端各执行一次支付、返回、重试和取消，记录视觉偏差与行为结果。
- 形成交付说明：在墨刀设计中写明组件名称、状态名、资源路径、例外规则和验收结论，研发按编号逐项复核。
需要比较制作方式时，可以参考移动端 UI 设计工具，重点看真实页面能否复用组件、标注状态并支持团队评审，而不是只看素材数量。
上线前检查清单
- 每个颜色、字号和图标是否写明用途，是否存在同一语义多种表现。
- 长标题、长订单号、金额、空值和错误信息是否在窄屏与字体放大后仍可读。
- 按钮是否覆盖默认、按下、禁用、加载、成功和失败，状态是否能被非颜色线索识别。
- 图标的视觉尺寸、点击区域、命名、源文件和导出格式是否分开说明。
- 权限不足、网络失败、订单关闭和重复提交是否有明确提示和恢复路径。
- 组件名称、状态名、资源路径和验收结果是否能让研发不依赖截图猜规则。
- 同一任务在列表、详情和弹窗中的文字、颜色和按钮层级是否一致。
- 最终页面是否在墨刀中完成一次可复现的评审，并保留问题、负责人和处理结论。
