用户与任务范围
确认目标用户、关键任务、使用环境和优先级，不让页面清单代替业务理解。
DIRECT ANSWER
先说结论。
完整的 UI/UX 设计交付不只是几张效果图，通常应包含用户与业务流程、信息架构、关键原型、视觉界面、组件与状态、响应式或多端规则、交互说明、素材和开发标注。是否包含研究、品牌、Logo、动效、可用性测试与设计走查，需要在项目范围中单独确认。
01 / HOW TO CHOOSE
先看当前情况，
再选择实现路径。
同一个项目名称可能对应完全不同的工作量。先按用户、流程、系统与风险判断，再比较方案和报价。
| 当前情况 | 建议路径 | 判断依据 |
|---|---|---|
| 业务流程还不清楚 | 先做 UX 与原型 | 先确定用户、任务、信息结构和关键状态，避免直接做视觉后反复推翻。 |
| 已有产品需要改版 | 先做体验与界面盘点 | 结合现有流程、数据和问题，区分必须保留、需要优化和可以重构的部分。 |
| 设计后由其他团队开发 | 强化规范与交接 | 需要完整组件、状态、尺寸、素材、响应式和交互说明，并安排设计走查。 |
| Logo、官网与宣传物料一起做 | 先建立品牌视觉系统 | 统一标志、色彩、字体、图形和使用规则，再适配官网与横竖版物料。 |
02 / BEFORE START
启动项目之前，
准备好这些输入。
资料不必一次完整，但关键责任、现有条件和不可改变的边界需要尽早说明。
信息架构与流程
建立导航、层级、主流程、异常流程和不同角色间的关系。
页面与状态清单
除正常页面外，列出加载、空、错误、无权限、成功、禁用和确认状态。
响应式与多端规则
明确 PC、手机、平板、小程序或 APP 的布局变化和交互差异。
组件与设计令牌
统一色彩、字体、间距、按钮、表单、弹窗、表格等复用规则。
开发交接与走查
确认设计源文件、切图、图标、标注、动效说明、开发答疑和上线前走查。
03 / ACCEPTANCE
把“做完了”，
变成可执行的验收。
验收标准应在开发前确认，并使用真实角色、数据和运行环境验证。
流程完整
关键用户能够从入口完成目标任务，并覆盖错误、返回、中断和权限变化。
状态完整
组件和页面具有真实数据、长文本、空状态、加载和异常状态，不只验收理想效果图。
多端可用
在约定屏幕和输入方式下验证布局、触控区域、焦点、键盘和内容可读性。
可开发可维护
组件命名、变量、素材和交互说明可被开发使用，重复页面遵循统一规则。
04 / RELATED WORK
从指南进入服务，
再参考相近项目。
服务页说明交付能力，项目页展示对应方向的业务和建设内容。
05 / FAQ
围绕真实决策，
继续回答常见问题。
如果您的系统、数据或上线条件不同，可以在沟通项目时进一步确认。
UI 和 UX 有什么区别？
UX 关注用户、任务、流程、信息架构和交互反馈；UI 关注视觉层级、组件、品牌和界面呈现。完整数字产品通常需要两者配合。
只有几张页面，也需要做组件规范吗？
需要与规模匹配的轻量规范。至少统一字体、色彩、间距、按钮、表单和常见状态，避免后续页面出现不一致。
设计稿是否默认包含手机和 PC？
不默认。需要在范围中明确包含哪些终端、关键断点、横竖屏和交互差异。
设计验收能只看是否好看吗？
不能。还应验证流程、状态、可读性、可访问性、多端适配、组件一致性和开发可实现性。
06 / REFERENCES
参考资料。
以下为本指南使用的标准组织、平台或政府机构资料；具体项目仍需结合业务和适用要求确认。
- 01Web Content Accessibility Guidelines 2.2 ↗W3C
用于建立可测试的可访问性、键盘、焦点、触控与内容呈现要求。
- 02Human Interface Guidelines ↗Apple Developer
用于理解 Apple 平台的人机交互与界面设计原则。
- 03Material Design 3 ↗Google
用于参考跨平台组件、布局、交互状态和设计系统组织方式。
GUIDE 04 · NEXT STEP