1. 认识Figma与原型设计核心概念

1.1 用户场景：谁在使用原型工具？

原型设计工具不再是设计师的专属领地。在产品需求驱动的协作模式下，三类角色每天都与原型工具打交道：

• 产品经理（PM）——在需求评审会上用手绘线框图或 Axure 低保真稿向团队解释功能逻辑，往往因信息密度低、交互不直观而被反复挑战。PM 需要一种能快速搭建可点击原型、直接承载需求描述的工具，让评审从“听我讲”变成“你来点”。
• 交互 / UI 设计师——面对多版本设计稿、混乱的图层命名、反复的切图导出，大量精力消耗在“管理”而非“创造”上。设计师需要一款支持组件级复用、实时协作、自动标注的平台，把时间还给方案打磨。
• 前端开发工程师——拿到设计稿后，常因标注不全、间距不明、交互状态缺失而反复找设计师确认。开发需要一份“可自解释”的原型——点击区域明确、逻辑分支完整、视觉规范可读。

1.2 业务问题：原型设计中的常见痛点

以下四个业务问题在跨职能团队中反复出现，直接拉长产品交付周期：

1.3 用户访谈：挖掘真实需求

在引入或优化原型工作流之前，必须对利益相关者进行结构化访谈。推荐的访谈框架如下：

1. 目标用户画像——谁是原型的主要产出者？谁是主要消费者？（例：PM+设计师 vs 开发+测试）
2. 当前工作流痛点——“你现在用什么工具画原型？最让你头疼的三个环节是什么？”
3. 协作摩擦点——“拿到设计稿后，你通常需要多久才能开始开发？中间要确认几次？”
4. 期望改善的指标——“如果工具能帮你减少 30% 的确认时间，你愿意尝试吗？”

1.4 需求拆解：Figma 核心功能与原型三要素

将用户访谈收集到的需求归类，对应到 Figma 的三大核心能力模块，这也是原型设计的三个基础支柱：

下面是一个常见的设计令牌（Design Token）配置示例，用于在 Figma 中统一管理颜色和间距变量，保证原型与开发规范一致：

{
  "color": {
    "brand-primary":  "#3498db",
    "brand-danger":   "#e74c3c",
    "bg-surface":     "#ffffff",
    "text-primary":   "#2c3e50",
    "text-secondary": "#7f8c8d"
  },
  "spacing": {
    "xs": "4px",
    "sm": "8px",
    "md": "16px",
    "lg": "24px",
    "xl": "40px"
  },
  "border-radius": {
    "sm": "4px",
    "md": "8px",
    "lg": "16px"
  }
}

1.5 方案表达：用 Figma 传达设计意图

原型是产品需求的“可执行文档”。在 Figma 中，方案表达遵循三层递进：

• 低保真线框图（Wireframe）——用矩形、占位符、文字描述页面结构和信息层级，不做视觉修饰，用于快速对齐需求范围。
• 交互原型（Interactive Prototype）——通过连线面板（Prototype Tab）将页面帧连接起来，定义点击、滑动、悬停等交互，模拟真实操作路径。
• 高保真交付稿（Handoff-ready Design）——在低保真基础上加载设计系统（颜色、字体、图标），补全所有状态（加载、空态、错误、边界），导出开发标注。

以下 SVG 框架图直观呈现了从用户场景到交付物的完整原型设计闭环：

1.6 指标验证：原型设计的度量标准

原型是否有效，不能凭感觉判断。以下四个核心指标覆盖了从“可用性”到“协作效率”的评估维度：

1.7 验收标准：原型交付物的检查清单

以下清单用于确认一份原型是否达到“可交付开发”的标准。每一项都对应一个具体的产品需求维度：

• □ 需求覆盖度——原型是否包含了所有用户故事（User Story）中定义的主路径和异常路径？
• □ 交互逻辑完整性——所有可点击元素是否都绑定了目标帧？是否有“死按钮”（点击无反应）？
• □ 状态完备性——每个页面是否覆盖了加载态、空态、错误态、边界态（如超长文本、网络异常）？
• □ 视觉规范一致性——颜色、字体、间距、圆角是否与设计系统（Design System）中的令牌一致？
• □ 标注与导出规范——切图是否按平台（iOS / Android / Web）命名？标注是否包含间距、字号、颜色值？
• □ 评论闭环——上一轮评审中的所有评论是否标记为“已解决”或“已确认推迟”？

1.8 交付物模板：第 1 章输出物

学习完本章后，你应该产出以下两份交付物，作为后续章节的基础输入：