UI设计需求确认书怎么写？页面、功能、交付与修改范围模板

“设计一个管理后台，预计30个页面”看起来已经很具体，真正开始后却可能出现移动端适配、五类角色、导入导出、异常状态和设计系统。双方都没有撒谎，只是“一个页面”包含什么从未被共同定义。

需求确认书应作为合同或报价的范围附件。它不必像PRD一样写完所有业务细节，但必须把目标、边界、交付、责任和变化处理方式写到可以执行。

01 第一部分：写项目目标，不写空泛愿景

目标说明这次设计为什么启动、服务谁、优先解决什么。可以写“重构销售人员创建报价的核心流程，降低重复录入和错误”，而不是“提升用户体验、打造一流产品”。

同时写出衡量方式和不在本期解决的问题。明确“不做”能防止项目在讨论中无限扩张。

02 第二部分：列角色、端和使用环境

同一产品可能有管理员、操作员、审核人、访客和客户，每种角色看到的页面与权限不同。还要说明Web、移动Web、APP、平板或大屏，以及是否需要适配特定浏览器和设备。

如果暂时无法定义全部权限，至少标记待确认项和负责人，不要默认由设计师自行推断。

03 第三部分：页面清单要连到功能和状态

页面名称只是目录。每一项至少记录主要功能、角色、关键状态、是否新设计、是否有现成组件和设计端。重复模板可按类型计数，但复杂页面应单独说明。

将弹窗、抽屉、空状态和错误状态全部按“页面数”收费并不一定合理，但它们必须进入范围。否则静态页面数量看似不变，实际工作持续增加。

04 第四部分：交付物写到文件和状态

明确是否包含信息架构、流程、原型、UI、组件库、响应式、动效说明、开发标注、走查和测试。源文件交付到哪个Figma团队，字体、图片和图标如何处理也应说明。

如果只做UI，不要让客户默认包含PRD、用户研究和前端代码；如果包含设计系统，写清是基础组件还是完整业务系统。

• 最终页面与关键状态；
• 桌面、移动或其他端适配范围；
• 可编辑Figma文件与组件；
• 原型、流程和交互说明；
• 字体、图片、图标与素材清单；
• 开发答疑、走查和验收次数；
• 不包含的研究、文案、开发和运营工作。

05 第五部分：修改机制要定义“一轮”

一轮修改应是甲方对同一阶段的一次汇总反馈。方向确认前允许讨论结构与风格，方向确认后再要求整体推翻，应视为范围变化，而不只是普通修改。

反馈期限、逾期处理、决策人和冲突意见解决方式也要写。修改次数本身不能解决多头决策。

06 第六部分：资料与依赖由谁提供

品牌素材、真实文案、产品规则、接口、数据示例、法律文本和设备信息都可能影响设计。确认书应列出提供方、日期和缺失后的处理方式。

使用占位数据设计复杂表格，后期换成真实长文本和异常数据时很容易破版。至少提供一组接近真实的数据样本。

07 第七部分：周期按条件启动，不只写日期

项目通常从预付款到账、合同生效且关键资料齐备后开始。客户反馈延迟、范围增加、第三方依赖和项目暂停应如何顺延，需要提前约定。

把里程碑写成“原型确认、视觉方向确认、全量设计、开发走查”，比只写最终交付日更可控。

08 第八部分：验收与变更形成闭环

验收依据是确认书中的页面、状态、交付物和适配范围，不应只用“客户满意”为标准。发现缺失先判断是原范围遗漏还是新需求，再决定修复或变更。

每次变更记录内容、原因、影响、费用、周期和确认人。小项目可以用一页表格，重点是留下共同版本。

1. 提出变更并说明业务原因；

2. 设计方评估页面、组件、开发和周期影响；

3. 双方确认费用与新里程碑；

4. 更新需求确认书或附加变更单；

5. 按新范围继续执行与验收。

09 确认书要允许“待确认”，但不能没有截止点

早期项目不可能一次写清全部规则。可以将项目项标为已确认、待确认、假设和不包含，并为待确认内容指定责任人、截止日期及对排期的影响。

例如英文站是否首发尚未决定，可以先完成中文结构，但应约定在视觉扩展前确认；若逾期，则按中文单语范围继续，后续增加按变更处理。

这种写法比假装所有信息都确定更诚实，也比一句“以最终需求为准”更可执行。

常见问题

需求确认书和合同有什么区别？

合同规定总体权利义务，需求确认书更具体地定义项目范围、页面、功能、交付与验收，可作为合同附件。

页面数量还没确定能签吗？

可以先签发现或原型阶段，待范围清楚后确认全量设计；不建议用模糊总价覆盖未知范围。

修改轮次越多越好吗？

不一定。更重要的是决策人、阶段确认和反馈质量。无限修改往往掩盖方向与范围不清。

需求中途改变怎么办？

通过变更流程评估对设计、开发、费用和周期的影响，确认后更新共同范围。

微信确认能代替签字吗？

涉及法律效力应咨询专业人士。项目管理上至少要形成可追溯、双方明确同意的记录。