Web 设计规范把团队反复使用的设计决定写成可复用、可实现和可检查的规则。它既包括色彩、布局与排版，也包括响应式、可访问性、交互反馈、性能、兼容性和安全相关的界面约定。规范的价值是让同一条业务流程在不同页面、设备与状态下仍然清楚一致。
开始前先写明适用产品、使用端、目标浏览器和维护人，再选一条正在开发的流程贯穿检查。例如一个“申请资源”流程，需要列表、详情、填写表单和提交结果，足以检验多数基础规则。先把这条流程说明白，再逐步扩展到其他页面。
1. 色彩和品牌：为颜色定义用途
色彩可以传达品牌和信息，但规范不能只有一排色块。记录主要文本、次要文本、页面背景、边框、主要操作和错误等语义角色，再为每个角色指定实际颜色与使用条件。品牌主色并不适合承担所有提示，错误也不能只靠红色表达。
在申请表单中，“提交”使用主要操作色，“取消”保持次级层级；字段出错时同时呈现颜色、错误文字和对应位置。明暗主题保持语义关系，而不是把每个颜色简单反相。文字与背景的对比度按实际组合检查：WCAG 2.2 AA 对普通文本通常要求至少 4.5:1，大文本通常至少 3:1，具体条件与例外参考官方标准。
需要把颜色传给研发时，可以采用设计 Token 命名方法，让同一用途在设计和代码中有对应名称。渐变色板可用于寻找视觉方向，但不能代替状态与对比度规则。
2. 布局和导航：写清区域关系与当前位置
使用网格、对齐和间距建立稳定布局。列宽和跨列卡片宽度可以按栅格计算方法确定。规范应说明页面容器、侧栏、主内容与操作区的关系，哪些固定、哪些自适应、内容过长时如何处理。不要只交付一张画布尺寸图，让研发猜测实际页面的伸缩方式。
导航标签用读者熟悉的任务名称，保持位置和选中状态一致。在申请流程里，用户应知道自己位于申请列表还是详情页，以及如何返回。底部导航适合某些移动任务，但不应因为有现成模板就直接搬到复杂桌面后台。
3. 响应式设计：以内容变化决定布局
响应式设计通过灵活布局、图片和媒体查询适应不同视口。断点应来自内容什么时候开始拥挤，而不是只罗列手机、平板、电脑三个设备名。导航放不下时如何收起，双栏表单何时转为单栏，操作按钮是换行还是折叠，都应在规范中说明。
使用长部门名称、长按钮文案和更多筛选条件测试。表格确需横向浏览时，让它在自身区域滚动，不让整个页面横向溢出。移动端还要检查软键盘、底部安全区与横屏布局，详细方法可接着看响应式设计基础。
4. 字体和排版：保证真实内容可读
文字规范至少记录字体顺序、字号、字重、行高和使用场景。标题、正文、辅助说明和数据各自承担不同角色，不能只用“18 号字”“灰色字”命名。中文、英文、数字与单位混排时，要检查行高、断行和对齐是否稳定。
规范应覆盖指定字体无法加载时的回退效果、按钮长文案、表格数字和多行提示。不要把重要文案全部做进图片，避免缩小后无法阅读，也不利于文本放大和辅助技术使用。用实际业务内容检查，比“标题文字”和“内容内容”更容易暴露问题。
5. 可访问性和可用性：让任务能够完成
键盘用户需要知道焦点在哪里，能够依次到达主要操作，并在关闭弹窗后回到合理位置。设计稿要标明焦点样式、顺序和弹层行为，研发再以相符的语义与组件实现。只给按钮加亮色边框，不能代表整条键盘流程已经可用。
表单标签应在填写后仍能识别；错误提示关联到具体字段并说明修正方法。有信息的图片描述关键信息，纯装饰图不重复朗读，复杂图表旁提供文字解释。完成组件后再走一遍完整任务，确认放大文字、键盘操作和错误恢复不会阻断流程。
更细的检查可参考WCAG 设计检查清单。某个按钮或色组通过检查，只能证明该项结果，不能外推为整个网站已经符合标准。
6. 图像和多媒体：明确比例、裁切与替代内容
为封面、内容插图、头像和产品截图分别定义展示比例、最小可读尺寸与裁切规则。重要人物、产品主体和截图中的关键状态不能在窄屏裁切后消失。图片应预留合适尺寸，减少加载后把正文向下推移。
选择当前站点支持的图片格式与压缩方式，并查看最终导出文件，不以“格式较新”代替实际清晰度检查。首屏关键图与下方补充图采用合适的加载策略。视频提供播放控制及所需字幕，关键说明同时保留为可读取文本，不让信息只存在于自动播放内容中。
7. 交互和反馈：说明操作前后会发生什么
按钮、链接和输入框需要清楚的可操作外观，也需要对应状态。提交前能否操作、提交中是否允许重复点击、失败后输入是否保留，都应写在组件或业务页面旁。不能只画成功状态，把接口异常留给开发临时决定。
以申请表单为例：未填写必填项时指出具体字段；提交中说明正在处理；失败后明确是否保留内容及如何重试；成功后给出查看申请的入口。文案必须与实际实现一致，不能写“内容已保存”却没有保存机制。动效用来解释变化，持续循环或过长过渡会干扰任务。
8. 页面加载速度：把性能要求落实到资源和页面
图片尺寸、字体、脚本、数据量和缓存都会影响页面体验。设计阶段可以明确资源职责与展示方式，研发阶段需要在运行页面中测量加载、交互响应和布局稳定性。静态截图好看，并不能证明页面运行流畅。
先选真实用户会访问的代表页面，约定设备、网络和数据条件。列表变长后是否卡顿，筛选时是否重复请求，图片加载后布局是否跳动，都要实际检查。问题记录写到资源或状态，例如“窄屏首屏下载了桌面大图”，比“页面太慢”更容易处理。
9. 浏览器兼容性：保留需要验证的组合
根据用户环境确定浏览器与版本范围，分别检查字体、布局、表单、滚动、弹窗和关键交互。Chrome、Safari、Firefox、Edge 的表现不能仅凭其中一个浏览器推断。使用某项 Web 能力前，应核对目标环境的支持情况，并为必要场景准备回退。
验收时固定视口、字体和测试内容，再对比预期与实际。可按设计稿视觉回归方法区分内容差异和布局问题。记录“申请详情，窄屏，长部门名称使按钮被推出屏幕”，后续才能复现并确认修复。
10. 安全性：划清界面规则与系统责任
设计需要明确权限不足、敏感信息遮蔽、会话过期、退出和危险操作确认的界面表现。例如没有编辑权限时，解释用户仍能做什么以及如何申请；删除不可恢复内容时，提供明确对象与后果，避免只写“确定吗”。
身份认证、服务端访问控制、传输和存储保护由研发与安全方案落实。隐藏一个按钮不能替代权限校验，锁形图标也不能证明数据安全。规范中记录这些依赖，确保界面承诺与系统行为一致。
把十项要求整理成一组可以交付的设计
在 Pixso 中，为基础样式、组件、业务页面与待确认问题建立清晰区域。用同一申请流程展示正常、填写错误、提交中和结果等状态，为图层、组件与规则采用稳定名称。让研发能够找到当前版本和对应说明，而不是从多个“最终稿”里猜测。
交付记录可以使用“页面、状态、环境、预期、实际、责任人”六个字段。规范更新时注明新增、调整与废弃内容，并确认受影响页面是否跟进。需要更细的组件记录时，参考组件规格与开发验收方法。
先从在 Pixso 整理第一组页面规范开始，让颜色、布局、交互与实现要求围绕同一任务对齐，再扩展到整个产品。
