01 / WHEN
适用场景
当一个数字产品已有业务方向，但角色、任务、功能关系或界面体验仍不清楚时，软件设计可以先建立可讨论、可确认的产品基础。
- 内部业务工具需要理清操作流程
- 新产品需要从想法形成可讨论原型
- 已有系统结构复杂、使用路径不清
- 开发前需要统一界面与交互依据
先识别使用者、目标任务和关键约束，再进入界面层。
02 / SCOPE
可提供内容
设计工作连接业务需求与界面实现，通过结构和原型降低沟通中的歧义。
- 业务场景、用户角色与目标梳理
- 产品信息结构与功能关系
- 关键任务流程与页面路径
- 低保真或高保真原型
- 界面视觉与交互状态设计
- 响应式或多端适配建议
- 组件与页面一致性说明
- 面向开发的标注和协作说明
具体精细程度取决于项目阶段、技术约束和交付用途。
03 / OUTPUT
典型交付
交付物用于支持范围确认、界面评审和后续开发，而不是只提供无法落地的视觉图片。
- 角色、场景与核心任务说明
- 产品结构和关键流程图
- 主要页面原型与交互路径
- 界面设计和常用状态
- 基础组件与视觉使用规则
- 开发协作所需的设计说明
关键流程应先于大量页面展开，避免在方向未定时过早制作细节。
04 / LIMITS
合作边界
本项以产品结构、原型、界面和交互等设计成果为重点。技术实现需要结合实际系统、接口、数据和运行环境另行评估。
- 后端编码不作为本项默认内容
- 完整系统交付需要单独确认技术范围
- 第三方接口与数据迁移需专项评估
- 长期系统运维不作为默认内容
页面数量、设计精度、修改轮次、源文件与使用范围以项目约定为准。若需要进入开发阶段，将依据确认后的设计和技术条件重新明确责任边界。
设计可以降低开发歧义，但不能替代对技术可行性和数据条件的确认。