UI项目开局常常很顺：需求文档发过去，设计师很快给出首页，大家围绕颜色和风格讨论。到了开发阶段，才发现权限没定义、空状态没画、移动端没确认、组件命名混乱。原本被视为“小细节”的问题，开始影响工期和预算。
以下12个坑并不只属于甲方或供应商。它们更像项目系统里的缺口：谁负责、什么时候确认、用什么证据验收没有被写清。越早发现，越不需要在最后靠加班补救。
01 坑1—3：在问题没说清时过早进入视觉
第一，需求只写“做得高级、简洁”，没有业务目标和核心用户；第二，页面清单代替用户流程，没人说明用户为什么进入、如何完成任务；第三，竞品分析变成截图库，没有判断哪些做法适用。
解决方式不是再开一次审美会，而是先完成目标、角色、关键任务、范围和成功标准。视觉方向应该建立在这些约束之上。
坑 | 表面现象 | 更好的处理 |
|---|---|---|
需求只讲风格 | 反馈变成个人喜好 | 补业务目标、用户与场景 |
页面清单代替流程 | 页面都有，任务走不通 | 先画关键路径与状态 |
竞品只做截图 | 所有方案看起来像同行 | 比较模式、证据与适用边界 |
02 坑4—6：只设计“正常状态”
第四，只画用户操作成功的理想路径；第五，表单没有错误、禁用、处理中和保存失败；第六，多角色产品只展示管理员视角。真实产品的大量体验发生在等待、权限不足、数据为空和操作失败时。
设计阶段应建立状态清单：初始、加载、空、部分数据、错误、成功、禁用、无权限、网络中断和重复提交。不是每个页面都需要所有状态，但每个关键任务都应说明异常如何恢复。
03 坑7—9：反馈与范围失控
第七，所有部门直接在群里零散提意见；第八，方向确认后仍不断增加新页面和新功能，却不调整周期；第九，修改轮次只写次数，没有定义“一轮反馈”是什么。
项目需要一位最终Owner，反馈先内部汇总。新增需求通过变更单说明原因、影响、费用和排期；一轮反馈应是同一阶段的一次完整汇总，而不是每个人随时追加。
风险 | 项目机制 |
|---|---|
多头反馈 | 指定决策人与汇总窗口 |
范围持续增加 | 需求基线＋变更评估 |
修改无限循环 | 阶段确认＋轮次定义 |
前一阶段反复推翻 | 确认记录＋影响说明 |
04 坑10：设计系统做得太晚或太重
小项目完全不建组件，导致相同按钮和表单在不同页面不一致；大项目则可能一开始花数周追求完美设计系统，业务页面迟迟没有验证。
更实际的方法是从核心链路提炼基础样式和高频组件，随着模块扩展逐步补业务模式。系统服务产品，不应成为另一个脱离业务的作品。
05 坑11：交付只有一份“看起来完整”的Figma
页面命名、版本、组件、响应式、交互说明和素材授权没有整理，开发只能通过会议猜。设计源文件也可能仍在供应商私人账号，项目结束后客户无法管理。
交付应包含最终页面、关键状态、组件与规范、原型或交互说明、图片图标与字体来源、可编辑源文件和必要走查。
06 坑12：把开发走查当成“有空再看”
开发实现后，设计师只在最后一天统一检查，发现布局、状态和响应式大量偏差。此时改动成本最高，团队也容易把问题归因于“开发不还原”。
应在基础组件、核心页面和全量页面三个节点走查。问题按阻断、重要和细节分级，先保证任务与信息正确，再修视觉细节。
- 组件阶段：字体、颜色、间距、按钮、表单和表格；
- 核心链路阶段：状态、交互、权限和响应式；
- 上线前：真实内容、边缘页面、浏览器与设备；
- 上线后：数据、用户反馈和未覆盖问题。
07 一张项目体检表，判断风险是否正在累积
如果下列问题有三项以上回答“不清楚”，项目不应继续大面积铺设计。
□ 核心用户和业务目标是否有共同版本？
□ 页面清单是否对应完整任务流程？
□ 方向、范围和修改机制是否书面确认？
□ 关键状态与角色权限是否有负责人确认？
□ 设计组件与开发组件是否建立映射？
□ 源码、字体、图片和第三方素材权利是否清楚？
□ 开发走查和最终验收是否进入排期？
08 真正节省预算的是减少错误决策
压缩发现阶段、跳过状态、减少走查，看起来省了设计时间，却把成本转移到开发、返工和上线后。好的流程并不意味着每一步都做得很重，而是关键判断在最便宜的阶段完成。
项目越小，流程可以越轻；但目标、范围、决策、交付和验收五件事不能缺。
09 第13个隐形坑：没有留下决策记录
项目中很多选择只存在会议记忆里：为什么没有做某功能，为什么保留旧流程，哪个状态由接口限制。几个月后人员变化，团队会重新争论，甚至把有意取舍当成遗漏。
关键决策应记录背景、选项、结论、影响和确认人，附在需求或设计文件附近。它不需要写成长报告，但要让后来者理解“为什么这样做”。
决策记录还能帮助复盘：哪些假设后来被数据推翻，哪些限制已经解除。产品迭代因此不只是不断叠加页面，而是在已有判断上继续学习。
常见问题
UI设计项目最先应该确认什么？
先确认业务目标、目标用户、核心任务、范围和决策人，再进入页面与视觉讨论。
只做几页UI也需要需求确认书吗？
需要，但可以简化。至少写清页面、状态、交付格式、修改轮次、周期和不包含范围。
空状态和错误状态必须全部设计吗？
关键任务必须覆盖主要异常与恢复方式，低风险重复页面可以通过统一规则处理。
设计师是否必须参与开发阶段？
复杂项目建议参与关键走查和答疑，否则设计规则容易在实现中被误解或遗漏。
如何控制客户频繁修改？
建立阶段确认、统一反馈人、明确修改轮次，并对新增或推翻方向的需求进行影响评估。
链接复制成功
