很多项目的预算表看起来很完整：UI多少钱、前端多少钱、后台多少钱。开工后却发现，没人负责梳理内容，流程没有验证，异常状态没有设计，测试时间被压缩，上线后也没有维护资金。问题不一定是总预算太少，而是预算只分给了“看得见的产出”。
先把项目拆成问题理解、内容与品牌、体验设计、技术实现、质量与上线、维护与风险六个资金池，再根据项目风险分配。越不确定的项目，前期研究和原型比例越高；越成熟、越标准化的项目，执行和开发比例可以提高。
01 先分清项目总预算与供应商合同价
供应商合同价只覆盖合同里的工作。企业项目还可能产生内部人员时间、文案、摄影、翻译、字体图片授权、域名服务器、第三方软件、法务、数据迁移、测试设备、推广和运营等成本。把合同价当成项目总预算，后期任何必要支出都会被认为是“额外加价”。
- 项目总预算：完成业务目标所需的全部投入，包括外部采购和内部资源。
- 供应商合同价：某一团队明确承诺的服务范围和交付物。
- 风险预留：已知存在但无法在立项时精确估算的变更、集成、内容和时间风险。
- 持续预算：上线后的监控、内容更新、优化、系统升级和维护。
02 建立6个预算资金池
资金池 | 包括什么 |
|---|---|
1. 问题理解与策略 | 调研、访谈、数据、现状审计、目标、范围和优先级 |
2. 内容与品牌资产 | 文案、产品资料、图片、品牌规范、翻译与迁移 |
3. UI/UX与原型 | 信息架构、流程、线框、视觉、设计系统、动效和测试 |
4. 开发与集成 | 前端、后端、CMS、接口、数据、第三方服务与部署 |
5. 质量与上线 | 功能、兼容、性能、安全、可访问性、培训和发布 |
6. 维护与风险预留 | 质保、监控、迭代、平台升级、未知问题和范围变化 |
六个资金池不代表每个项目都采购全部服务。它的作用是让企业在删减范围时知道自己删掉了什么风险控制，而不是误以为只有设计和开发两项。
03 三类项目的预算分配示例
以下比例是JVDS用于前期讨论的规划示例，不代表行业平均值，也不直接等于报价。实际项目应根据资产、需求成熟度、技术复杂度、决策人数和上线风险调整。
模型A：品牌升级优先项目
预算方向 | 示例比例 | 重点 |
|---|---|---|
问题理解与品牌策略 | 20% | 品牌审计、定位、架构和核心方向 |
品牌视觉系统 | 35% | Logo、色彩、字体、图形、规范和关键应用 |
数字触点体验 | 20% | 官网、社交、销售模板或产品界面适配 |
落地制作与培训 | 15% | 模板、文件、供应商协作和内部培训 |
测试与风险预留 | 10% | 商标边界、字体图片许可、打样和调整 |
模型B：企业官网与增长项目
预算方向 | 示例比例 | 重点 |
|---|---|---|
策略与需求 | 10% | 目标、受众、竞争、转化路径和范围 |
内容与SEO基础 | 15% | 页面文案、产品资料、关键词和迁移 |
UI/UX设计 | 20% | 结构、原型、视觉、响应式和动效 |
开发与CMS | 35% | 前端、后台、表单、部署和集成 |
测试与上线 | 10% | 性能、兼容、可访问性、重定向和验收 |
维护与预留 | 10% | 上线支持、缺陷、内容调整和未知风险 |
模型C：复杂B端或SaaS产品
预算方向 | 示例比例 | 重点 |
|---|---|---|
Discovery与业务梳理 | 15% | 角色、流程、权限、规则和风险假设 |
UX与服务设计 | 20% | 任务流、信息架构、原型和可用性验证 |
UI与设计系统 | 15% | 高密度界面、组件、状态和规范 |
开发与系统集成 | 30% | 前后端、接口、数据、权限和部署 |
测试、安全与上线 | 10% | 回归、性能、安全、可访问性和培训 |
维护与预留 | 10% | 版本迭代、监控、依赖升级和范围变化 |
04 用阶段控制投入，而不是一次锁死全部预算
Design Council的Double Diamond把过程概括为Discover、Define、Develop、Deliver：先理解问题，再定义问题，随后发展多个方案并测试，最后交付。它不是固定瀑布流程，但提醒企业不要在问题尚未清楚时把大部分预算投入最终制作。
阶段 | 预算买什么 | 阶段结束应得到什么 |
|---|---|---|
Discover | 理解用户、业务、现状和约束 | 研究结论、风险和待验证假设 |
Define | 确定问题、目标、范围和成功标准 | Brief、路线图和版本边界 |
Develop | 探索、原型、测试和迭代方案 | 可验证的方案与技术方向 |
Deliver | 生产、测试、上线和持续改进 | 正式资产、产品、文档和运营机制 |
需求仍不成熟时，可以先签Discovery或概念验证，再根据结果确定后续总价。这样不是把项目切碎加价，而是避免企业在错误方向上一次性承诺全部预算。
05 哪些预算最容易被低估
- 内容准备：产品资料、案例、数据、图片和多语言往往比预期更慢。
- 异常状态：错误、空数据、权限不足、弱网、加载和边界条件也需要设计与开发。
- 内部决策：参与部门越多，评审、修改和协调成本越高。
- 设计系统：复杂产品若不建立组件和规则，后期页面越多越难维护。
- 可访问性：应进入整个生产过程，而不是上线前补救。
- 数据与集成：旧系统、第三方接口、数据清洗和权限是风险集中区。
- 上线与迁移：重定向、SEO、埋点、培训、灰度和回滚不是按下发布按钮。
- 长期维护：内容、浏览器、系统、依赖和平台规则会持续变化。
06 预算不足时，应该先删什么
预算有限时，正确做法是缩小范围，而不是把每个环节都削薄。与其做20个未经验证的页面，不如完成8个关键页面；与其做双端全功能APP，不如先做一条完整核心流程。
处理方式 | 典型内容 |
|---|---|
优先保留 | 核心用户任务、关键业务规则、异常状态、验收、测试和资产归属 |
可以缩小 | 页面数量、应用场景、动效范围、次要功能、非核心语言和高级组件 |
可以后移 | 低频功能、全量报表、复杂个性化、长期应用和非必要集成 |
不宜直接删除 | 安全、隐私、备份、可访问性基础、关键监控和上线回滚 |
07 风险预留应该怎么用
JVDS建议在复杂项目中保留约10%至15%的风险预留作为规划起点，具体比例根据需求成熟度、外部接口、数据迁移、决策人数和时间压力调整。这是编辑建议，不是行业规定。风险预留不是供应商可以自动使用的“额外预算”，每次动用都应说明原因、影响和剩余金额。
08 付款节点不等于成本分配
界达设计现有合同常采用50%启动、30%阶段确认、20%最终交付的里程碑付款结构。付款比例解决现金流和履约风险，不代表成本恰好按50/30/20发生。企业应同时管理预算分配表和合同付款表。
付款节点 | 作用 | 客户应同步拿到 |
|---|---|---|
启动款 | 锁定团队、启动研究和规划 | 需求资料、计划、人员与启动确认 |
阶段款 | 方向或设计阶段确认 | 阶段成果、范围变化和后续计划 |
尾款 | 最终验收和完整交付 | 源文件、代码、文档、账号和交接清单 |
09 一次预算会议需要回答的12个问题
- 项目要解决什么业务问题，不做会造成什么损失？
- 第一版必须让哪类用户完成哪项任务？
- 现有品牌、内容、数据和技术资产有多少可以复用？
- 有哪些不可延期的法规、平台或上市时间要求？
- 哪些工作由企业内部完成，哪些必须外包？
- 是否需要研究、测试和实际用户招募？
- 是否包含移动端、响应式、多语言和可访问性？
- 开发是否涉及后台、接口、数据迁移和第三方系统？
- 上线后谁负责内容、服务器、监控、版本和安全更新？
- 哪些费用不在供应商报价中？
- 需求变化和审批延迟如何影响预算？
- 用什么指标判断项目值得继续投入？
10 常见问题
设计预算占总项目多少合理？
没有固定比例。品牌、官网和复杂产品的风险不同，应先看已有资产、内容、技术和上线责任。
预算应该一次批完还是分阶段？
目标明确、范围稳定可一次批准并按里程碑支付；不确定性高的项目更适合分阶段决策。
可以只做UI，不做研究和原型吗？
可以，但前提是已有可靠需求、流程和信息架构。若基础不存在，省下的前期费用可能转化为返工。
为什么要给上线后留预算？
真实用户、设备、内容和系统环境会暴露设计阶段看不到的问题。没有持续预算，项目会在发布当天失去负责人。
结语
设计项目预算的核心不是把每一分钱平均分给不同角色，而是把资源放在最能减少错误、验证风险和支持交付的环节。范围不清时先买认知，方向明确后再买产出，上线后仍要保留测试、监控和迭代预算。
预算模型可以调整，但不能把内容、研究、异常状态、测试、可访问性、上线和维护当成“有钱再做”的附加项。它们不一定都需要很高比例，却必须在项目开始前被看见。
