一套设计稿在展示图里很精致，进入真实产品后却可能出现长文案放不下、错误状态缺失、移动端崩坏和组件无法复用。
判断质量应看真实任务和完整系统，而不是只看首页、Dashboard或几张高保真截图。
01 页面是否服务明确任务
每个页面应有主要用户、目标和下一步。视觉层级要帮助用户判断，而不是平均强调所有内容。
关键操作的位置和文案应与风险相匹配。
02 信息结构是否可扫描
标题、分组、间距、对齐和内容顺序应让用户快速找到重点。复杂页面还需支持筛选、搜索和渐进展开。
空白多不等于清晰，信息密度也不等于混乱。
03 组件与状态是否完整
按钮、输入、表格、弹窗、导航等要有稳定规则，并覆盖默认、悬停、聚焦、禁用、加载、成功和错误。
真实产品还要考虑无数据、权限不足和网络异常。
04 内容与数据是否接近真实
检查最长名称、极端数字、国际化、图片缺失和大量列表。只用理想占位文本的稿件无法证明韧性。
文案也应明确、可执行并保持语气一致。
05 响应式和无障碍是否被设计
不同宽度下不是简单缩小，而是重新排列优先级。键盘焦点、对比度、触控尺寸和辅助标签应进入规范。
可访问性不是上线前一次扫描。
06 设计能否转化为可维护实现
设计Token、组件映射、资源、标注和交互说明应清晰。若每页都有特例，开发还原和后续迭代都会失控。
验收应比较真实产品而不只是Figma。
UI设计10项检查
检查项 | 要看到的证据 |
|---|---|
任务清晰 | 用户、目标、主操作 |
层级合理 | 标题、分组与视觉顺序 |
组件一致 | 规则、变体和状态 |
异常完整 | 错误、空、加载、权限 |
数据真实 | 长文案、极值、大列表 |
响应式 | 多断点优先级 |
无障碍 | 焦点、对比、触控、标签 |
内容质量 | 清楚、统一、可执行 |
开发可行 | Token、组件映射、说明 |
结果验证 | 测试、走查与指标 |
常见问题
UI设计好看就是专业吗？
好看有价值，但必须同时满足任务、完整状态、可访问性和开发可行性。
组件数量越多越好吗？
不是。应覆盖真实复用场景，过度拆分和重复组件都会增加成本。
如何检查响应式设计？
查看关键断点和内容优先级，并用真实设备和极端内容测试。
设计稿需要包含所有错误状态吗？
关键流程和高风险状态必须明确，低风险重复状态可通过系统规则覆盖。
设计师需要懂开发吗？
不必成为工程师，但应理解实现约束、组件逻辑和交付协作。
链接复制成功
