设计合同最容易出现争议的地方，不是总价，而是“交付什么”没有被定义清楚。“一套UI设计”并不是完整的交付标准，可能只包括几张主页面，也可能覆盖需求分析、原型、视觉、交互、设计规范和开发协作。合同应把每项成果拆开描述，并明确页面范围、使用端、文件形式、完成标准及不包含的内容。
先写清交付层级
如果包含需求分析，应明确是否交付用户角色、功能梳理、信息架构和流程分析；如果包含原型设计，应说明是低保真还是高保真，是否包含可点击演示、页面跳转和交互说明。原型解决的是页面结构与业务流程，不能默认等同于最终视觉稿。
视觉设计部分应列出具体页面和状态，而不是只写“完成全套UI”。至少要确认首页、列表、详情、表单、个人中心等页面是否包含，以及登录失败、网络异常、无数据、加载中、权限不足等异常或空状态是否纳入范围。商城、内容平台和企业管理系统的页面数量相近时，因业务角色和状态不同，工作量也可能完全不同。
文件与协作必须单列
合同应明确交付视觉稿、原型文件、设计源文件、组件库、切图、开发标注、动效演示和设计规范中的哪些项目。设计规范最好写明是否包含色彩、字体、间距、图标、按钮、弹窗和卡片等组件规则。否则，服务方交付几张效果图，也可能被解释为已经完成项目。
如果项目涉及安卓和iOS差异、平板或横屏适配、后台管理端，也应逐项列出。开发阶段是否提供答疑、是否参与评审、反馈响应范围，同样不能依靠口头约定。
修改与验收要有边界
“修改到满意”缺乏可执行性。合同应明确每个阶段包含几轮修改，修改是否限于原需求，新增页面、改变业务流程或增加动效如何计费，评审延迟是否顺延交付时间。验收则应以页面清单、状态清单和文件清单为依据，由指定人员统一确认。
一份合格的设计合同，核心不是把内容写得复杂，而是让双方能够回答同一个问题：项目结束时，具体要交哪些页面、哪些状态、哪些文件，以及哪些工作仍需另行报价。只有交付物可核对，价格和进度才真正具备可管理性。
