1. 交互描述与评审标准概述

适用场景

交互描述与评审标准贯穿产品设计研发全流程,以下场景必须启动本课程所定义的标准流程与交付规范:

  • 新产品交互方案设计 — 从零开始构建交互体系时,需要统一的描述语言和评审尺度。
  • 跨团队方案评审会 — 设计、产品、开发、测试等多角色协同评审,必须有可对照的标准基线。
  • 交互规范落地与对齐 — 团队内部或跨项目组需要拉齐交互描述的颗粒度和评审通过条件。
  • 设计资产传承与复用 — 交互文档需作为长期资产被后续项目引用,标准化描述是复用的前提。
  • 外部协作与外包交付 — 与外部设计团队或供应商协作时,用本标准定义交付验收边界。

前置条件

学习或执行本章内容前,参与者应满足以下条件:

角色 必备条件 建议经验
交互设计师 掌握至少一种原型工具(Figma / Sketch / Axure) 参与过 2 个以上完整项目
产品经理 能读懂交互稿和流程图 负责过 1 个以上产品模块
开发工程师 了解前端基本交互逻辑 参与过交互方案技术评审
测试 / QA 熟悉用例编写方法 执行过交互相关测试用例
提示: 本章为全课程的总纲,建议所有角色至少通读一遍,重点关注“适用岗位”和“交付物总览”两节,以便在后续章节中快速定位与自己相关的内容。

操作步骤

本章作为课程总览,不涉及具体操作执行,但为整个课程定义了一条四阶段学习路径,后续 29 章均按此路径组织:

  1. 概念建立(第 1–6 章) — 理解交互描述的核心要素与评审标准的底层逻辑。
  2. 描述规范(第 7–14 章) — 掌握结构化交互描述的方法、模板与字段格式。
  3. 评审实操(第 15–24 章) — 按角色演练评审流程,使用检查清单进行模拟评审。
  4. 交付与资产化(第 25–30 章) — 输出标准交付物,建立团队级交互资产库。
路径说明: 四阶段可顺序执行,也可按角色跳过。但“概念建立”阶段所有角色必须完成,否则后续章节的术语和标准无法对齐。

输入输出物

类型 名称 说明 来源 / 去向
输入 产品需求文档(PRD) 包含功能列表、用户故事、业务规则 产品经理提供
输入 用户研究数据 用户画像、场景描述、可用性测试报告 用研团队提供
输出 交互描述文档(IDD) 结构化描述交互方案的标准文档 交互设计师产出,进入评审流程
输出 评审检查清单(RCL) 按角色和维度拆分的评审条目 评审主持人维护,评审会使用
输出 评审报告(RR) 记录评审结论、遗留问题、责任方 归档至项目资产库

其中 交互描述文档(IDD) 的字段结构是本课程的核心模板,后续章节将逐字段讲解。以下是 IDD 的字段骨架预览:

交互描述文档(IDD)字段结构
┌──────────────────────────────────────────────┐
│ 1. 文档头:项目名、版本号、作者、日期        │
│ 2. 交互场景:触发条件、前置状态、用户角色    │
│ 3. 流程步骤:步骤编号、操作描述、反馈说明    │
│ 4. 状态规则:正常态、空态、加载态、错误态    │
│ 5. 交互约束:手势标准、动效时长、边界值      │
│ 6. 评审记录:评审结论、待修复项、确认签字    │
└──────────────────────────────────────────────┘

责任边界

交互描述与评审标准涉及多个角色,各角色的责任边界定义如下:

角色 在描述阶段的责任 在评审阶段的责任 否决权
交互设计师 按标准撰写 IDD,保证字段完整 演示交互流程,记录评审意见 无(需服从评审结论)
产品经理 提供 PRD 与业务上下文 确认交互是否符合需求 可一票否决业务逻辑偏差
开发工程师 不参与描述阶段 评估交互的技术可行性与成本 可对不可实现项提出反对
测试 / QA 不参与描述阶段 从异常覆盖和边界角度提出质疑 无(但意见需记录并回复)
评审主持人 确保描述文档符合标准格式 控制评审节奏,推动结论形成 可终止无效讨论,要求补充材料
边界红线: 交互设计师不得在未经评审的情况下直接将 IDD 交付开发;产品经理不得跳过评审环节直接要求开发按 PRD 实现交互。评审是必经关卡,不可省略。

记录材料

本章学习与执行过程中,需要维护以下记录材料:

  • 个人学习笔记 — 记录对四大核心模块的理解、疑问和案例摘录。
  • 术语对照表 — 整理本章出现的术语(如 IDD、RCL、RR),标注定义与首次出现的章节。
  • 岗位职责速查卡 — 一张 A4 纸列出所有角色在描述和评审阶段的权责,供日常参照。
  • 交付物模板索引 — 记录 IDD、RCL、RR 模板的存放路径和版本号。

异常处理

本章作为总纲,不涉及执行层面的异常;但学习过程中可能遇到以下情况,按对应策略处理:

异常现象 原因 处理方式
对“交互描述”与“交互稿”的概念混淆 二者在团队中常被混用,标准定义不清晰 返回本章“核心概念”节点,对比表格中的定义差异
不理解评审标准的必要性 所在团队长期无标准评审,依赖个人经验 阅读第 3 章“评审标准的价值案例”,结合自身项目复盘
不确定自己属于哪个责任角色 小型团队一人多岗,角色边界模糊 按当前项目中的主要职责定位,选择一个主角色 + 一个副角色
团队尚无 IDD 模板,不知从何开始 标准化程度低,缺乏沉淀 使用本课程提供的 IDD 骨架模板先行试用,第 7 章有完整模板
建议: 如果在学习本章时遇到任何术语理解障碍,不要跳过去,先记录在术语对照表中,然后查阅第 2 章“术语词典”或直接参考下方 SVG 结构图中的节点关系。

验收标准

完成本章学习后,应达到以下验收标准:

  • 能准确说出交互描述与评审标准的四大核心模块及其包含的子项。
  • 能列举至少3 种适用场景,并说明为什么需要标准。
  • 能根据岗位对照表,准确说出自己所在角色的描述责任和评审责任。
  • 能画出本章知识体系的概念结构图(与下方 SVG 一致或更简化的版本)。
  • 能解释 IDD、RCL、RR 三个交付物的全称和用途。
  • 能识别至少2 种异常情况并说明处理策略。
验收方式: 建议采用“自测 + 小组互讲”模式。自测使用本章附带的验收清单逐条打勾;互讲则向另一位角色不同的同事口述本模块内容,对方能听懂即通过。
交互描述与评审标准 — 知识体系全景结构图 交互描述与评审标准 核心概念 课程目标 适用岗位 交付物总览 交互描述定义与规范 评审标准与评估维度 掌握结构化描述方法 建立专业评审能力 交互设计师 / 产品经理 开发工程师 / 测试人员 交互描述文档 (IDD) 评审检查清单 (RCL) 📌 四大模块构成完整知识闭环 概念为基 → 目标驱动 → 岗位落地 → 交付验证