UI界面设计规范的核心，不是把按钮统一成同一个圆角，也不是做一页颜色和字体展示。真正有用的规范，需要让设计师知道“该怎么设计”，让开发知道“该怎么实现”，让测试知道“什么算通过”，同时保证界面在不同屏幕、输入方式和用户能力下仍然可用。
如果现在还只用“主色 + 辅助色 + 8px 间距 + 统一按钮”来理解 UI 规范，会漏掉很多真正影响产品质量的部分。更完整的 UI 设计规范，至少要覆盖视觉基础、Design Token、组件状态、响应式与自适应、无障碍、异常状态和设计 QA。
先纠正几个常见但已经不够准确的旧做法
很多入门教程里的方法并非完全错误，只是容易被误解成“行业硬标准”。
60-30-10 配色可以参考，但不是 UI 的通用规则
60-30-10 更像一种视觉配比经验，适合帮助初学者理解主次关系，却不适合直接拿来定义复杂产品的颜色系统。真正落地时，更重要的是建立语义化颜色：品牌色、背景色、文字色、边框色、成功、警告、错误、信息，以及它们在浅色、深色和高对比模式下的对应关系。
“Web 安全字体”不再是字体选择的核心判断
今天网页和 App 都可以使用系统字体、Web Font 或品牌字体。真正需要判断的是：字体是否易读、不同字重是否齐全、中英文混排是否稳定、加载成本是否可接受、系统放大字号后布局会不会崩。Apple 当前 HIG 也强调应优先保证可读性，减少过多字体混用，并让布局适应用户调整文字大小。
“像素级还原”不应该等于固定尺寸
设计稿与开发一致当然重要，但现代界面不是一张静态截图。窗口会缩放、手机会横竖屏切换、折叠屏会改变可用区域、用户会放大字体。真正的交付目标应该是“规则一致”，而不是在某一个画板宽度下每个像素都不动。
一套完整的 UI 界面设计规范，应该分成 6 层
如果要让规范可以长期维护，可以把它拆成从基础到页面的六层。
| 层级 | 应该定义什么 | 典型内容 |
|---|---|---|
| 1. Foundations | 视觉基础 | 颜色、字体、图标、栅格、圆角、阴影 |
| 2. Tokens | 可复用设计决策 | color-primary、space-200、radius-md |
| 3. Components | 高频组件 | 按钮、输入框、下拉、卡片、弹窗、导航 |
| 4. Patterns | 组合交互模式 | 搜索、筛选、上传、登录、空状态、表单提交 |
| 5. Layouts | 页面与响应式规则 | 列表页、详情页、后台工作台、多栏布局 |
| 6. QA | 验收规则 | 无障碍、状态完整性、跨尺寸、开发一致性 |
2025 年 Design Tokens Community Group 发布了首个稳定版 Design Tokens 规范，用于在不同工具与平台之间交换颜色、尺寸、字体等设计决策。它不是 W3C Recommendation，但已经说明一个趋势：设计规范正在从“视觉文档”转向更结构化、可被设计工具和代码共同使用的数据。
布局规范：不要从“固定尺寸”开始，而要先确定信息关系
好的布局规范先解决三个问题：什么最重要、哪些信息属于一组、在空间变化时怎么重新排列。
- 使用统一的间距尺度，而不是每个页面随手写 13px、17px、23px。4px 或 8px 作为基础步进都很常见，但不是必须遵守的行业标准。
- 同类信息保持对齐和一致的容器边界，减少不必要的视觉起点。
- 先规定内容的最小/最大宽度、栅格和断点逻辑，再决定具体页面怎么排。
- 不要只设计 375px 手机和 1440px 桌面两个画板，中间尺寸、横屏、分屏和大字号都需要检查。
Android 2026 年的官方设计指导已经把 adaptive design 作为默认思路，强调界面应根据窗口尺寸重排、显示或改变呈现方式，而不是只针对“手机竖屏”制作一套固定布局。Apple HIG 同样强调布局需要适应窗口、方向、Dynamic Type、语言和不同设备。
字体规范：不要只写字号，要定义完整的文字角色
很多 UI 规范只有“标题 24、正文 16、辅助 12”，实际开发很快就会失控。更合理的方法是先定义文字角色，再为每个角色规定字号、行高、字重和颜色。
| 角色 | 用途 | 建议关注 |
|---|---|---|
| Display / Hero | 营销页或关键数据 | 少量使用，避免挤压内容 |
| Heading | 页面与区块标题 | 层级稳定，不要跳级 |
| Body | 主要阅读内容 | 可读性优先，保证合理行高 |
| Label | 按钮、表单、Tab | 短、明确、动作一致 |
| Caption | 时间、注释、辅助信息 | 不能小到影响阅读 |
字体规范还需要测试三件事：中文和英文混排、最长文案、系统文字放大。WCAG 2.2 要求网页文本在放大到 200% 时不应丢失内容或功能。对 App，平台的动态字号机制也应在设计阶段考虑，而不是开发完再补。
颜色规范：先保证信息能被看懂，再谈品牌感
颜色系统最容易出现的问题不是“不高级”，而是状态含义混乱、对比度不足，以及只靠颜色传达信息。
- 同一种颜色尽量保持相同语义。例如红色已经表示错误，就不要同时拿来表示普通可点击文字。
- 错误、成功、警告不能只靠红绿颜色区分，最好同时有图标、文本或形状变化。
- 浅色模式和深色模式应分别验证，而不是简单把背景翻成黑色。
- 品牌色可以保留个性，但文字、图标和控件仍要满足可读性。
W3C 的 WCAG 2.2 对普通文本的最低对比度要求为 4.5:1，大号文本可为 3:1；用于识别控件和状态的非文本视觉信息通常也需要至少 3:1 的对比度。这个数字比“看起来够清楚”更适合作为验收依据。
组件规范：真正需要定义的是“状态”，不是一张漂亮的按钮图
一个按钮至少可能有默认、悬停、按下、聚焦、禁用、加载等状态。输入框还会增加填写、错误、成功、只读、自动填充等情况。
如果组件库只展示默认状态，开发一定会在缺失的地方自行补规则，最终导致同一个产品出现不同的 hover、focus 和 disabled 样式。
每个高频组件至少应该说明：尺寸、内边距、图标规则、文字规则、状态、可交互区域、键盘行为、错误反馈、响应式变化，以及哪些场景禁止使用。
触控和键盘：尺寸标准不要混在一起理解
很多文章会直接告诉设计师“按钮必须 44px”或“点击区域必须 48px”，但不同平台使用的单位和标准并不一样。
| 场景 | 当前可参考标准 | 怎么理解 |
|---|---|---|
| Web / WCAG 2.2 AA | 目标尺寸至少 24×24 CSS px（存在例外） | 这是无障碍最低要求，不代表最佳体验 |
| Android | 触控目标建议至少 48×48 dp | 可视图标可以更小，但可点击区域要足够大 |
| iOS / iPadOS | Apple HIG 默认控件尺寸 44×44 pt，当前列出的最低控件尺寸为 28×28 pt | 设计时还要保证控件间距，避免误触 |
因此，更稳妥的规范不是给所有平台写一个数字，而是根据产品平台建立自己的最小交互尺寸，并明确“视觉尺寸”和“可点击区域”可以不同。
Web 产品还必须规定键盘焦点。WCAG 2.2 新增了对焦点不被遮挡、焦点外观和目标尺寸等要求。设计稿里最好直接给出 focus 状态，不要让开发浏览器默认样式后再临时处理。
异常状态：真正成熟的 UI 规范，要设计“事情不顺利时”
新手最容易只设计正常流程：有数据、网络正常、用户输入正确、接口立即返回。上线以后真正拉开体验差距的，往往是异常状态。
- Loading：用户要等多久，是否需要骨架屏，能否取消。
- Empty：没有内容时告诉用户原因和下一步，而不是只放一张插画。
- Error：说明发生了什么、是否可恢复、怎样重试。
- Offline：网络断开时哪些内容还能看。
- Permission：没有权限时是隐藏、禁用还是解释原因。
- Long content：超长标题、超长用户名、翻译后文字变长怎么处理。
这些状态应该进入组件或交互模式库，而不是留到测试阶段发现一个补一个。
设计系统不要追求“大而全”，先解决重复问题
很多小团队还没稳定产品结构，就先花几周做几十页 Design System 文档，最后没人维护。更实际的顺序是：先找重复出现的设计决策，再沉淀 Token 和组件。
1. 先统一颜色、字体、间距、圆角这些基础 Token。
2. 整理项目里使用频率最高的 10～20 个组件。
3. 补齐组件状态和使用边界。
4. 把搜索、筛选、表单、弹窗等重复流程整理成 Pattern。
5. 最后再做复杂页面模板和跨产品规范。
设计系统的价值不是“看起来专业”，而是减少同一个问题被重复设计和重复实现。Google 的无障碍指南也提醒，即使使用成熟组件库，也不能默认组件一定适合自己的环境，仍需要实际测试。
UI 设计流程：更合理的版本
1. 明确业务目标和关键任务：先知道用户要完成什么，不要从视觉风格开始。
2. 梳理信息架构和关键流程：确认页面关系、入口、返回路径和异常分支。
3. 用低保真原型验证结构：快速发现流程问题，不要过早投入高保真。
4. 建立 Foundations 和 Tokens：颜色、字体、间距、圆角等先统一。
5. 用组件搭建高保真界面：减少页面之间的自由发挥。
6. 补齐响应式、状态和无障碍：测试不同尺寸、键盘、触控和文字放大。
7. 与开发一起完成设计交付：交付规则、变量、组件、状态和行为，而不仅是截图标注。
8. 上线前做 Design QA：在真实环境核对布局、文案、状态、无障碍和边界情况。
设计交付：开发真正需要的不是“更多标注”，而是更少歧义
过去设计交付经常依赖大量红线图：这个间距 16px、那个按钮 40px。现在设计工具和前端框架都能读取更结构化的信息，人工标注反而应该减少。
一个可执行的交付包至少包含：页面、组件来源、Token/变量、组件状态、响应式规则、交互说明、异常状态、资源文件、文案规则和验收条件。
如果团队已经在设计工具和代码中使用变量，最好让 Token 名称尽量语义一致，例如 `color-text-secondary`、`space-300`，而不是设计里叫“灰色2”，代码里又叫 `#667085`。这也是 Design Token 标准化真正想解决的问题之一。
常见错误：规范很多，但产品还是不统一
- 只规定视觉，不规定交互状态。结果是默认态统一，hover、focus、error 全部不同。
- 把设计稿尺寸当规则。真正应该统一的是间距体系、容器逻辑和响应式行为。
- 组件做得太细。为每个业务页面都新建一个按钮变体，最后组件库比页面还难维护。
- 忽略长文案和国际化。中文正常，英文或德文一上线就溢出。
- 无障碍放到最后做。颜色、层级、组件结构已经定型后再补，成本会明显更高。
- 规范没人维护。组件已经改了三版，文档还是旧截图，团队自然不会再信规范。
一份可以直接使用的 UI 设计检查清单
- 页面是否有明确的第一视觉层级和主要操作？
- 颜色是否使用统一 Token，而不是页面里随手新增？
- 正文文字和背景对比度是否足够？
- 所有关键组件是否包含 hover / pressed / focus / disabled / loading / error 等必要状态？
- 可点击区域是否符合目标平台的交互尺寸要求？
- 只使用键盘能否完成 Web 的核心流程？
- 不同窗口宽度和横竖屏下，信息是否仍然完整？
- 文字放大或文案变长后，是否出现遮挡、截断和按钮溢出？
- 空状态、错误状态、权限不足、网络异常是否有处理？
- 设计工具中的组件与代码组件是否能对应？
- 开发完成后是否做了真实环境 Design QA，而不是只对截图？
FAQ
UI设计规范一定要使用 8px 网格吗？
不一定。8px 是很常见的间距基础，但不是行业强制标准。4px、8px 或其他尺度都可以，关键是规则足够少、可复用，并能覆盖目标设备和组件尺寸。
网页按钮最小尺寸应该是多少？
如果从 WCAG 2.2 AA 的最低要求看，指针目标通常至少应达到 24×24 CSS px，但存在间距等例外。实际产品通常会设置更舒适的交互区域，不应把 24px 当作推荐按钮高度。
iOS按钮是不是必须44×44pt？
不能简单理解成“所有按钮视觉都必须 44×44pt”。Apple 当前 HIG 将 iOS/iPadOS 默认控件尺寸列为 44×44pt，同时列出 28×28pt 的最低控件尺寸，并强调控件之间要有足够间距。设计时还需要结合具体组件和可点击区域判断。
UI设计和UX设计到底有什么区别？
UI 主要负责用户能看到和操作的界面表达，包括视觉层级、组件、状态和反馈；UX 的范围更大，还包括用户研究、流程、信息架构、服务体验和整体任务完成质量。实际项目里两者并不是完全分开的岗位边界。
小团队需要做完整Design System吗？
通常不需要从“大而全”开始。先建立颜色、字体、间距 Token，再整理高频组件和关键 Pattern，等产品稳定后再扩展。这样更容易被团队真正使用。
无障碍是不是只有政府或大型产品才需要做？
不是。对比度、焦点、触控尺寸、文字放大、错误提示这些无障碍要求，本质上都会改善普通用户的使用体验。是否需要达到某个法律或行业合规级别，要根据产品所在地区和业务场景单独判断。
UI设计完成后还需要做Design QA吗？
需要。静态设计稿无法覆盖真实字体渲染、浏览器差异、接口数据、长文案、加载状态和响应式变化。Design QA 的作用就是在真实产品里确认“规则是否真的被实现”。
总结
一套真正有效的 UI界面设计规范，重点已经从“统一颜色、字号、按钮”转向“统一设计决策和产品行为”。视觉基础仍然重要，但它只是第一层。
如果要从零建立规范，最值得优先做的是：统一 Token，整理高频组件，补齐状态和响应式规则，把无障碍作为设计条件，并在开发完成后做真实环境 QA。这样得到的规范才不是一份只在设计工具里好看的文档，而是一套能让产品持续保持一致、可用和可维护的工作方式。
