xAI · Primly 社区

xAI 产品设计师 UX 面试和作品集评审:我的 loop 里发生了什么

brand_ben (Primly starter) · 5 条回复

2025 年末走了 xAI 的 designer loop,想着发出来,因为几乎没人写那边的设计招聘到底是什么样。

背景:8 年设计经验,先 agency 后产品。主要做偏消费端的东西。我申请的是做 Grok 界面的 product design 职位。

recruiter screen 很真诚,也有点直,但我觉得是好的那种直。他们说设计团队很小,这个角色杠杆很高,你会被期待做研究、交互设计,有时候还要自己写 UI 文案。没有专职 writer。这个信息基本把他们要什么说透了:要能落地能交付的通才,而不是需要完整 pod 才能发挥的专才。

portfolio review(60 分钟) 我共享屏幕,讲了三个项目。他们一直打断提问,我其实挺喜欢的。问题永远在过程和决策上,不在美观:比如「为什么你选这个导航模式而不是 X」、「研究里有什么发现让你改方向」、「现在回看你会怎么做不一样」。要准备好讲错误和转向,而不只是胜利。我的一个 case 里有个设计我到现在也不完全满意,我也直接说了。他们似乎更喜欢这种,而不是那种每个 case 都一帆风顺的。

他们还具体问我怎么跟工程师合作:我做不做 redlines、figma dev mode、pair sessions,还是别的。他们想要能减少来回沟通的设计师,而不是增加摩擦的。

design exercise(take-home,4 小时 time-box) 给了我一个提示,和改善 AI assistant 界面里的某个具体交互有关。不能说太多,不然太明显。它是故意很模糊的。关键是你得先自己把问题定义清楚,再去解。我前一小时写了个快速 user model,然后进入解法空间。他们明确说:展示你的过程,而不只是抛一个很精致的 mockup。我用 figma 提交,配了注释 frame 和一个简短的 loom walkthrough。

debrief round 我和两位设计师加一个 PM 过了一遍我的 exercise 方案。他们会戳你的假设,提出不同的 framing。我得在不防御的情况下为自己的选择辩护,这是设计评审里最难的技能。

我会对准备的人说: 不要把 exercise 过度打磨。他们想看你怎么想,不只是你能做出什么。 figma 要很熟:auto-layout、variables、dev mode 交付。 对 AI 产品设计要有观点。现在的 chatbot UI 哪些坏掉了,你会改什么。这不是加分项,你就是要为 AI 产品做设计。 理解小公司 vs 大公司里「high-leverage design」的含义。干系人更少,但也没有安全网。

最后我因为薪酬结构的原因选择不继续,但这个 loop 本身是我这轮求职里做过的更好的之一。

由 AI 翻译,查看原文

5 条回复

ux_uma (Primly starter)

“UI 文案要你自己写”这件事在小型 AI 公司越来越常见了。如果你是 product designer 但对 copy 不太自信,面这些流程前就得主动补上。没有专职 writer 的情况下,哪怕基础的内容设计能力也会更重要。

由 AI 翻译,查看原文

content_cole (Primly starter)

那种 debrief 形式:你讲作业,房间里还有个 PM 追问。我在自己招聘里一直在推这个形式。它比只看成品更能出信号。一个人怎么回应质疑,比 deliverable 本身更说明问题。

由 AI 翻译,查看原文

alex_design (Primly starter)

take-home 里“要先自己定义问题”这一点太关键了。我见过设计师拿到一个很模糊的 prompt 就直接跳到方案,评审是看得出来的。把 time-box 的 20-30% 用来做问题框定,几乎总是值得的,而且在提交里把这段 framing 标注出来,会让评审更容易读懂你的思路。

由 AI 翻译,查看原文

brand_ben (Primly starter)

没错。我以前 take-home 翻车过,就是把一个模糊 prompt 当成了清晰 spec。现在我第一步永远是:这里真正的问题是什么,会不会有不止一种解读方式。把这些先写下来,再打开 figma。

由 AI 翻译,查看原文

Primly Team

在这种 design 面试流程里,有一关经常被低估:作品集 review 里的现场问题 framing。打断你往往不是为了挑刺,而是在测试你是否能:(1)把目标和约束清楚、利落地复述出来,(2)讲清你做的关键取舍,(3)说明什么证据会让你改变想法。

一个通常很有效的结构是:Context(用户、约束、成功指标)→ Decision(你选择了什么)→ Alternatives(你真实考虑过的 2 个选项)→ Evidence(研究、日志、support 工单、可用性信号)→ Tradeoff(你明确让什么变差了)→ Next bet(如果再给你一周你会测什么)。

常见失误:讲得很“精致”,把不确定性藏起来。在很多高杠杆的通才岗位里,不确定性没问题,但没有被你拥有的假设不行。

你遇到过哪个打断问题,彻底改变了你现在讲 case study 的方式?

由 AI 翻译,查看原文