开发拿到一张标满像素的设计稿，仍然可能不知道输入框在窄屏上如何变化、长文案能否换行、错误发生后提示放在哪里。UI设计标注的目标，是让组件的外观、行为和边界条件可以被一致实现。尺寸只是其中一部分，完整交付还需要状态、规则和验收条件。
本文以一个“搜索订单”输入组件为例，整理可以直接放入交付文件的规格。涉及整个项目的资源组织、沟通和版本管理，可以配合设计交付指南一起使用。开始标注前，可先按原型到UI的交接清单确认页面、状态与业务规则。
从一张静态稿，整理成六块组件规格
开始标注前，给组件一个稳定名称，说明用途和不适用场景。例如“订单编号搜索框，用于按编号检索，不承担全文筛选”。再列出输入内容、外部依赖和主要动作。名称与边界明确，开发和测试才不会把视觉相近的组件当成同一功能。
- 结构：标签、输入区、图标、清除按钮、辅助说明、错误信息之间的关系。
- 尺寸：固定值、最小值、最大值，以及随内容变化的部分。
- 样式：颜色、字体、边框、圆角和阴影对应的设计变量。
- 状态：默认、悬停、聚焦、输入、加载、错误、禁用或只读。
- 行为：触发方式、校验时机、键盘路径和结果反馈。
- 验收：用哪些内容和环境检查，达到什么结果才算通过。
尺寸标注先写规则，再写数值
“宽度320像素”描述的是某张画面；“在父容器内伸展，达到最大宽度后不再增加”才是布局规则。一个组件可以同时包含固定图标、随内容增长的文字和弹性输入区，需要分别标注。下面的数值只用于说明规格写法，实际取值应与项目的组件库一致。
例如输入框高度40、左右内边距12、图标与输入文字间距8。交付时还要补上：错误说明出现后是否增加组件总高度；标签超过一行时是否换行；窄容器内清除按钮是否始终保留；字号放大后是否允许高度增长。只交一个40像素的高度，容易在缩放或多语言场景中裁切内容。
布局采用弹性盒时，应描述主轴和交叉轴，避免笼统写“水平对齐、垂直对齐”。主轴会随排列方向变化；justify-content控制主轴上的空间分配，align-items控制项目在交叉轴上的对齐，align-content处理多行内容的分布，不能当成任何场景通用的垂直居中开关。开发可参考 MDN 的Flexbox 对齐说明确认实现条件。
样式值要能追溯到组件和变量
如果团队已经有颜色、间距和字体变量，优先交付变量名及用途，再附当前取值。比如“错误边框使用错误状态色”，比在十张稿里重复写同一个色值更容易维护。没有变量体系时，也应统一一个规格表，避免设计稿与附件各留一份不同数据。
字体规格至少包括字体族、字重、字号、行高和必要的字间距；还要说明文本过长时换行、截断还是扩展容器。截断方案需要考虑用户如何获得完整内容，不能只在设计稿中用省略号掩盖实际限制。组件涉及段落缩进时，正确的CSS属性是text-indent，不是indent-align；参考 MDN text-indent。
边框与焦点轮廓也要分开。边框通常参与盒子尺寸计算，焦点轮廓用于表达当前交互位置；不能为了接近视觉稿直接删除轮廓。描述轮廓宽度时使用outline-width，并给出颜色、样式与间距要求。最终是否合适，要在键盘操作和不同背景上验证，而不只是查看静态截图。
做一份能解释变化的状态清单
默认与聚焦：默认态让用户识别可以输入；聚焦态要在键盘和鼠标操作下都清楚。占位提示不能取代可持续看到的字段标签，输入内容后用户仍应知道字段的含义。
加载与结果：提交检索后显示“正在搜索”，同时说明是否允许改关键词、取消或重新提交。加载只表达操作进行中，不代表查到结果。无结果应保留关键词并提供修改入口，服务失败则应说明重试路径，这两种状态不能共用一句“暂无数据”。
错误与只读：错误文案写明问题和改法，例如“订单号应包含8位数字”，而不是“输入非法”。只读表示可以查看但不能修改，禁用表示当前不可操作，两者的样式、焦点行为和说明不应混为一谈。若禁用依赖前置选择，用户需要知道怎样满足条件。
给每个状态补上进入条件和退出条件。例如“提交时订单号格式不完整→字段错误；用户修改到合法格式→清除该错误；服务器无响应→请求异常”。仅画红框却不写何时消失，开发往往只能自行猜测。
把设计决策写进交互与文案约定
以搜索框为例，明确按回车和点击搜索是否执行同一动作、清除内容后是否清除旧结果、连续提交时是否保留最后一次查询。搜索结果更新后是否移动焦点，也需要按任务决定。不要无条件把焦点拉到页面顶部，让键盘用户失去当前位置。
动态出现的“搜索完成”“没有找到结果”等状态应能被辅助技术感知。设计标注可以注明“结果提示不抢焦点，但需要被读屏软件获知”，再由研发采用合适的语义实现。W3C 对状态消息的说明，可作为联调时的依据。
有动效的组件还应交代触发、持续时间、结束状态和减弱动效后的表达。不要只写“自然一点”。如果加载动画承担进度含义，应说明进度来自真实数据还是仅表示等待；没有真实进度时，不应设计会误导用户的百分比。
一张规格卡，怎样进入开发交付
把组件实例、规格说明和问题讨论放在能互相定位的位置。组件名称后附版本或更新记录，变更时说明影响的是外观、行为还是数据要求。比如“新增只读态”与“默认高度改变”影响范围不同，不能都归为“微调”。
可以在Pixso中整理组件及其状态画面，配合设计稿说明与团队评审确认规则。能查看或复制的样式信息有助于交付，但业务校验、数据权限、接口调用与异常恢复仍需研发实现和联调。不要把样式代码的复制等同于完整页面已经开发完成。
开发开始前，用一份真实格式的订单号、一段超长文本和一个缺失值共同走读。把发现的问题当场补进规格，比在开发完成后再补一张“最终稿”更容易避免多套理解。组件复用时，引用同一份规格，不要复制出数份无法同步的说明。
标注里保留取舍理由，减少后续反复确认
关键规则旁边增加一句原因，能帮助协作者在新场景中作出一致选择。例如“错误文案占据独立一行，以免遮挡输入内容”“搜索按钮保留文字，因为图标含义对新用户不够明确”。理由不必覆盖每一条视觉参数，但应解释影响任务、可访问性和业务风险的取舍。
对尚未确定的内容明确标记待确认项，包括确认人和截止节点。不要在主稿里使用一个临时值，却只在聊天记录中说“以后再改”。如果缺少真实数据，主动列出需要研发提供的字段长度、错误码和状态清单，避免凭经验设计一套接口永远不会返回的反馈。
联调发现实现与设计不同，也先判断差异来自规则遗漏、技术限制还是错误理解。把最终决定更新回同一份规格，再验证关联组件，避免修正只停留在某一张开发截图上。这样规格才是协作依据，而不是交付后失效的附件。
发布前用这些场景验收
- 内容边界：空内容、最长内容、长英文串和多行错误说明都能阅读，重要操作不会被挤出。
- 尺寸边界：窄容器、常规容器、页面缩放后的布局符合规则，没有靠隐藏溢出来掩盖信息丢失。
- 交互边界：键盘可完成任务，焦点可见且顺序合理，禁用与只读行为符合约定。
- 请求边界：加载、无结果、错误、再次提交有不同反馈，旧响应不会覆盖新的有效结果。
- 变更边界：当前实现对应已确认版本，未完成项记录负责人和复验条件。
UI设计标注做得好，不是每个元素旁边都有尺寸，而是下一位协作者无需猜测关键规则。先选一个高频组件把规格跑通，再扩展到组件库，往往更容易形成稳定的交付习惯。
