📚 课程目录第4章用户研究与需求分析

4. 用户研究与需求分析

说实话，Figma 入门不难，但真正把它用成「工程化工具」，很多人就卡住了。我见过不少团队，设计稿画得挺漂亮，一到开发对接就乱成一锅粥。问题出在哪？说白了，就是没把 Figma 当成一个「代码仓库」来用。

这一章，我把自己在车载 HMI 项目里踩过的坑、总结出来的套路，全部分享给你。咱们从四个最核心的进阶能力说起。

4.1 组件变体：别再复制粘贴了

你想想看，一个车载仪表盘，光「速度表」就有 3 种布局、5 种颜色模式、2 种字体大小。要是每个组合都单独画一个组件，那得维护多少个？我见过最夸张的项目，一个按钮组件有 40 多个实例，改一次样式要改半天。

组件变体（Component Variants） 就是来解决这个问题的。它把多个相似组件合并成一个「超级组件」，通过属性切换不同的状态。

4.1.1 创建变体的正确姿势

我个人习惯，先画好所有状态，再统一合并。比如一个「车速显示组件」：

布局变体：居中布局、左对齐布局、右对齐布局
颜色变体：日间模式、夜间模式、运动模式
状态变体：正常、警告、故障

选中所有相关组件，右键 → Combine as variants。然后给每个属性起个名字，比如 Layout、Theme、Status。

我的经验：属性命名要跟开发同学对齐。他们用枚举，你就用枚举。别自己发明一套「左1」「左2」这种名字，开发看不懂。

4.1.2 属性类型怎么选

属性类型	适用场景	例子
文本	可自定义文字内容	按钮文字、标签文本
布尔值	开关、显示/隐藏	图标显示、边框开关
实例切换	替换子组件	图标类型、插槽内容
变体	多状态切换	颜色主题、布局模式

嗯，这里要注意：不要滥用变体。如果一个组件有超过 20 种组合，建议拆分成多个独立组件。我在项目里吃过这个亏，一个变体组件属性太多，每次修改都要加载好几秒，团队里的人都快疯了。

4.2 交互组件：让原型动起来

车载 HMI 跟手机 App 最大的区别是什么？交互反馈必须即时、精准。驾驶员没时间等你加载动画。所以，Figma 的交互组件能力，在车载项目里特别重要。

4.2.1 交互组件的核心逻辑

说白了，交互组件就是给组件加上「行为」。比如：

点击按钮 → 切换状态
悬停 → 显示提示
长按 → 触发二级菜单

在 Figma 里，选中组件，右侧面板切到 Prototype，拖拽连线到另一个状态，设置触发条件和动画。

  车载场景特别提醒：交互组件的动画时长建议控制在 150ms-300ms 之间。太短了看不清，太长了驾驶员会分心。我一般用 200ms，配合 ease-out 缓动，手感最自然。

4.2.2 我常用的交互模式

做车载 HMI 原型，我总结了三类高频交互：

状态切换：按钮按下/抬起、开关开/关。用 On click 触发，切换到另一个变体状态。
悬停反馈：触摸屏上虽然没有「悬停」，但鼠标操作时很有用。用 While hovering 触发，显示提示框。
拖拽滑动：音量条、亮度调节。用 While pressing + Drag 实现。

避坑：我曾经在项目里用「After delay」做自动跳转，结果评审时动画卡住了，因为 Figma 的延迟触发在复杂组件里容易失效。现在我只用「On click」和「While hovering」这两种触发方式，稳定得多。

4.3 设计Token管理：让设计与开发说同一种语言

这是我最想强调的部分。很多团队设计稿和代码对不上，根因就是「颜色不叫同一个名字」。设计说「主色蓝 #007AFF」，开发代码里写的是 --color-primary: #007AFF，但 Figma 里那个蓝色叫「蓝色 1」。你说这能不出错吗？

设计 Token 就是给每个设计属性起一个「语义化名字」。比如：

color/background/primary → 主背景色
spacing/padding/small → 小间距
typography/heading/h1 → 一级标题

4.3.1 在 Figma 里怎么落地

我推荐用 Variables 功能（Figma 2023 年推出的）。具体步骤：

打开 Local variables 面板
创建 Color 变量，命名用 color/role/name 格式
创建 Number 变量，用于间距、圆角
创建 String 变量，用于字体家族

// 示例：车载 HMI 颜色 Token 结构
color/
  surface/
    primary    → #1A1A2E
    secondary  → #16213E
    warning    → #E94560
  text/
    primary    → #FFFFFF
    secondary  → #A0A0B0
    disabled   → #555555
  accent/
    blue       → #0F3460
    orange     → #E67E22

我的习惯：Token 命名一定要跟开发同学一起定。我们团队每周五下午开 30 分钟「Token 对齐会」，把新增的 Token 过一遍。这样设计稿出来，开发直接复制变量名就能用，零沟通成本。

4.3.2 Token 的层级结构

层级	说明	例子
全局 Token	最底层的基础值	`color/blue/500` → #3498DB
语义 Token	映射到具体用途	`color/button/primary-bg` → `color/blue/500`
组件 Token	组件级别的覆盖	`button/primary/bg` → `color/button/primary-bg`

为什么要分三层？因为车载项目经常要换主题。比如冬天模式、夏天模式，你只需要改全局 Token 的值，所有组件自动更新。我在一个项目中用这套方法，主题切换从 2 天缩短到 2 小时。

4.4 团队协作与版本管理

Figma 的协作能力很强，但用不好就是灾难。我见过最乱的情况：一个文件里 30 个页面，每个人都在上面改，最后谁也不知道哪个版本是对的。

4.4.1 文件结构规范

我建议这样组织车载 HMI 项目文件：

00-Design System：组件库、Token、样式
01-Screens：所有页面，按功能模块分
02-Flows：交互流程、用户路径
03-Archive：历史版本、废弃方案
04-Reviews：评审记录、反馈截图

每个页面命名用 模块_页面_版本 格式，比如 仪表盘_主界面_v2.3。

4.4.2 版本管理实战

Figma 的 Version History 很好用，但很多人不会用。我分享几个技巧：

每次提交都写描述：别写「更新」，写「修复仪表盘速度表颜色问题，调整间距为 8px」
打标签：重要节点打标签，比如 v2.0-release、v2.1-sprint-3
分支管理：用 Figma 的 Branch 功能做实验性修改，不影响主文件

  我的血泪教训：有一次团队 5 个人同时改一个文件，有人不小心删了「导航栏」组件，我们花了 3 小时才从历史版本里找回来。从那以后，我强制要求：主文件只读，所有人用分支工作。合并前必须经过 review。

4.4.3 协作中的常见问题

问题	原因	解决方案
组件被意外修改	多人同时编辑	用分支，主文件锁定
版本混乱	没有命名规范	统一命名格式，打标签
反馈丢失	评论被淹没	用 Review 页面集中管理
Token 不一致	没有同步机制	每周 Token 对齐会

4.5 本章知识体系

下面这张图，把这一章的核心内容串起来了。你可以把它当成一个「检查清单」，看看自己哪个环节还没做到位。

这四个能力，说白了就是一套「设计工程化」的完整链路。组件变体解决「复用」问题，交互组件解决「行为」问题，Token 解决「一致性」问题，协作和版本管理解决「效率」问题。任何一个环节掉链子，整个项目都会受影响。

我在多个车载项目里验证过这套方法。刚开始推行时，团队会觉得「太麻烦了」，但坚持两三个迭代后，所有人都离不开它。因为你会发现：改一处，全局更新；加一个组件，自动继承所有规范。这才是 Figma 真正的威力。