APP设计经常被理解成“根据功能清单画界面”，但真正影响用户能否完成任务的，往往是进入方式、流程顺序、输入成本、状态反馈、失败恢复和平台规则。只做视觉没有错，前提是产品和交互已经足够成熟。
采购前最重要的工作，是明确企业需要纯UI执行、完整UX/UI设计，还是包含产品策略和需求定义的服务。三种范围都合理，但不能用同一份交付和价格理解。
01 先区分三种经常被混在一起的服务
服务层级 | 解决的问题 | 典型前提 | 主要交付 |
|---|---|---|---|
纯UI设计 | 建立视觉风格并完成界面视觉 | 需求、流程、原型和文案已经稳定 | 视觉方向、全量界面、基础组件和资源 |
完整UX/UI设计 | 优化信息、流程、交互和视觉 | 业务目标清楚，但体验方案需要设计团队完成 | 流程、原型、UI、状态、组件、测试和走查 |
产品策略 + UX/UI | 明确第一版做什么、给谁用、如何验证 | 新产品、需求不稳定或内部缺少产品能力 | 研究、范围、优先级、产品原型、UI和验证计划 |
如果客户只购买纯UI，供应商不应默认承担产品策略；如果供应商报价完整UX/UI，也不应只交最终页面。范围名称必须对应具体工作和交付物。
02 完整APP UI/UX设计的11个模块
模块 | 主要工作 | 典型交付 |
|---|---|---|
1. 目标与范围 | 业务目标、用户、版本、指标、技术和合规约束 | Brief、范围表、优先级、风险和成功标准 |
2. 用户与场景 | 任务、动机、环境、频率、痛点和证据 | 场景、用户任务、研究发现和假设 |
3. 产品结构 | 功能层级、导航、内容、对象和入口 | 信息架构、功能地图、页面清单 |
4. 用户流程 | 主流程、分支、返回、中断、失败和恢复 | 流程图、规则和异常清单 |
5. 线框与原型 | 页面结构、操作、反馈、输入和可点击验证 | 低/高保真原型、交互说明 |
6. UI视觉 | 色彩、字体、图标、层级、图片和品牌表达 | 视觉方向、全量界面和适配稿 |
7. 状态设计 | 加载、空、错误、权限、网络、成功和业务状态 | 状态清单、组件状态和提示文案 |
8. 设计系统 | Token、组件、模式、资源和命名 | 组件库、文档和版本规则 |
9. 动效与反馈 | 转场、微交互、手势、加载和关键状态变化 | 动效说明、原型或交付素材 |
10. 测试与可访问性 | 任务测试、文字缩放、对比、读屏和触控 | 测试报告、问题等级和修正 |
11. 开发走查 | 标注、资源、答疑、实现核对和上线验收 | 交付包、走查记录和问题清单 |
并不是每个项目都需要完整11项，但每一项必须明确由客户、设计公司、开发公司还是第三方承担。
03 APP设计工作量不等于主页面数量
“25屏APP”可能只统计首页、列表、详情和个人中心，却没有计算登录失败、无权限、加载、空数据、支付取消、支付失败、网络中断、表单校验、键盘遮挡和不同账号状态。实际交付时，状态和组件常常比主页面更能反映工作量。
统计单位 | 说明 | 适合用途 |
|---|---|---|
主页面 | 独立信息和任务容器，如首页、详情、订单 | 快速了解产品规模 |
流程 | 用户完成任务的连续路径 | 评估UX、规则和异常复杂度 |
状态 | 同一页面在不同数据、权限和结果下的变化 | 估算完整度和研发工作量 |
组件 | 可复用的按钮、输入、卡片、列表、弹窗等 | 判断设计系统与一致性工作 |
端别 | iOS、Android、小程序、平板或Web | 评估平台适配和重复工作 |
04 iOS、Android和小程序不是简单换一个尺寸
差异 | 需要考虑 |
|---|---|
导航与系统模式 | 返回、标签、顶部栏、弹窗、分享、权限和系统设置入口 |
设备与屏幕 | 安全区域、键盘、全面屏、平板、折叠屏和横竖屏 |
交互习惯 | 手势、长按、系统选择器、输入方式和触觉反馈 |
权限与隐私 | 请求时机、解释、拒绝后路径、数据删除和隐私声明 |
商店与平台规则 | 账号、支付、内容、用户生成内容和审核要求 |
组件实现 | 平台原生组件、跨平台库、开发框架和可实现性 |
为了节省成本，可以建立共享的品牌和设计Token，再对关键平台模式做差异化，而不是强行让所有端完全一致。
05 哪些项目适合哪种服务范围
项目情况 | 推荐范围 | 不建议 |
|---|---|---|
已有成熟产品和完整原型，只需品牌升级 | 纯UI + 基础组件 + 开发走查 | 重新做大规模研究 |
新功能或体验问题明显 | 完整UX/UI + 核心流程测试 | 直接进入全量视觉 |
从0到1、需求仍在变化 | 产品策略 + 原型验证 + 分阶段UI | 一次性锁定全部页面 |
复杂交易、金融、医疗或多角色 | 完整UX/UI + 风险流程 + 可访问性和合规协作 | 只按页面纯UI |
小程序快速验证 | 聚焦核心闭环的UX/UI + 简化系统 | 复制完整APP所有功能 |
06 每个阶段的交付和验收标准
阶段 | 交付物 | 验收问题 |
|---|---|---|
范围 | 目标、用户、功能、版本和不包含项 | 是否知道为什么做、第一版做什么、谁负责 |
结构与流程 | 架构、页面、流程、状态和规则 | 用户能否完成关键任务，异常是否可恢复 |
原型 | 可点击原型和交互说明 | 关键决策是否在视觉前被验证 |
视觉与组件 | 界面、状态、资源、组件和适配 | 品牌一致、层级清楚、状态完整、开发可复用 |
测试 | 任务、发现、严重度和修正 | 高风险问题是否解决或有明确接受理由 |
研发交付 | 源文件、标注、资源、说明和走查 | 开发能否找到最新版本并正确实现 |
验收时建议选择注册、购买/提交、取消/退款、账号恢复等高风险流程走一遍，不要只随机查看几张视觉稿。
07 这些内容通常不默认包含
- 完整商业咨询、市场规模、商业模式和财务预测；
- 后端规则、数据库、接口、技术架构和代码开发；
- 正式法律意见、资质办理、隐私合规和商店申诉；
- 大规模用户招募、线下调研、差旅和第三方研究费用；
- 全部运营文案、内容生产、摄影、插画和3D制作；
- 品牌Logo、完整VI和市场传播物料；
- 上线后的持续运营、数据分析和新版本设计。
可将这些工作纳入合作，但需要单独确认预算、周期、负责人和验收。
08 开发交付不是“发一个Figma链接”
交付内容 | 最低要求 |
|---|---|
文件与版本 | 最终文件、页面命名、历史版本和已确认状态清楚 |
组件与样式 | Token、组件、变体、状态、使用说明和禁用方式 |
资源 | 图标、图片、字体、动效、尺寸、格式和授权信息 |
交互与规则 | 跳转、手势、反馈、键盘、异常、边界和数据条件 |
响应与适配 | 安全区域、断点、文字长度、多语言和设备规则 |
走查与验收 | 节点、问题等级、修正责任和上线前核对 |
Apple审核要求、隐私说明和平台权限会影响界面和流程。设计与开发应在早期确认可实现性，而不是等到交付后才发现支付、账号或数据使用不符合平台规则。
09 合成情景：为什么“已有PRD”仍需要UX设计
某服务预约APP已有详细PRD和页面清单，客户希望直接做UI。评审原型后发现，取消与改期规则只写在文档中，用户界面没有显示截止时间；支付失败后订单状态也不清楚，服务人员端无法处理异常预约。
项目最终不是推翻PRD，而是先补齐预约、支付、取消和退款四条状态链，再进入视觉。新增的UX工作减少了后续接口与客服争议，也让UI状态数量在报价前变得可见。
该情景由常见项目问题合成，不对应单一客户或已验证业务结果。
10 询价前至少准备这些资料
资料 | 作用 |
|---|---|
产品目标和用户 | 判断第一版任务与体验重点 |
功能或PRD | 了解业务规则和范围成熟度 |
核心流程 | 估算原型、状态和风险工作 |
现有设计/竞品 | 判断继承、重构和品牌要求 |
技术方案和平台 | 判断原生、跨平台和组件适配 |
上线时间和预算 | 决定阶段、优先级和协作方式 |
内部团队与决策人 | 明确产品、开发、审核和反馈责任 |
常见问题
1. 只有需求清单，可以直接做UI吗？
可以，但应先确认清单是否包含流程、状态、异常和平台规则。否则需要把澄清工作加入范围。
2. APP设计一定要做高保真原型吗？
不一定。核心流程和高风险交互需要足够精度验证；简单内容页可以直接进入UI。
3. 设计系统适合小型APP吗？
小项目也需要基础样式和核心组件，但不必建设复杂治理体系。系统深度应与产品寿命和迭代规模匹配。
4. iOS和Android需要两套设计稿吗？
可共享大部分品牌与结构，但关键导航、系统组件、权限和设备差异需要明确。是否全量双稿取决于开发方案。
5. 动效设计通常包含什么？
关键转场、状态反馈、加载、手势和品牌动效。需要写清交互原型、参数说明还是可直接使用的动画文件。
6. UI设计完成后还需要设计师参与吗？
需要至少进行交付答疑和关键节点走查。没有开发协作，最终实现容易在间距、状态、组件和响应式上偏离。
结论：先选择正确的服务层级
APP设计范围没有越多越好。真正成熟的做法，是根据产品阶段选择必要工作，并把每项责任、交付和验收写清。这样既不会为不需要的研究付费，也不会把关键体验问题拖到开发阶段。
APP设计范围诊断
可提交产品目标、主要用户、功能清单、现有原型、目标平台和上线时间，由界达设计判断更适合纯UI、完整UX/UI还是分阶段产品设计。
