当事情变乱时，你是什么样的产品设计师？

一个完全不科学的产品设计师性格测验。

有资深人员在你最终设计时留言：“我就是不喜欢蓝色。”没有解释，没有后续，评测四分钟就结束了。你接下来做什么，可能只是习惯，而不是决定。你以前也做过，只是在另一个文件里，关于不同颜色。

大多数“你是哪种类型的设计师？”测验都是按我们喜欢做什么来分组。研究或视觉设计。系统或讲故事。宏观思考或细节打磨。

我更感兴趣的是工作中那些尴尬的部分。项目经理来了，解决方案已经确定。工程部门说不行。研究扼杀了你最喜欢的想法。截止日期变了，也带走了你的计划。

这就是设计师行为截然不同的起点。给六个设计师同样的分歧，一个会开放研究。一个会做另一个原型。一个会让所有人聚在一起。一个会找到真正能发货的版本。

会问我们是否应该这么做。还有一个会悄悄地把整个问题解决，直到大家都还没讨论完。

这些方法不一定更好，但你可能有默认选择。所以选择你真正会做的事，而不是你认为一个非常成熟的产品设计师应该做的事。

十二个问题，大约三分钟。每个答案都有一个符号，所以在你做的过程中保持统计，你收集到最多的符号就是你的结果。

请不要把它带到下一次绩效评估时。

1. 你的项目经理会给你一个完整的解决方案

“我们需要这个弹窗，这里有这四个字段。”

你还没讨论这个问题呢。你怎么办？

• A）问清楚哪些是固定的，哪些是灵活的，哪些必须发货。◆
• B）在谈论弹窗之前，先问清楚我们到底想解决什么问题。●
• C）模拟他们的想法，并提出另一个方向，以便我们进行比较。★
• D）礼貌地反驳。我愿意探讨，但我不想一开始就把解决方案做好。■

2. 工程部说你的设计需要三周时间

他们三天内就能做出更简单的版本。你的反应？

• A）做个更简单的原型。我需要看看我们会放弃什么。★
• B）和工程师坐下来，了解为什么费用高昂。▲
• C）自己处理那些昂贵的部分，看看哪些可以简化而不改变整体流程。✦
• D）开始逐步拆除，直到找到最小但仍能使用的产品。◆

3. 在最终评审中，一位资深人士评论道：

“我们能不能让它感觉更高级一点？”

没有更多解释。你：

• A）解释当前治疗的目标，并询问哪些地方觉得不够优质。■
• B）在旁边尝试两个替代方案。有时候看到它们比辩论更快。★
• C）问问具体哪里对他们不起作用。●
• D）做出调整，带回具体的观点，而不是拖延争论。✦

4. 两个利益相关者给出完全相反的反馈

一个想要更少的步骤，另一个想要更多信息。接下来会发生什么？

• A）让两个人进入同一个对话。▲
• B）找到最小的妥协，解决双方最大的关切。◆
• C）设计两个版本。有时候人们需要看到后果。★
• D）回到用户问题，找出哪个担忧有更强有力的证据支持。●

5. 你在审阅另一位设计师的作品

他们选择了你不会选择的方向，这没什么问题。你：

• A）别管它。不同并不意味着完全错误，设计是有效的。◆
• B）问问他们为什么选择这个，看看理由是否站得住脚。●
• C）放下方向，悄悄地修正那些仍需关注的流程部分。✦
• D）告诉他们你会怎么做不同，并进行权衡的讨论。■

6. 团队已经为同一个决定辩论了30分钟

你开始失去生存的意志了。你怎么办？

• A）问问什么证据能真正改变任何人的想法。●
• B）总结大家的共识，并挑出我们仍然存在分歧的那一点。▲
• C）提出最简单合理的方案然后继续前进。◆
• D）会议后自愿参与竞争方案的原型制作。★

7. 用户调研与你最喜欢的设计相矛盾

你的第一反应是？

• A）好吧。我已经想尝试另一条路了。★
• B）弄清楚设计实际需要修改多少。◆
• C）检查哪些地方失败，以及这种模式是否一致。●
• D）轻微的情感创伤，随后展开了一场相当热烈的讨论，讨论我们哪里做错了什么。■

8. 你被给了一个模糊的简报

“提升预订体验。”你自然而然的起点？

• A）在接触设计前，先和已经有背景的人沟通。▲
• B）开放现有流程，立即开始修正你能改进的地方。✦
• C）探索几个方向，弄清楚简报可能的发展方向。★
• D）开始提问，直到“进步”能体现出来。●

9. 截止日期提前两周

你那美好的计划死了。你先做什么？

• A）围绕新截止日期开始调整流程，先处理明显的削减。✦
• B）让项目经理和工程部门合作，重新定义“完成”的含义。▲
• C）如果剩余范围无法有效解决问题，推迟截止日期。■
• D）确定哪些假设在删减前还需要验证。●

10. 你的设计评审收到了9个人的23条评论

其中一半彼此矛盾。你：

• A）将评论按主题分类，找出哪些分歧需要讨论。▲
• B）解决那些明显是偏好而非产品问题的评论。■
• C）悄悄地处理文件，修正那些你能在不再谈的情况下解决的问题。✦
• D）优先考虑对结果重要的评论，其余的留言。

11. 你的项目经理在周末用AI构建了一个原型

周一则以“基本上是设计”的形式呈现。你：

• A）指出原型尚未解决的重要状态、决策和边缘情况。■
• B）先把它当作一个方向，然后快速做另一个原型再决定。★
• C）询问他们想测试什么，以及从制作过程中学到了什么。▲
• D）保留有用的部分，弥补漏洞，推动项目前进。✦

12. 该功能与你的设计不同

没人告诉你。你：

• A）和工程师沟通，了解发生了什么，再决定是否是问题。▲
• B）检查这些差异是否会影响体验。如果没有，就继续前进。◆
• C）更新Figma文件，让设计和制作再次达成一致。✦
• D）提高它。如果团队做出了不同的决定，设计至少应该理解原因。■

数数你的符号

你最常选的那一个很可能就是你的默认选择。

●证据收集者
▲外交官
■挑战者号
◆实用主义者
★探险者
✦沉默的修理工

● 证据收集者

你最喜欢的问题可能是类似的：“我们怎么知道？”

你并不特别喜欢看着假设因为有人自信地说出来就变成事实。你会寻找研究、分析、以往实验、支持工单或其他任何能让决策不那么假设性的东西。

当有人说“用户可能想要这个”时，你已经在想“可能”这个词为什么会出现在这里。

这很有用。产品团队在信息不完整的情况下做出很多决策，而你往往是那个注意到自信观点成为必需的人。

你的危险区是在等待证据，彻底消除不确定性。

不会的。在某个阶段，“我们还不知道”仍然足以做出可逆的决定。

▲ 外交官

你常常会注意到真正的问题不在于界面。而是产品、工程和设计解决的问题略有不同。

你提出问题，转化关切，并让合适的人进入同一个对话。当两个人意见不合时，通常你想先弄清楚原因再选边站。当团队陷入僵局时，这很有价值，因为大家都基于不同的假设争论。

你的危险区是把每一次分歧都变成对话。有时候没有隐藏的背景可供挖掘。没人需要工作坊;只需要有人做出决定。

我自己也遇到过类似的线索，之后被告知我“太好心了”.问题不在于善意或避免冲突。我等得太久才说清楚。

■ 挑战者号

你异常坦然地说：“我不确定我们是否应该这么做。”

你质疑简报，挑战假设，并且往往能察觉到某个建议已经变成了决定，而没有人真正审视它。当你觉得推理薄弱时，你会直言不讳。

团队需要愿意做这件事的人。许多糟糕的产品决策之所以能存活下来，仅仅是因为在场每个人都假设别人有充分理由。

当每个分歧都变得值得捍卫时，你的危险区就会出现。有时候利益相关者的烦人建议没问题。有时候你评审的设计师做了不同的选择，也没问题。

你不必因为能看到它就死在每座山上。我对此写过更多内容我越是资历越高，就越不想赢得每一次设计争论.

◆ 务实主义者

你对“我们到底能配对什么？”这样的短语有着异常强烈的喜爱。

你会寻找理想体验、技术现实、业务限制和某人已承诺日期之间的实用中间地带。当工程部门说某件事需要三周时间时，你大概已经在摸索三天的版本了。

你的危险区妥协得如此高效，以至于团队慢慢忘记了本该是什么样的更好版本。每一个合理的权衡都意味着你稍后会回来玩这个。

你知道通常都是这样。

★ 探险者

有人说：“我觉得那行不通。”你的直觉是：“让我看看。”

一旦想法变得具体，你会更好地理解它们。与其在两个假设方案上辩论30分钟，你往往更愿意在20分钟内把两个假设都做得很糟糕，然后发现哪些假设能在实际流程中存活下来。

当一个团队自我说服自己绕圈子时，这很有用。

你的危险区是在你回答了重要问题后继续探索。尝试另一个方向很便宜，但这并不意味着每个决定都值得有五个。

最终你得停止开新的Figma框架，选择一个。

✦ 安静的修理工

你不想花45分钟讨论一个你可能20分钟就能更清楚的问题。你会打开文件，理清流程，清理组件，重写文案，调查实现，或者修正没人正式分配给你的问题。

然后你会带出大家都能应对的东西。

这正是问题所在。

你的危险区是人们习惯了你周围的事物神秘地变得更好。最终你会修正那些你不属于自己的决定，清理没人让你拥有的流程，并吸收别人责任之间的空白。

然后有一天你会想为什么自己会感到疲惫。

我就是这样。我写过关于如何摆脱困境的事我停止了所有修复，开始修复系统.

有混合的吗？

很好。

真正的设计师显然不会被简单地归入六个框架。

当有人提出强有力的产品声明时，你可能是证据收集者;当你不确定互动会如何表现时，你可能是探索者;当解决方案过早确定时，你是挑战者;当工程部门告诉你冲刺周五结束时，你是务实主义者。

在这个非常不严肃的测验下，有一个稍微严肃一点的观点。问题不是你属于哪种类型。而是无论什么情况，你是否总是重复同样的回答。

这些行为大多有用，直到其中一种成为你唯一的回应。

你得了什么？欢迎在评论区告诉我，尤其是如果你觉得测验答错了。

延伸阅读

• 当“太好”不是真正的问题时
• 我越是资历越高，就越不想赢得每一次设计争论
• 我停止了所有修复，开始修复系统
• 设计师在产品团队中真正遇到的困难，作者：Laura Klein（尼尔森诺曼集团）

当事情变得混乱时，你是怎样的产品设计师？最初发表于训练营在Medium上，人们通过突出和回应这个故事，继续讨论。