·Use-case·Minds Team

使用合成用户预测试 Figma 原型 | Minds

设计评审只能告诉你对于已经了解产品的人来说流程是否合理。合成受众则能告诉你初次看到该界面的人认为它是做什么的,而这正是设计评审在结构上无法回答的问题。

参与设计评审的每个人都已经清楚该产品的功能。这种共享认知既让评审变得高效,也带来了盲区:评审人员无法抹去既有的认知模型,因此无法像初次接触界面的用户那样看待设计。其结果往往是:流程在内部逻辑自洽,在外部却令人困惑,直到数周后的真实用户录屏中才暴露问题。

将文件或画板链接粘贴到 Minds 中,询问从未见过该界面的受众他们认为这是什么。

初次接触能发现的问题

图标与文案的歧义。 某个控件在团队眼中含义明确,但在其他人看来完全是另一回事。

缺失的入口上下文。 界面默认用户进入时已经了解某些前提,但整个流程从未交代过这些背景。

预期不匹配。 用户预期的主操作结果与你实际构建的不一致。这是代价最昂贵的一类设计缺陷,因为只有在点击发生后才会显现。

未明示的成本顾虑。 用户犹豫不决,是因为他们担心会产生某种承诺(例如扣费、永久更改或公开可见),而设计中对此只字未提。

工作流程

  1. 在“设置 → 集成”中关联 Figma。
  2. 将文件或画板链接粘贴到新建的研究中。
  3. 根据先验知识而非仅靠人口统计学特征来定义受众。“从未用过类似工具的人”与“从竞品迁移过来的用户”对同一界面的解读截然不同。
  4. 先让受众进行直观解读:这是什么、给谁用的、你在这里会做什么。
  5. 接着询问预期判断:做了该操作后会发生什么。
  6. 对比不同人群画像的反馈,只要预期与实际设计不符,就立即修正。

提问顺序很关键。如果先询问主观意见,你得到的往往是客套评价;先要求对方复述理解,你才能发现真实的认知脱节。

如何利用输出结果

理解偏差可以通过修改文案来解决,成本极低。预期不一致需要调整交互,虽然成本稍高,但现在修改远比开发上线后重构要划算得多。未明示的成本顾虑只需在按钮旁补充一行打消疑虑的提示即可。

平均满意度评分给不出任何实质性指导。“有两个人认为点击此按钮会直接立即发布”则能准确告诉你该改什么。

局限说明

合成受众的反应不是真实的观察行为。它们无法衡量任务耗时,找不到小了 3 像素的点击热区,也无法取代亲眼观察真人用户操作受阻的过程。它们的作用是确保当你最终组织真人测试时,面对的是一个已经排除了明显认知缺陷的设计。

在白板工具中构思的设计同样适用此方式,类似的导入逻辑也适用于需求工单,具体可参考 Linear 和 Jira 工作流。

示例 Prompt

请首次查看此界面。它的用途是什么,面向什么人群?你会首先与哪个元素进行交互,为什么?你预期交互后会立刻发生什么?有什么因素会阻止你采取行动?

常见问题

如何将设计导入 Minds?

只需关联一次 Figma,然后将 Figma 文件或画板链接粘贴到输入框中即可。设计稿会直接作为研究上下文的一部分,因此受众是对屏幕上实际呈现的内容作出反应,而不是针对文字描述。

这是可用性测试吗?

不是,两者的区别非常关键。可用性测试观察的是用户在特定任务下的实际行为。而这项测试揭示的是理解程度与心理预期:人们认为这个界面的用途是什么、某个控件有什么功能,以及点击后预期会发生什么。在将设计交付给真人测试之前,这些问题最值得提前排查消除。

针对一个界面我应该提问什么?

询问该界面的用途、目标受众、他们会首先与哪个元素互动及原因、他们预期接下来会发生什么,以及在采取行动前还缺少什么信息。多询问其背后的逻辑原因而非喜好偏好,单纯问“你喜欢这个吗”无法得出任何可供改进的依据。

我可以对比两种设计方案吗?

可以。将两种方案呈现给同一批受众,对比理解出现分歧的地方。细分人群之间的意见分歧往往比平均得分更有价值,因为它通常能揭示哪种方案依赖了新用户所不具备的先验知识。

这能替代真人测试吗?

不能。它的作用是以低成本提前消除显而易见的认知偏差,从而让真人测试环节专注于观察行为细节与边缘用例,而不是把时间浪费在发现某个文案存在歧义上。