如果小小的界面修改也要等待设计稿

“只是在设置菜单里加一个帮助项而已。”即使作为 PM 提出小改动，为了展示改动后的样子，有时也得向设计师说明并等待设计稿。脑海中明明是简单的修改，却多了一件需要请别人完成的事。

如果能在会议前亲自做出那个界面呢？与其用语言说明位置，不如让同事点一点并给出反馈。

Figma Make 的节省时间实验显示，PM 可能可以亲自把这些小改动做成草稿。让 100 名 PM 和产品设计师完成相同任务后，可使用 Make 的 PM 组在三项任务中的累计完成时间缩短了 23%。让我们通过实际任务看看差异出现在哪里。

交给 100 人的工作有三项

Figma 招募了 50 名产品设计师和 50 名 PM，随机分配至可使用 Make 的组别和不使用 AI 的对照组。两组针对同一个社交媒体界面完成了三项修改任务。在所有参与者中，使用 Make 的条件下三项任务的累计完成时间减少了 20%。

实验任务PM产品设计师
将浅色模式改为深色模式时间显著改善无显著差异
在设置菜单中添加帮助时间显著改善无显著差异
创建打开评论面板的交互无显著差异时间显著改善

这里的“无显著差异”并不表示效果恰好为零，而是指仅凭公开的实验结果，未能在统计上确认时间改善。

适合 PM 的是范围较小的界面改动

PM 显著节省时间的任务是切换深色模式和添加帮助菜单。相反，在最复杂的评论交互中，并未确认同样的改善。

因此，首次尝试最好选择改动范围和完成条件都明确的工作。例如，新增一个菜单项或更改特定界面状态，然后将可供同事点击体验的草稿与设计请求一同交付。PM 也能把过去只能用语言说明的改动方案准备成可见的形式，是这一结果中值得借鉴的用途。

不过，23% 并不意味着 PM 的所有设计工作，或等待设计师的所有时间都减少了。这是对 50 名 PM 完成三项任务的累计完成时间进行的比较，本研究并未证实产出质量、协作效果或项目上线速度。

对设计师而言，需要点击才能传达的交互值得作为候选

产品设计师出现显著时间改善的任务，是打开评论面板的交互。对于熟悉的颜色切换和菜单修改，并未确认同样的差异。

可以优先选择仅靠静态设计稿难以说明的行为，例如点击按钮后打开面板，或根据选择改变界面。与其把所有简单修改都交给 Make，不如选择各角色中表达耗时较长的工作。

首次应用的标准

PM 可以从范围较小的界面改动开始尝试，设计师则可以从可点击的交互开始。这个标准只是从三项任务中发现的模式，因此实际团队应在相同完成条件下与手动工作进行比较。

现在就试着做：点击打开的帮助菜单

如果是第一次使用，请从不带现成设计的小界面开始。以下步骤并非复现 Figma 实验的方法，而是为确认 Make 的用途而设计的练习。

  1. 确认使用条件。 请在Figma Make 开始页面注册或登录。可用范围因套餐和席位而异，发送提示词会消耗 AI 积分。
  2. 打开新的 Make 文件。 在 Figma 文件浏览器中选择 Drafts（草稿）→ 右上角的 Make。
  3. 将以下请求粘贴到 AI 聊天中，然后点击 Send。 第一次练习时，只请求一个界面和一种行为。清楚写明要制作的对象、所需元素、行为以及要排除的功能即可。

请创建一个简单的设置界面，让同事可以在会议中点击体验。菜单只包含“账户”“通知”和“帮助”三项。点击“帮助”时，在右侧打开说明面板；点击面板中的“关闭”时，再次关闭该面板。请让我无需实际注册或连接外部服务，也能验证这一行为。

第一次成功的标准不是界面是否漂亮，而是帮助是否能打开并再次关闭。 在生成后出现的交互式预览中，依次点击“帮助”和“关闭”。如果没有打开，请具体说明一个失败的行为，例如：“点击帮助后面板没有打开。请修复菜单和面板之间的连接。”

扩展到实际界面时，可以将想要修改的 Figma 画框粘贴到 Make 聊天中，并通过“保留附件界面的其余结构，只添加帮助菜单”来限定范围。官方文件创建指南中也可以查看导入现有设计的方法。

节省的时间要在修改完成后计算

实际工作中应关注的数字，不是第一个结果出现的时间，而是直到完成符合需求的草稿为止的总时间。请记录编写请求、等待生成以及修复失败行为所花的全部时间。还应记录每条提示词消耗的 AI 积分。积分消耗量会因模型、任务复杂度和需要处理的上下文量而异。

比较时，应对手动工作和 Make 工作采用相同的完成条件。对于本次练习，标准是：“点击帮助会打开面板，点击关闭后面板消失。”如果同事再次修改了结果，也应把返工时间计入其中。

这项实验展示的最实用起点很明确。如果你是 PM，请先亲自将一个小而明确的改动方案做成可运行的草稿。然后再确认它是否也缩短了实际工作中的准备时间。