Designing for AI's Present and Future
打开互动全文版(中英对照 + 朗读 + 问答)→Anthropic 产品设计负责人 Joel Lewenstein 探讨设计 Claude 等前沿 AI 产品的独特挑战,平衡即时用户价值与长期根本性变革。
Joel Lewenstein, Head of Product Design at Anthropic, discusses the unique challenges of designing cutting-edge AI products like Claude, balancing immediate user value with long-term radical change.
欢迎来到 Dive Club。我是 Red,这里是设计师永不停歇学习的地方。本周的嘉宾是 Joel Lewenstein,他是 Anthropic 的产品设计负责人,负责设计像 Claude 这样的前沿 AI 产品。我喜欢按每分钟信息密度给节目打分,不得不说这一期是爆表级别的。一个很大的原因是 Joel 非常擅长用比喻来拆解关于 AI 设计、提示工程和系统思维等复杂概念。所以,在深入细节之前,我们先听听 Joel 的背景,然后探讨设计前沿 AI 产品需要什么。
Welcome to Dive Club. My name is Red, and this is where designers never stop learning. This week's episode is with Joel Lewenstein, who's the head of product design at Anthropic, where he designs cutting-edge AI products like Claude. Now, I like to grade episodes in terms of juice per minute, and I have to say this one is off the charts. A big reason why is how effectively Joel uses metaphors to break down really complex ideas around AI design, prompt engineering, and systems thinking. So before we get into all the details, let's hear a little bit about Joel's background, and then we can dive into what it takes to design a cutting-edge AI product.
在此之前,我在 Airtable 工作。在那里待了几年,见证了非常惊人的增长,也遇到了很多难题。然后 AI 革命来了。我和 Airtable 里做 AI 产品的同事密切合作,因为那个产品的形态,我们的第一次尝试就是一个由 LLM 驱动的单元格,可以从另一个单元格获取数据,做一些处理,然后输出一个值。这是一个非常有趣且受限的设计问题。十亿美元的算力浓缩在大概 400 像素的空间里。我当时就有种感觉:天哪,AI 的能力如此强大。我很想知道在一个毫无限制、一切从头开始、没有任何假设的产品上工作是什么感觉。于是我来到了 Anthropic。现在我在 Anthropic,又有点这山望着那山高的感觉:哇,Airtable 有那么多数据、那么多结构、那么多现成的工作流。想想你能用这些数据做什么。所以我们都是从不同角度来解决这个问题,凡事都有利弊,但这一年真是疯狂。我认为 AI 正处于 S 曲线的中间阶段,不同的人会告诉你 S 曲线上不同的位置,但我们试图同时做两件事。在 S 曲线的高端,也就是渐近线那里,我们认为在接下来的几年里,我们与计算机的关系几乎会彻底改变,而且这个数字非常小。如果你读过我们 CEO Dario 的《爱与优雅的机器》那篇文章,他认为 AGI 会在个位数年内到来。所以我们希望在那发生时做好准备,打造产品,打造体验,迎接自施乐帕克以来最根本的计算变革。另一方面,我们也在努力打造人们今天就想用的产品。这些模型尽管还处于成熟早期,但如果知道如何利用,它们能为人们提供很多价值,而很多人并不知道。所以我们同时在做这两件事。在 Airtable 时我们有个说法:提高天花板或降低地板。我们现在试图同时做到这两点,这带来了很多乐趣,也带来了很多混乱,很多边走边摸索,同时推进两条线。
Prior to here, I was at Airtable. Spent a couple years there, saw just really incredible interesting growth, lots of hard problems. Then the AI revolution hits. I was working closely with some of the folks who were working on the AI products at Airtable, and because of the form factor of that product, you know, our first foray was like a cell that is powered by one of these LLMs, can ingest data from another cell, do something, and spit out a value in the cell. Really interesting constrained design problem. A billion dollars of GPU condensed into, you know, 400 pixels or something. And I had this feeling, I was like, man, AI is capable of so much. I wonder what it's like to work on a product with no holds barred, everything can be AI from the ground up, no assumptions. Found my way to Anthropic. Now that I'm at Anthropic, there's a bit of a grass is greener thing where I'm like, wow, Airtable has all of this data, all of this structure, all of these existing workflows. Like think of what you could do with all of that data. So we're all coming at this problem from a different angle, and it's kind of, there's pros and cons to everything, but it's been a wild year. You know, I think AI is in the middle of this S-curve, and different people will tell you different places on the S-curve, but we're kind of trying to do two things at once. On the sort of higher end of the S-curve, the asymptote there, we think nearly everything about our relationship to computers is going to change in the next number of years, and that number is really small. Like if you read Dario, our CEO's, 'Machines of Love and Grace' essay, he thinks AGI is coming, you know, in a single digit number of years. So we're trying to be there when that happens, to build product, to build experience that is ready for the most radical change to computing since, you know, Xerox Park. On the other hand, we're trying to build a product that people want to use today. And these models, despite being sort of in the early phases of their maturity, can provide a lot of value to people if you know how to do it, and many people don't. And so we're sort of doing this, we had this phrase at Airtable: raising the ceiling or lowering the floor. We're kind of trying to do both at once, and that leads to just a lot of fun, a lot of chaos, a lot of trying to figure out as we go, and sort of do both tracks simultaneously.
我写了一篇爆款文章,讲的是设计师缺失的工具,我觉得我终于找到了。这个产品叫 Desen,它让你无需编码就能发布设计变更。你只需进入你的线上应用,他们的扩展会覆盖一个类似 Figma 的界面,这样你就能轻松做设计修改,然后 AI 会编写所有代码并推送到 GitHub。这意味着作为设计师,你可以直接贡献生产代码。这真的很重要。所以去 dive 看看吧。
So I wrote this viral article all about the missing tool for designers, and I think that I finally found it. The product is called Desen, and it allows you to ship design changes without coding. You just go to your live app, their extension overlays a Figma-like interface, so you can easily make design changes, and then the AI writes all the code and pushes it to GitHub for you. That means you as a designer can contribute directly to production code. It's a pretty big deal. So head to dive.
Club/Desen 去试试看,就是 D-S-N。这似乎是我和 AI 领域深度从业者交谈时反复出现的张力:你必须为今天而构建,但当你明知一切都会发生根本性变化时,又该如何做到呢?而且,一只脚踩在两个阵营里,我想象这会给设计师带来一系列完全独特的问题。
Club/Desen to try it out, that's D-S-N. That seems to be the consistent tension whenever I'm talking to people who are deep in the AI space: you have to build for today, but it's like how do you do that when you know that everything fundamentally is going to change? And having one foot in each camp, I have to imagine, creates a totally unique set of problems for designers.
我认为和许多设计问题一样,你只需要先明确你的假设,并且在开始之前找准正确的问题。我们很幸运,拥有足够大的团队和足够多元化的投资组合,因此我们可以非常明确。我们可以说:‘这是一组我们认为今天能为企业客户提供价值的想法;我们预期会看到使用量,预期会看到收入。’然后我们还有一些团队和项目更像是:‘这还需要 X 个月或 X 年才能准备好’,或者‘这是一个在寻找问题的解决方案;我们甚至不知道它是否会有用,但我们正在探索,因为我们觉得潜力很大。’我认为唯一的危险点在于,你是否对自己或团队诚实,是否真的期望人们今天就用上它。不过,我确实认为这个领域有太多炒作和兴奋——我认为对未来前景的兴奋是合理的——但我觉得人们有点低估了仅仅在今天提供价值这件事有多令人兴奋。我们团队里一位资历最深的设计师 Kyle Turman 有句很棒的话:他说,‘即使模型永远不会变得更好,即使 Claude 3 就是终点,Claude 3.5 永远不变,可能仍然有数年的设计工作要做,因为模型能做很多事情,但人们不知道如何让它去做。它是不透明的;它需要这种提示的黑暗艺术;你必须理解所有这些不同的概念和技术思想。’所以有很多有趣的设计问题。是的,我们在做降低门槛和提升上限,但两者都引人入胜,也都很难,是新的、深度的技术问题。所以我两者都喜欢。
I think as with many design problems, you just have to state your assumptions and you have to be dialed into the right problem before you start. We have the luxury of having a big enough team and enough of a portfolio of bets that we can be pretty explicit. We can say, 'This is a set of ideas that we think provides value today to our enterprise customers; we expect to see usage, we expect to see revenue.' Then we have teams and initiatives that are much more like, 'This won't be ready for X months or X years,' or 'It's a solution in search of a problem; we don't even know if this is going to be useful yet, but we're exploring it because we feel there's a lot of potential.' I think the only danger spot is if you're not honest with yourself or with your team about whether we expect people to use this today. I do think, though, there's so much hype in the space and so much excitement—I think merited excitement for what the future holds—but I think people sleep a little bit on how exciting it is to just provide value today. One of the most tenured designers on our team, Kyle Turman, has this great phrase: they say, 'Even if the models never got better, even if Claude 3 was it, Claude 3.5 was it for all time, there's probably still years of design work left because there are all these things that the model can do that people don't know how to get it to do. It's opaque; it requires this dark art of prompting; you have to understand all of these different concepts and technical ideas.' So there are a lot of interesting design problems. Yes, we're doing floor lowering and ceiling raising, but they're both fascinating and they're both hard, interesting, new, deeply technical problems. So I like them both.
你之前对我说过,有些 6 个月前在 AI 领域看起来正确的事情,现在似乎不那么正确了。你能为我们详细解释一下吗?
Something that you said to me earlier was, you said some things that seemed true about the AI space 6 months ago don't seem so true anymore. Can you unpack that for us?
每个想在 AI 领域做设计的人——包括我自己——看到所有这些聊天机器人,都会说:‘我不会去做聊天机器人;我们要超越聊天机器人。’然后你与这些模型相处,你尝试、推动、实验。我认为语言作为与计算机的沟通媒介,有一种非常深刻的东西,这些聊天机器人用看似简单的 UI 真正捕捉到了这一点。而且我认为,用不同的 UI 获得那么多价值并提供那么多灵活性和力量,实际上非常困难。肯定还有更多可能性。我在脑海中开始区分语言作为小写‘i’的界面——作为一种沟通媒介——和聊天机器人,或者聊天作为两个实体之间来回的气泡。我想我比以前更看好语言了。举一个非常具体的例子:我们有一个叫 Artifacts 的产品。我们把文档放在右侧面板里,这样你可以生成这些资产,并实际看到你在做什么。我们最近推出一个小功能,你可以高亮 Artifacts 的一部分,然后说‘改进这个’,接着你可以给 Claude 指令,告诉它你想要什么:‘我不喜欢这一段;我希望它更有趣;我希望你多融入这篇文章的论点’等等。这不一定是聊天,对吧?你更像是在文档编辑模式中,但它是语言——是思想的自由表达,不受工程师放在代码库中的枚举约束。我认为这非常人性化,并且很可能在很长一段时间内成为这些交互的一个特征,即使屏幕上的矩形开始看起来和聊天机器人不一样。
Everybody who wants to do design on AI—myself included—sees all of these chatbots and is like, 'I'm not going to do a chatbot; we're going to move beyond the chatbot.' And then you sit with these models, you try things, you push, you experiment. I think there's something deeply profound about language as a communication medium with computers that these chatbots, in a seemingly simple UI, have really captured. And I think it is actually quite difficult to get that much value and to provide that much flexibility and power with different UIs. There's definitely more out there. I've come to distinguish in my head between language as a lowercase 'i' interface—as a communication medium—and chatbots, or chat as a series of bubbles back and forth between two entities. I guess I'm long language in a way that I wasn't previously. So to take a really concrete example: we have this product called Artifacts. We put documents in this right pane so you can produce these assets and actually see what you're making. We recently launched a small thing where you can highlight a part of that artifact and say, 'Improve this,' and then you can give Claude instructions for what you want: 'I don't like this paragraph; I'd like it to be more interesting; I'd like you to pull in more of the thesis of this essay,' whatever. That's not chat necessarily, right? You're more in a document editing modality, but it is language—it is the free-form expression of ideas, unconstrained by an enum that an engineer sort of put into a codebase. I think that's just deeply human and probably going to be a feature of these interactions for a long time, even if the sort of rectangles on screen start to look different from a chatbot.
我喜欢这个区分。而且我认为归根结底,有时候就是设计师喜欢新奇——我们想超越聊天,因为我们就是不想做前人做过的事情。
I love the distinction. And I think at the end of the day, sometimes it's just like designers love novelty—we want to push past chat because we just don't want to do the same thing that the people before us did.
是的,这很有趣。我们显然对未来做了很多思考,又回头看了 Dario 的文章,然后想:好吧,如果你相信这个假设——在 2、3、4 年内,模型将能够进行复杂推理,解决一群人从未解决过的问题,采取独立行动,反思自身等等——那么给它指令的方式是什么?给这个极其强大、深思熟虑、能解决问题的实体一个待解决的问题或挑战的方式是什么?我们制作草图、模型和愿景资产,有趣的是,它可能仍然是用几句英语或你选择的语言给它指令。区别在于,现在你能给的句子是‘请总结这个 PDF 并放入邮件’,而未来将是‘请利用你对人类生物学的理解,提出三个关于阿尔茨海默病病因的新假设,设计一个实验室实验,并为这个实验申请 FDA 批准。’对吧?所以从你写文字、AI 做事情这个意义上说,它仍然是聊天;只是‘做事情’变得难以想象地庞大。这里面有各种各样的设计问题,对吧?比如当这个强大的东西在后台运行时,用户应该参与多少?
Yeah, it's funny. We've been doing a lot of thinking about the future, obviously, and thinking again, looking at Dario's essay, and thinking like, okay, if you believe the hypothesis that in 2, 3, 4 years the models will be able to do complex reasoning, solve problems that groups of people have never solved before, take independent action, reflect on its own thing, whatever—what is the way to give it instructions? What is the way to give this incredibly powerful, thoughtful, problem-solving entity the problem, the challenge to go solve? And we make sketches and mock-ups and vision assets, and it's funny because it's still probably giving it instructions in a few sentences in English or your language of choice. The difference is right now the sentence you can give is like, 'Please summarize this PDF and put it in an email,' and in the future it will be, 'Please use your understanding of human biology to develop three novel hypotheses for the cause of Alzheimer's and propose a laboratory experiment and apply for FDA approval for this experiment.' Right? So it's still a chat in the sense that you're writing words and the AI is doing stuff; it's just that the doing stuff becomes unthinkably large. And there are all sorts of design problems in there, right? Of what involvement should the user have as this powerful thing is operating sort of in the background.
我们能深入探讨一下吗?因为我确实认为,作为一个局外人,我看到这个领域的很多创新,有时确实感觉像是一堆技术演示或寻找问题的解决方案。那么,与 AI 合作如何塑造你探索不同设计和产品想法的方式,尤其是当你在这种边缘地带运作,甚至可能是在技术下一次数量级跃升之后?
Can we go a little bit deeper into that? Because I do think as an outsider, I look at a lot of the innovation in the space and sometimes it does kind of feel like a bunch of tech demos or solutions in search of problems. So how does working with AI shape the way that you explore different design and product ideas, especially when you're operating kind of at this fringe, maybe even post the next order of magnitude jump in the technology?
是的,‘寻找问题的解决方案’这个说法非常有趣。我认为它通常被认为是贬义的、轻蔑的——人们说这话的意思是‘你不应该那样做’。当然,大写 D 的设计学派会说理解用户问题,从那里开始锚定。你知道,任何好的设计评审都是从‘这里是用户问题’开始的。这才是经久不衰的,对吧?技术会变,但人们的问题不变。但我开始认为‘寻找问题的解决方案’根本不是脏话。我认为只要你接受它,并且再次保持清晰,明确假设,知道自己在做什么,说‘看,这里有一些萌芽,我们要去探索它。’我认为唯一重要的是诚实地面对你所处的阶段。
Yeah, so 'solutions in search of a problem' is such an interesting phrase. I think it's generally felt to be derogatory, pejorative—people say that as a sort of 'you shouldn't do that.' And certainly the capital-D design school would say understand user problems, start anchored there. You know, any good design crit starts with 'here are the user problems.' That's what endures, right? The technology changes but people's problems stay the same. I've come to see 'solutions in search of a problem' as not a dirty word at all. I think as long as you just lean into it and you again have clarity, stating assumptions, knowing what you're doing, saying, 'Look, there's the germ of something here and we're going to explore it.' I think the only thing that matters is being honest about the stage you're in.
真正重要的是,最终问题和解决方案能够连接起来,这样你就是在为真实的人解决真实的问题。但我已经对从哪一端开始变得相当不可知论了。这可能让人不舒服。当我刚开始时,我们确实是一个非常重视原型的文化。我们是一个'凭自己的热情和直觉探索事物'的文化。这来自我们的研究人员、工程师和设计师。而我那大写D的设计思维看到所有这些原型时,我会想:'但用户的问题是什么?给我一个用户旅程。'我不得不稍微压制这种想法。不是要太俗气,但就像《社交网络》里贾斯汀·汀布莱克的那句台词:'我们不知道它能成为什么,我们只知道它很酷。'并不是所有东西都会有用,但我认为,仅仅停留在某个酷炫且引人入胜的东西上,并看到它的萌芽,是很有价值的。然后我脑子里有一个双钻石设计过程的图,从解决方案端伸出卷须,最终找到通往产品或问题端的路。我觉得这没问题。
What really matters is that eventually the problem and the solution link up together, so you're solving a real problem for a real person. But I've come to be pretty agnostic as to which end you start from. And this may be uncomfortable. When I started, for sure, we're a very prototype-heavy culture. We're a very 'explore things out of our own passion and intuition' culture. This comes from our researchers, from our engineers, from our designers. And my sort of capital-D design brain would see all these prototypes and I'm like, 'But what's the user problem? Give me a user journey.' And I've had to sort of quiet that a little bit. Not to be too cheesy, but it's the Justin Timberlake line from The Social Network: 'We don't know what it can be. We just know that it's cool.' And not all of it is going to be useful, but I think there is something deeply valuable to just sitting with something that is cool and compelling, and you can see the germ of something. Then I have a diagram in my head of a Double Diamond design process, and sort of tendrils coming out from the solution end and eventually finding their way to the product or to the problem end. I think that's okay.
这也是一个多么有趣的工作环境啊。我个人还没有加入过那种产品团队,但看起来真的很酷,因为通常情况下,你做的事情都源于用户问题或高层业务目标,最终一切都是自上而下流动的。而你几乎坐在一个有点混乱的技术创新泡泡里,即使只是为了生存,你也必须对新鲜事物做出反应。这和我工作过的任何其他地方都不一样。在其他地方,代码是因为有 PRD(产品需求文档)才被写出来的,代码交付的是 PRD 设定的需求。
What a fun environment to work in too. I personally have not been in that type of product team yet, but it looks really cool, because it's so typical that the things you would be working on would be derived from user problems or top-level business objectives, and everything at the end of the day kind of flows top-down. Whereas you almost are sitting on this kind of a little bit chaotic bubble of technical innovation, where you have to respond to the new things even just to stay alive. It's unlike any other place I've worked. Every other place, code gets written because there's a PRD, and the code delivers the requirements that the PRD sets out.
我对 AI 有很多类比,但现在最能引起我共鸣的是:就像看着一个孩子长大。我有一个六岁、一个三岁和一个四个月大的孩子。做父母有一种神奇的经历,尤其是对老大,当他第一次解决一个问题时。我的意思是,可以简单到他们以前从未打开过冰淇淋蛋筒的盒子,然后他们做到了。或者他们在学习阅读,或者他们在事物之间建立了你从未见过的逻辑联系。关键是,你从未教过他们。六岁的孩子刚上幼儿园,所以他经常在外面,回来后会带来一些我和我妻子没有教过他的见解。我们和他在一起,然后我会转向我妻子说:'你知道他能做到吗?'她说:'不,这太神奇了。'而这正是坐在这些模型之上的感觉。我们惊人的研究团队正在推动最前沿的技术。这些模型从生产线上下来。我们都在戳戳点点,然后想:'嗯,我不知道它以前能解决这个级别的问题',或者'哇,它在一个以前相当枯燥的话题上变得很有诗意和哲学意味。'这打开了什么?我们以前没有想到的事情是什么?这如何扩大我们的视野?你需要放下假设,因为有一个智能实体,一个在你身边成长、成熟和变化的东西。所以它有一种反应性、开放性和存在感,我认为这在更声明式的软件世界里是不存在的。
I have many analogies for AI, but the one that resonates the most for me right now is: it's like watching a child grow up. I have a six-year-old, a three-year-old, and a four-month-old. There's this magical experience of being a parent, especially for your oldest, where they figure out a problem for the first time. I mean, it can be as simple as they've never managed to open the box of ice cream cones before, and then they do. Or they're learning to read, or they're making these logical connections between things that you've never seen. And critically, you've never taught them. A six-year-old just started kindergarten, so he's out in the world a lot, and he comes back with these insights about things that my wife and I didn't teach him. We'll be present with him, and then I'll turn to my wife and be like, 'Did you know he could do that?' And she's like, 'No, this is amazing.' And that really is what it feels like sitting on top of these models. Our astounding research team is pushing the state-of-the-art. These models are rolling off the assembly line. We're all poking and prodding, and we're like, 'Huh, I didn't know it could solve this level of problem before,' or 'Wow, it got really poetic and philosophical on a topic that it used to be pretty dry about.' What does this open up? What are things that we weren't thinking of before? How does this expand our aperture? You need to just drop assumptions, because there's this intelligence entity, this thing that is growing and maturing and changing next to you. So there is a level of reactivity and openness and presence to it that doesn't exist, I think, in more declarative software universes.
设计 AI 产品的另一个元素,我很想听听你的看法,就是这种从非常明确的用户旅程和流程的转变,你面对的是更加流动的产品表面,几乎是无限的自由度。这如何影响像 Anthropic 这样的设计团队的工作方式?
Another element of designing AI products that I'm kind of curious to hear you talk about is this departure from very defined user journeys and flows, where you're dealing with this much more fluid product surface area, kind of infinite degrees of freedom. How does that impact the way that a design team like Anthropic shows up?
大多数现有软件就像坐火车或地铁,对吧?有一系列站点。你可以提前定义旅程。你可以绘制整个空间的地图。你可以说它是纽约市地铁图。这个系统只有 47 个站点。我知道如何到达每一个。我看到设计师的作品集展示中,人们真的画出了存在的每一页。我认为当前聊天机器人的范式更像是被扔在一片没有地图或小路的田野中央。你可以做任何事,你拥有的自由度几乎是无限的。而且它是基于语言的。这既是 LLM 惊人的力量和机会,如果你不是经验丰富的徒步者,也相当令人生畏。把这个比喻推到极限,我认为在这个领域工作的设计团队的挑战是提供足够的寻路和路径,让人们感到舒适,但不要把他们锁进单轨系统。所以有一些现有的模式在这里有效:建议、模板、引导人们的方式。有趣的是,你可以获取用户所处的状态。你可以查看他们正在写的聊天记录和文档。然后你可以让另一个模型在后台运行,查看那个状态,并问:'你认为这个人可能想做什么?他们看起来像是在探索模式吗?他们是在尝试生成文档吗?他们看起来卡住了吗?'你实际上可以问另一个 Claude 实例:'这个用户看起来卡住了吗?'然后你可以给他们指导。轻指导、重指导、像牛道一样轻轻引导他们,或者像有护栏的大路一样,你说:'你看起来卡在这里了,我们会把你引导到这条路上,这样你至少能到达某个地方。'而对于那些感觉非常舒适的人,总是可以穿过田野,走向没有人要求你去的方向。
Most existing software is something like being on a train or a subway, right? There's a series of stops. You can define the journey ahead of time. You could map the entire space. You could say it's the New York City metro map. There are only 47 stops in this system. I know how you get to each one. I see designer portfolio presentations in which people literally map out every page that exists. I think the current paradigm of chat bots is more like being dropped in the middle of a field with no map or trails. You can do anything, and the number of degrees of freedom you have is almost literally infinite. And it's language-based. This is both the astonishing power and opportunity of LLMs. It's also pretty intimidating if you are not an experienced hiker. To push this metaphor to a breaking point, I think the challenge of a design team working in this space is to provide just enough wayfinding and pathways that people feel comfortable, but to not lock them into a monorail system. So there are existing patterns that work here: suggestions, templates, ways of guiding people. Interestingly, you can take the state that a user is in. You can look at a chat and a document that they're writing. You can then run another model working in the background, look at that state, and say, 'What do you think this person might want to be doing? Do they seem like they're in exploring mode? Are they trying to produce a document? Do they seem stuck?' You can actually ask another instance of Claude: 'Does this user seem stuck?' And then you can give them guidance. Light guidance, heavy guidance, cow paths that maybe guide them gently, big roads with barriers where you're like, 'You seem pretty stuck here, we're going to funnel you down this path so at least you get somewhere.' And then for the people who feel really comfortable, there's always walking through the field in a direction that no one has asked you to go down.
你还有什么其他想法吗?即使从你在 Airtable 的背景来看,这些技术含量很高、功能强大的产品。关于如何将合适的抽象层次或隐喻带给人们,把一些超级强大、可能复杂、可能令人生畏的东西,变成有意义的东西,你学到了什么?
Do you have any other thoughts on, even coming from your background with Airtable, these really tech-heavy powerful products? What have you learned about bringing the right level of abstraction or metaphors to people, to take something that is super powerful, maybe complex, maybe intimidating, and turn it into something that makes sense?
最终,你必须说用户和用户问题的语言。所以我认为我在 Airtable 的岁月里的旅程基本上是:一开始,我们有一个数据库,一种灵活、可见的可视化数据库。最终我们添加了自动化,以及这些可定制的仪表盘和应用。所以你有一个模型-视图-控制器架构。毫无疑问,一个灵活的 MVC 软件平台对人们是有价值的。但我们一次又一次地通过用户研究、增长数据等看到,这对人们来说没有意义。人们不是在寻找一个灵活的 MVC 平台。他们在寻找解决他们问题的方案。所以你必须在他们所在的地方与他们相遇。你必须提供模板、例子和映射到他们心智模型的隐喻。例如,不要说'数据库',而是说'更智能的电子表格'。不要说'自动化',而是说'如果这样,那么那样'。你必须在技术现实和用户理解之间架起桥梁。这是一个持续的挑战,尤其是当产品进化并变得更加强大时。
Ultimately, you have to speak the language of users and user problems. So I think the journey in my years at Airtable was basically: at the start, we have this database, this kind of flexible, visible visual database. Eventually we added automations, and we added these kind of customizable dashboards and apps. So you have a Model-View-Controller architecture there. And I think there is no doubt in the world that a flexible MVC software platform is valuable to people. But we saw time and time again through user research, through growth numbers, etc., that doesn't make sense to people. People aren't looking for a flexible MVC platform. They're looking for a solution to their problem. So you have to meet them where they are. You have to provide templates, examples, and metaphors that map to their mental model. For instance, instead of saying 'database,' you say 'a smarter spreadsheet.' Instead of 'automations,' you say 'if this, then that.' You have to bridge the gap between the technical reality and the user's understanding. And that's a constant challenge, especially as the product evolves and becomes more powerful.
用户要的是四分之一英寸的钻头,其实他们想要的是四分之一英寸的孔,对吧?你必须用那种语言说话。我们在 Airtable 开始把这些东西打包成解决方案时,看到了更多的兴奋、理解、增长和收入,我们说:‘好,这里有所有原材料,所有零件,这是真正解决你问题的东西。你是一个产品经理,你面临的问题是跟踪团队的工作。你只需要相信这套工具可以组合成一个软件,让你跟踪团队的工作。我们会为你完成所有组装,交给你,然后让你在此基础上定制。’我们在 Airtable 经常用的另一个类比,我觉得也非常适用于 Anthropic,就是乐高积木。你可以把乐高看作是一套无限表达力、模块化、可组合的东西。你可以决定它如何呈现在一个决定是否购买乐高的人面前。我认为有三个层次。你拿一堆乐高积木倒在桌子上,说:‘它能做任何事,我保证。’这大概是我们开始的地方。我觉得这非常令人望而生畏。诱惑可能是去建造那个用了 16000 块积木、花了 42 小时拼好的泰坦尼克号,然后展示:‘看,这东西太强大了,看我们能造出什么。’我认为这也是个错误,因为没人想要真正的泰坦尼克号。他们想要一艘完全符合他们心意的船。他们想要外面是蓝色的,想要四个烟囱而不是三个。所以诀窍是找到中间地带,你说:‘这里有几种不同形状的船。你可以装上或拆下那些对你有意义的零件。我们给你提供了三种不同的烟囱、两种舵和三种帆。我们做了中等保真度的零件。现在你可以把它们拼在一起,做出让你感觉很好的东西。’最终你学会如何一直定制到逐块积木的层面。所以我认为是找到那个中间地带,用用户需求的语言说话,而不是技术能力的语言。
Quarter inch drill, they're looking for a quarter inch hole, right? You have to speak in that language. We started to see a lot more excitement, understanding, growth, and revenue at Airtable when we started packaging these things into solutions and saying, 'Okay, here are all these raw materials, here are all these pieces, here's the thing that actually solves your problem. You are a product manager, the problem you face is keeping track of your team's work. You just want to believe that this set of tools can be put together into a piece of software that lets you track your team's work. We're going to actually do all of that assembly for you, hand it to you, and then let you customize from there.' Another analogy we use a lot at Airtable that I really like and think is very applicable to Anthropic is Lego pieces. You can think of Legos as this infinitely expressive, modular, composable set of things. You can decide basically how that shows up to a person deciding whether to buy Legos. I think there are three levels. You just take a bunch of raw Legos and dump them out on the table and say, 'It can do anything, I promise.' That's probably where we started. I think that is deeply intimidating. The temptation is probably to build that Titanic that took 16,000 pieces and 42 hours to put together and show, 'Look, this thing is so powerful, look what we can build.' I think that's a mistake too, because nobody wants the actual Titanic. They want a boat that is exactly the boat they want. They want it colored blue on the outside, they want four steam stacks instead of three. So the trick is to find the middle where you say, 'Here are a couple different shapes of boats. You can take on and off the pieces that make sense to you. We brought you three different steam stacks, two different helms, and three different sails. We've made the medium-fidelity pieces. Now you can click these together and make something that feels really good to you.' Eventually you learn how to customize all the way down to the brick-by-brick level. So it's finding that middle ground, I think, and speaking in user needs language, not technical capabilities language.
我喜欢这个类比。它甚至让我回到你刚才说的例子,你可以问另一个 Claude 实例,这个用户可能在哪里卡住了,不仅要找到那个中间地带,还可能根据用户当时的情况动态调整。这是一套非常有趣的设计机会。它完全打破了我通常认为的设计产物中固定的屏幕和流程数量,但真的很令人兴奋。
I love that analogy. It even makes me go back to the example you were just talking about where you can ask another instance of Claude where this user might be feeling stuck and thinking about not only finding that middle ground but potentially making it dynamic to the situation that user is experiencing right then. It's such a fun set of design opportunities to think about. It totally breaks away from the set number of screens and flows that I would typically think about design artifacts as, but it's really exciting.
我有个有趣的故事。我们当时在做一个功能,基本上就是做这个,对吧?它查看聊天记录,然后说:‘我们认为你可能想做的三个下一步。’负责这个功能的设计师 Simin,她把它带到设计评审会上。她展示出来,UI 非常直接,就是聊天下方出现的一些小建议卡片。她展示了一些例子,大家说:‘嗯,挺好的,有道理,这些是好的下一步。我们应该考虑什么时候以及如何推出它。’评审会差不多要结束了,因为东西很好,没什么可说的。然后有人问:‘你能给我们看看你用来让另一个 Claude 实例做出正确建议的提示词吗?’她拿出了一份七页的提示词,里面有各种指令、例子和小调整。提示词的艺术就是这种黑暗艺术。她迭代了,我记得她说大概 75 或 100 次,几百次迭代,尝试不同的提示词组合,观察效果,看是否合理,所有这些都是为了让用户看到的东西优雅简单。这对我来说是进入 AI 世界的另一个重大觉醒时刻:提示词是设计过程的一部分,设计师需要知道怎么做。Simin 现在在内部教我们的设计团队如何写提示词,因为它对你交付给用户的最终产品至关重要。
I have a fun story there. We were working on a feature that basically does this, right? It looks at a chat and says, 'Here are three next steps we think you might want to do.' The designer working on it, Simin, she brought it to crit. She shows it, the UI is pretty straightforward, it's little suggestion chips that appear underneath the chat. She showed some examples, and you're like, 'Yeah, that's pretty good, that makes sense, those are good next steps. We should think about when and how to roll this out.' The crit was sort of tailing off just because it was good, there wasn't a lot to say. Then someone was like, 'Can you show us the prompt that you used to ask this other instance of Claude to make the right suggestions?' And she brings up this seven-page prompt with all of these instructions and examples and little tweaks. The art of prompting is this dark art. She had iterated, I think she said like 75 or 100, hundreds of iterations trying different combinations of prompts, looking at it, seeing if it made sense, all to get this thing that was just elegant and simple for a user. This was another big awakening moment for me switching into the AI world: prompting is part of the design process, and designers need to know how to do it. Simin now teaches our design team basically how to do prompting internally, because it is so critical to the end product you're delivering to people.
你们从这种黑暗艺术中学到了什么,可以让听众直接应用,或者当他们开始涉足这个领域、可能不是每天都与这些模型打交道时,能更实用一些?
What have you all learned about the dark art that someone listening to this could just apply or make it a little bit more practical when they're kind of making their own foray into this world where maybe they're not working with these models every day?
元建议就是多尝试。就像 AI 领域的一切,没有一套非常精确的步骤来完善某件事。Claude 知道如何为自己写提示词;它知道好的提示词是什么样的。所以如果你在这个工具上做到了一半,你可以问一个 Claude 实例。UI 中有一个按钮写着‘用 Claude 改进这个提示词’。你给它提示词,它实际上会迭代,让自己变得更好。然后你可以再次运行你的例子。这真的很迭代。老实说,感觉就像设计过程。你尝试一些感觉接近的东西,你琢磨它,你觉得‘这感觉不对’,你就微调一下。你做的具体改变,有一些最佳实践,对吧?比如‘让 Claude 扮演一个角色:你是一个专家产品评审,你是一个营销天才。’使用例子,从那开始有点像模板。然后就是调整个别词语。我见过一些案例,用小写字母和全部大写字母给出指令,结果差别很大。所以我认为这很像设计。我无法给你一个七步流程来做出好的 UI。更像是:尝试一些东西,琢磨它,微调,再琢磨,在不同场景下压力测试,迭代,回到第一个,对比。这真的是一次探索性的迭代之旅。
The meta advice is just try a lot of stuff. Like everything in AI land, there's not a really exact set of steps to go through to perfect something. Claude knows how to write prompts for itself; it knows what a good prompt looks like. So if you get yourself halfway there on this tool, you can then ask an instance of Claude. There's a button in the UI that says 'Improve this prompt with Claude.' You give it the prompt, it will actually iterate and get itself to something that is even better. Then you can run through your examples again. It's really iterative. It feels like a design process, to be honest. You try something that feels close, you sit with it, you're like 'I don't feel like this is right,' you nudge. The actual concrete changes you make, there are best practices, right? There's 'Ask Claude to be in a role: you are an expert product reviewer, you are a marketing genius.' Using examples, there's sort of a bit of a template from there. It is tweaking individual words. I've seen cases where the difference between giving instructions in lowercase and all capitals actually makes the difference. So it really, I think, is much like design. I couldn't give you a seven-step process to make a good UI. More like: try something, sit with it, nudge, sit with it again, stress test it in a different scenario, iterate, go back to your first one, compare and contrast. It really is an exploratory, iterative journey.
我想稍微转换一下话题,谈谈你们正在设计和开发的一些具体产品。也许首先,我想多了解一下你们团队是如何工作的。你能分享一下像 Claude Artifacts 这样的东西背后的故事,以及它是如何诞生的吗?
I want to transition a little bit and get into some of the specifics of the products that you're designing and working on. Maybe to start, I want to learn a little bit more about how you all are working as a team. So can you share a bit about the backstory behind something like Claude Artifacts and how that came to life?
当然可以。Claude Artifacts 是一个很好的例子,体现了我们的一些公司价值观。它很好地展示了两个方面:我们如何与研究团队合作,以及我们如何制作原型。这个想法最初来自我们的研究团队。在大量使用它进行研究的过程中,他们有点沮丧,因为每次它写出代码,他们都要把代码复制粘贴到代码编辑器中,再回到……
Absolutely. Claude Artifacts is an amazing example of some real company values. The two things it showcases really nicely are how we work with research and how we prototype. The idea started on our research side. In the course of using it a bunch for this research, they kind of got frustrated that every time it wrote code, they had to copy and paste that code into a code editor, go back to a...
浏览器一刷新,就感觉像是个笨拙的循环。于是他们想,等等,这是 HTML。我在浏览器里用 Claude,为什么不直接把它渲染到侧边栏里,这样我就能让 Claude 给我 HTML,然后直接在旁边看到效果?他们做了那个原型。我们内部有个会议,基本上公司任何人都可以来演示一些他们认为很酷的东西。所以又回到之前那个点:它必须很酷。你不需要知道它最终的未来是什么。所以他们带来了这个东西。现场有设计师、产品人员、工程师、研究员。我们的一位产品设计师 Michael 看到了,他说,这很重要。第一次,感觉 Claude 在为你创造东西。这里有一些可用性上的好处,那就是在行内看到一个大文档很糟糕,你不得不费力地把 Claude 的评论和文档分开。所以这只是一个基本的可用性问题。但我认为 Michael 发现的是更深层的东西,关于它的感觉,那就是感觉 Claude 在为你创造东西。我们希望 Claude 成为你最好的协作者、最好的创意伙伴。创意伙伴会给你草稿,接受对草稿的反馈,有对话,有交流。所以 Michael 认为这非常深刻。然后他又做了另一个原型,分享给公司。那个原型被 Dario 注意到了,他基本上说,这太棒了,我们应该发布它。然后我们就开始加速了。我不能谈具体细节,但还有一些基于 Michael 原型的变体,把这个想法推向了更远的极限。同样,它们只是很酷。我们还不知道拿它们做什么。有些在 S 曲线的低端,有些在 S 曲线的高端。我认为我们工作的方式很大程度上可以用一句话概括:“眼见为实”。你可以谈论 AI,可以写 AI,可以编程,但看到工作原型并感受那种动态的、随机的本质,然后说“哇”,这非常有力量。听别人描述,我不知道自己会有多兴奋,但看到网站实时渲染、迭代并在你面前变化,这就有种魔力。原型确实有助于推销这一点。
Browser hit refresh, it was just like this clunky loop. So they were like, wait, this is HTML. I'm using Claude in a browser. Why don't I just render this in a sidebar so that I can just have Claude give me HTML and I can see the HTML right to the side? They built that prototype. We have a meeting internally where basically anyone from the company can come and demo something that they think is just compelling. So we're back to the earlier point of like it just has to be cool. You don't have to know what the ultimate future of it is. So they bring this thing. There's designers, there's product people, there's engineers, there's researchers. There, one of our product designers named Michael sees it and is like, this is a big deal. For the first time, it feels like Claude is making something for you. There's some usability benefits here, which is that it sucks to see a huge document rendered inline. You have to sort of tease apart Claude's commentary and the document. So there's just a basic usability thing. But I think what Michael identified was something sort of more profound about the feel of it, which is that it feels like Claude is making something for you. We want Claude to feel like the best collaborator, the best creative partner you've ever had. And creative partners give you drafts, they take feedback on drafts, there's a dialogue, there's a conversation. And so Michael noted that this was really profound. He then built another prototype, shared it with the company. That prototype got noticed by Dario, who is basically like, this rules, we should ship this. Then we're off to the races. I can't talk about the specifics, but there are also prototypes riffing off of Michael's prototype that push this idea even further to the limit. Again, they're just cool. We don't know what to do with them yet. Some of them are like low on the S-curve, some of them are radically high on the S-curve. I think largely how we work is we have a phrase like "seeing is believing." You can talk about AI and you can write about AI and you can code, but there's something just so powerful about seeing a working prototype and feeling the dynamic, stochastic nature of it and just saying like, wow. Hearing this described, I don't know how excited I would have been, but seeing a website get rendered in real time, iterating on it and seeing it change in front of you, it just there's something magical about it. And prototypes really help sell that.
你们目前正在招聘。我想稍微聊聊这个。我读了职位描述,第一条职责写着设计师应该为工具的 Strategic 方向做出贡献。我想听你多谈谈这对你来说是什么样的,尤其是对于像 Claude 这样非常技术性的产品。
You're currently hiring. I want to talk about that a little bit. And I read the job description and the first responsibility line says that designers should contribute to the strategic direction of our tools. I'd like to hear you talk a little bit more about what does that look like to you, especially for a very technical product like Claude.
这是个很好的问题。我认为这有助于我们看清什么是可能的。使用视觉叙事、原型、模型。我在 Airtable 的前老板 Chad Thornton 会称之为“挑衅”——用视觉资产挑战人们的假设,开始帮助我们看清可能实现战略或解决问题的方式。我认为如果产品和产品管理能给出一个非常清晰的问题要解决,设计在塑造战略中的角色就是探索广阔的解决方案空间,并理解我们有多种不同的方式来解决这个问题。我认为他们做的另一件事,可能在一个组织中独特或半独特,就是始终牢记全局,保持这种整体的产品体验。我认为最好的功能是那些同时解决多个问题的,是简单的抽象,可以成长为解决未来问题的功能。所以塑造战略的一部分,我认为是提出一个解决方案,不仅仅是——以 artifacts 为例。我们刚刚谈过。有一个用户问题,即用 Claude 写文档很困难,因为它占满了整个屏幕,你实际上看不到 Claude 的评论等等。你可以把这个交给设计师,说:“我们能解决这个问题吗?”叙述者注:我们不是这样做的,但你可以想象这是一种解决问题的方式。你可以找到 10 种不同的解决方案来解决这个问题。其中一些解决方案是新概念、新抽象、新事物的种子,你可以在此基础上构建。我认为设计师的工作就是看到这一点并倡导它。所以举个极端的例子,你可以加一个折叠按钮,把长文档隐藏到聊天里。那会是一个局部解决方案,但它不是一个可以在此基础上构建的复合抽象概念,不是产品中的原语。把东西放到侧边栏可能看起来是一个明显的解决方案,我认为设计师的工作就是说:“嘿,这里有未来。如果我们这样做,这为我们未来打开了什么。我们可以帮你更好地写代码,我们可以可视化代码,也许有一天会有多个文件,也许有一天你会用 artifacts 进行动态编辑,同时在聊天和文档中互动。”我认为找到正确的解决方案,同时找到那个成为乐高积木之一、成为构建模块的解决方案,就是战略如何被塑造的。
That is a really good question. I think it's helping us see what's possible. Use visual storytelling, use prototypes, mockups. My old boss at Airtable, Chad Thornton, would say "provocations" — kind of challenge people's assumptions with visual assets and start to help us see what might be possible as ways to achieve our strategy or the problems that we want to solve. I think if product and product management can give a really clear problem to solve, design's role in shaping strategy is to explore a vast solution space and understand like here are a bunch of different ways we can solve this. I think what they also do, probably uniquely or semi-uniquely in an org, is just keep the whole picture in mind and keep this sort of holistic product experience in mind. And I think the best features are the ones that solve multiple problems at once, that are simple abstractions that can grow into ones that solve future problems. And so part of shaping strategy, I think, is proposing a solution that is not just — let's take artifacts as an example. We just talked about it. There is a user problem which is that it's hard to write documents with Claude because it takes up your entire screen, you can't actually see Claude's commentary, etc. You could hand that to a designer and say, "Could we solve that problem?" Asterisk narrator: that's not what we did here, but you could imagine that is a way of solving a problem. You could find 10 different solutions that would solve that problem. Some of those solutions are the seeds of a new concept, a new abstraction, a new thing that you can build on. And I think it's design's job to see that and advocate for it. So to paint stupid ends of the spectrum, you could just have a collapse button that takes long documents and hides them in the chat. That would be like a local solution to a problem, but it is not a sort of compounding abstract concept that you can build off, a primitive in the product. Bringing things in the side panel might seem like an obvious solution, and I think it's designers' jobs to say like, "Hey, there's a future here. If we do this, here's what this opens up for us in the future. We could help you write code better, we could visualize code, maybe one day there's multiple files, maybe one day you're doing dynamic editing with artifacts and actually engaging both in the chat and in the document." And I think finding the right solution, but also finding the solution that becomes one of the Lego pieces, one of the building blocks, is how strategy is shaped.
是的,我能看到这在开放式的 AI 原生产品中非常重要,就像找到那个解锁全新探索领域的构建模块。这是一个很酷的思考方式。我们一直在谈论产品。我想稍微拉远一点,谈谈组织,因为你跟我说过组织设计是一个设计问题。所以我希望你能多谈谈这个,也许你可以分享一些你现在最关心的设计考量。
Yeah, I can see how that's really important in an open-ended AI native product, like finding that building block that unlocks an entire new area of exploration. That's a cool way to think about it. We've been talking a lot about product. I want to zoom out a bit and talk about the org a little bit, because something you said to me is how org design is a design problem. So I'd love to hear you talk a little bit more about that, and maybe you could share some of the design considerations that are top of mind for you right now.
我认为把人匹配到问题上是关键。我以前在脑子里把这想象成篮球暂停时的教练,画战术,对吧?你不是在投篮,但你坐在球员旁边,你说:“好,我的感觉是最好的投篮来自侧翼。你觉得呢?你想试试吗?要么成功要么不成功。你回来,看着白板,说,好,我们试试另一个战术。”但实际上我换了一个不同的教练比喻,那就是更多是关于构建正确的阵容,找到正确的对位,只是把人放在能成功的情境中。这更少是逐回合的,更多是根据比赛状态、比分、对手,我把这三个人放在场上,在这个比喻中是五个人,然后看看会发生什么,看看他们是否适合这个情况、这个问题。我实际上觉得这很有趣。就像我在 Airtable 和 Chad 一起做的那样。
I think matching people to problems is critical. I think in my head I used to think of that as a coach during a basketball timeout, sort of diagramming plays, right? You're not taking the shots, but you're sitting next to the player and you're like, "Okay, my sense is that the best shot is from the wing. Well, what do you think? Do you want to try that? Either it works or it doesn't. You come back, you look at the whiteboard, you're like, okay, we're going to try a different play." I've actually come to a different coach metaphor here, which is it's much more about building the right lineups and finding the right matchups and just putting people in a situation to succeed. And it's much less play-by-play, and it's much more given the state of play, given the score, given the competition, I'm going to put these three people together on the court, five people in this analogy, and sort of see what happens, see if they are the right fit for this situation, this problem. I actually find this pretty fun. Like when I did this with Chad at Airtable.
我们真的有一个包含所有团队、所有项目和所有设计师的 Figma 文件。你只是——重组可不是闹着玩的,你需要谨慎对待。但在管理者探索的安全空间里,你会想,‘你知道吗,如果把这家伙的技术能力、那个人的用户同理心,还有这个人的工艺感,都扔到这个问题上会怎样?’哦,那里还有一个非常热爱用户问题的工程经理。我觉得这个组合能行。这种神奇的化学反应和活力,作为管理者创造出来真的很有趣。
We literally had a Figma of all the teams, all the projects, and all the designers. You just sort of—reorgs are no laughing matter, and you want to be careful with them. But in the safe space of manager exploration, you're like, 'You know what would be interesting? If you took this guy's technical chops, this person's user empathy, and this person's kind of craft, and you threw them at this problem.' Oh, and there's an EM there who really loves user problems. I think that combination could work. There's this kind of magical chemistry dynamism that is really fun to create as a manager.
我脸上带着微笑,因为我能看到你谈论这件事时有多兴奋。听到有人对自己所做的事情真正充满热情,总是非常振奋人心。也许换个方式来了解你作为领导者的表现是:你从之前的经历中——可能是在 Kora 或 Airtable——带了一些什么东西到这个新机会中,并用它来塑造你对设计组织可以成为什么样子的思考?因为在很多方面,你得到了一张白纸。我的意思是,在如何设置和运作方面,你几乎可以做任何事。那么,过去的哪些经历在塑造你处理这个新画布的方式?
I have a smile on my face just because I can see how much you're lighting up even talking about it. It's always super energizing to hear when someone gets genuinely excited about the thing that they're doing. Maybe a different way to learn more about how you're showing up as a leader is: are there different things from your experience, maybe at Kora or at Airtable, that you're kind of taking with you into this new opportunity and using it to shape the way that you're thinking about what the design org can be? Because in many ways you're given this blank slate. I mean, you could literally do anything in terms of how you want this to be set up and function. So what past experiences are shaping how you want to approach this new canvas?
嗯,这是个好问题。我非常坚信产品设计师应该深度嵌入到产品团队中。设计团队总是存在一个从集中式到深度嵌入式的光谱。我非常喜欢深度嵌入的产品设计师。我认为这能建立与产品经理和工程师的关系,让你真正贴近实际的用户问题。我参与过的最成功的团队,我认为,是你把大部分时间花在深入产品思维空间、深入你针对的用户群体、深入与产品经理的合作上。然后你与设计师交流主要是为了评审、团队仪式等。但人们来参加我们的评审时,带着相当成熟的想法来解决他们的问题。我们在评审中做的大部分工作是常规的质量和反馈循环,但也包括协调矛盾、寻找联系,比如‘你似乎在探索这个想法。我在这里看到了一个联系。我们能讨论一下其中的含义吗?’我认为,这比一个主要内部聚焦于设计团队的团队能带来更好的工作和更好的跨职能关系。
Yeah, that is a great question. I'm a huge believer in product designers being deeply embedded in product teams. There's always a spectrum of centralized design teams versus deeply embedded ones. I really like deeply embedded product designers. I think it builds relationships with PMs and engineers, and it gets you just really close to actual user problems. The most successful teams I've been on, I think, are where you spend a majority of your time deep in your product headspace, deep with the user segment you're going for, deep with your PM. And then you're talking to designers basically for crits, for team rituals, etc. But people come to our crits with pretty fully realized ideas that are solving their problems. Then a lot of what we're doing in crits is general quality and feedback loops, but also squaring circles and trying to find connections, saying, 'You seem to be exploring this idea. I see this connection over here. Can we talk through what the implications are there?' I think that leads to better work and better cross-functional relationships than a team that is primarily internally focused on the design team.
嘿,我是 Rid。经常有人问我最喜欢的产品是什么,所以我花一分钟快速介绍一下我的工具栈。Desen 是我用来在不写代码的情况下交付设计变更的工具。Framer 是我用来建网站的工具。Genway 是我用来做研究的工具。Jitter 是我用来给设计做动画的工具。Play 是我用来设计和原型移动应用的工具。Visual Electric 是我用来生成所有图像的工具。而 Raycast 是我每一步的快捷方式。我亲手挑选了这些公司与我合作,这样我就能全职做这些节目了。所以支持这个节目的最好方式就是去看看它们。你可以在 dive.club/partners 找到完整列表。好了,现在继续节目的其余部分。
Hey, it's Rid. I'm constantly asked about my favorite product, so I'm going to take just one minute and give you a quick rundown of my stack. Desen is how I ship design changes without having to code. Framer is how I build my websites. Genway is how I do research. Jitter is how I animate my designs. Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery. And Raycast is my shortcut every step of the way. Now, I've hand-selected these companies to partner with me so that I can do these episodes full-time. So the best way by far to support the show is to check them out. You can find the full list at dive.club/partners. Okay, now on to the rest of the episode.
你提到了评审。你能给我们概述一下你设立了哪些仪式,以及有哪些不同的事情在构建这些不同产品团队的运作方式?
You talked about crit. Can you just give us an overview of what are the rituals that you've put in place and different things that structure the way these different product teams operate?
尽管我希望我们在世界上有强大的声誉和存在感,但我们是一个小而精干的团队。我用过的比喻是:研究团队感觉像一个有 200 年历史的哈佛研究实验室,有惊人的天才在解决困难的技术问题。我们的产品组织感觉更像一个 YC 创业公司,获得了独家接触那些研究的权限,但不是一个拥有所有成熟度的 200 年机构。所以我的回答会比较轻量。我们每周做几次评审。我们在产品内部做评审,而且我们刚刚开始做品牌和产品之间的联合评审。设计组织的另一个让我们非常兴奋的部分是试图与品牌保持同步。我们有一些相当重要的信息要传达给世界。我们的品牌团队由一位名叫 Everett 的出色人士领导,他们正在考虑如何与所有这些不同的受众沟通。我们真的想把这些信息、这些价值观、那个安全使命转化到产品中。所以我们有一个专门的评审,只针对那些重叠的地方:登录屏幕、引导流程、产品内的品牌时刻、文案。所以我们真的在努力依赖这种关系,不让它们偏离,就像我在其他团队看到的那样。我们有一个有趣的 Slack 笔记本文化。我认为这源于我们的研究背景。Anthropic 的大多数员工都有一个专用的公开 Slack 频道,叫做“Joel notebook”或“Rid notebook”,基本上是你想什么的意识流。可以是进行中的工作,你在世界上发现的东西,你想抛到空中看看别人想法的挑衅性文档。这是一个非常神奇的仪式,我从未在其他地方见过,但我现在完全上瘾了。我们的设计师经常发布非常有趣、有挑战性的东西:一个他们因为灵感而在一晚上拼凑出来的原型,然后第二天早上醒来发现它看起来像一场灾难,他们会说,‘我就把它放在这里。我不觉得它好,但我不想让它完全消失在黑暗中。’十次有八次它消失在黑暗中,十次有两次有人注意到它,然后说,‘等等,和这个其他东西的联系。我刚和这个研究员聊过。’这是一个很好的跨组织交叉授粉的事情。研究员有笔记本,设计师和工程师有笔记本,我们在彼此的笔记本里。所以你会发布一些东西,然后一个研究员会说,‘有意思。我刚试了一个新模型,结果发现它在某件事上特别好。我想知道我们能不能把它和这个 UI 配对,做出一些有趣的东西。’反之亦然,方向也是双向的。
Despite what I hope is a strong reputation and a strong presence in the world, we are a small and scrappy team. The analogy I've used is: the research team feels like a 200-year-old Harvard research lab with astonishing geniuses working on hard technical problems. Our product org generally feels a bit more like a YC startup that has gotten exclusive access to that research but is not a 200-year-old institution with all the maturity there. So my answer is going to be pretty light. We do a couple crits a week. We do crits kind of within product, and we just started doing a joint crit between brand and product. Another part of the design org we're really excited about is trying to be in lockstep with brand. We have some pretty big messages we're trying to communicate to the world. Our brand team, led by an amazing person named Everett, is thinking about communicating to all these different audiences. We really want to translate those messages, those values, that safety mission into the product. So we have a dedicated crit just for the places where that overlaps: login screens, onboarding flows, brandable moments inside the product, copy. So we're really trying to lean on that relationship and not let them drift, as I've seen other teams do. We have an interesting culture of Slack notebooks. I think this comes from our research origins. Most employees at Anthropic have a dedicated public Slack channel called 'Joel notebook' or 'Rid notebook', which is basically a stream of consciousness for whatever you're thinking about. It can be work in progress, things you found in the world, provocative documents you want to toss into the ether and see what people think. It's a really magical ritual that I've never seen anywhere else, but I'm completely addicted to now. Our designers are often posting really interesting challenging stuff: a prototype they hacked together in an evening because they were inspired, then woke up the next morning and it looked like a disaster, and they're like, 'I'm just going to put this here. I don't think it's good, but I don't want it to just totally disappear into the dark.' Eight times out of ten it disappears into the dark, and two times out of ten somebody notices it and is like, 'Wait, the connection to this other thing. I just talked to this researcher.' It's a great cross-org pollination thing. The researchers have notebooks, the designers and engineers have notebooks, and we're in each other's notebooks. So you'll post something and a researcher will say, 'Interesting. I just tried a new model that turned out to be really good at this particular thing. I wonder if we could pair that with this UI and make something interesting.' And vice versa, the direction goes as well.
这太酷了。我完全要偷学这个。它极大地降低了可分享的门槛。有很多次我在想一些东西,尤其是不同的原型,可能离路线图很远,但我仍然觉得它们很酷,很难把它们扔到一个公共频道里,因为那几乎感觉像是你分心了。但如果是我自己的……
That is so cool. I will totally steal that. It decreases the bar for what is sharable in a really drastic way. There were so many times where I was thinking of things, especially different prototypes that maybe are not anywhere near the roadmap, but I still think they're cool, and it's hard to dump that into a public channel because it almost feels like you are distracted. Where if it's my own...
Notebook 是一个安全的空间,真的很酷,完全正确。如果你要采用它,我得告诉你它的阴暗面:它会制造很多闪亮的新东西,大部分是积极的,但有时也会分散注意力。我们聊过原型文化和“寻找问题的解决方案”有趣的一面,但没那么有趣的一面是,我们是一个小团队,需要专注、需要优先级、需要快速交付解决实际问题的东西。从“寻找问题的解决方案”这一端伸出的触手越多,你在另一端就需要越多的纪律来说‘这太酷了,但现在不是时候’。我认为交叉授粉和灵感 100% 值得,但它增加了专注和说‘不’的负担。如果你把我们看作一个早期产品初创公司,这正是我们需要的纪律。还有什么我们没谈到的,关于你作为设计领导者如何实践,或者你如何积极激发团队中设计师的最佳状态?我深信心理安全感是冒险的必要前提。看看我们讨论过的很多事:寻找问题的解决方案、公开分享你还不太确定的东西、同时做雄心勃勃的未来工作和短期战术工作——把这些东西公之于众在创意上是冒险的,即使在我们这样规模的组织里也是如此。所以我坚信人们需要感到安全、舒适,并认同自己作为设计师的身份,这很大程度上来自人员管理、人员管理的实践以及我们正在建设的文化。所以我们让 Kim Bost——另一位设计领导者——加入团队,她和我花了很多时间谈论个人,谈论他们所处的情境,他们的天才形式是什么,我们是否在激发那种天才,无论是大方式还是小方式,比如他们没有发挥出最佳状态,我们努力创造空间、创造环境,让每个人都能理解自己的天才,处于一个能让天才得以表达的位置,当他们跌倒时——因为他们不可避免地会跌倒——网就在很近的地方,错误被容忍,甚至被欢迎和鼓励,你在一个支持性的环境中学习,然后重新站起来。我很幸运在我的第一位真正的设计经理 Rebecca Cox 那里体验到了这一点,她在 Kora 工作,她常说‘快速行动,犯一堆错误’。我当时大概是 Kora 的第 10 号员工,每个人都在推送生产代码,我们都在一个房间里:两位创始人、我的老板 Rebecca(她基本上是伪联合创始人)、七个工程师和我。我推送了一个导致网站宕机的更改,我不知道怎么修复,甚至不知道我破坏了什么。某个时刻,CEO Adam 站起来,在这个小房间里摘下耳机,用相当严厉的声音说‘现在需要有人让网站恢复’。有人做了,一切恢复正常。我当时想‘我要被开除了,就这样了,美好的两周,挺有趣的’。就在那一小时里,Rebecca 说‘我们去喝咖啡’,我们走着,她让我发泄,让我感觉糟糕,然后她说‘如果你不破坏网站,你就没有推送足够的东西。这是个好迹象,说明你在尝试、在快速行动、在火线上’。那是关于代码的,但我认为这种精神是我真正在乎的。我希望设计师们大胆尝试,深入决策的核心,这意味着有时会失手。回到教练的比喻,这就是管理存在的意义,这就是你在这里的原因——去理解它,去处理情感后果。高压工作的情感是非常真实的。我认为人们不仅应该被当作完整的人来对待和支持,而且如果你那样对待他们,工作会变得无限好。
Notebook it's a safe space really really cool that's totally right if you're going to adopt it I'll then give you the dark underbelly of it which is it creates a lot of bright shiny things in a sort of like largely positive but of sometimes distracting way and like you know we we talked about the fun part of prototype culture and Solutions in search of problems the not as fun part is like we're a small org we need to focus we need to prioritize we need to deliver things that are shipping fast and solving real problems the more tendrils that are sneaking out of the solutions in search of a problem end of the spectrum the more discipline you need at the other end to say that's so cool it's not for right now I think the cross pollination and the inspiration is 100% worth it but it um it increases the burden of focus discipline saying no which again if you think of us as like in early stage product startup that is a discipline that we that we need anything else that we're not talking about in terms of just how you approach your practice as a design leader or different ways that you are actively trying to bring the best out of the designers on your team I'm just an enormous believer in psychological safety as a necessary precursor to risk-taking if you look at like a lot of the things we've talked about Solutions in search of problems publicly posting things that you don't know good yet trying to do both ambitious futur looking work and near-term tactical work it's creatively risky to put this stuff out in the world and in in even in an organization this the size of ours and so I am a huge believer in people needing to feel secure and comfortable and who they are as designers and that largely comes from just people management the practice of people management and the culture that we're that we're building and so we put Kim bost's uh another design leader on the team um she and I both just spend a lot of time talking about individuals and talking about the situations that they're in what their form of Genius is are we bringing that genius out ways big and small that like they're not bringing their best and we're working to just create the space create the the the environment that each person feels that they understand their own genius that they're in a position back to Staffing where that genius can be expressed and that when they trip because they inevitably trip the net is pretty close and mistakes are say tolerated but like welcomed and encouraged and you learn from them in a supportive environment and you sort of pick yourself back up I was lucky enough to have this in my kind of first true design manager in Rebecca Cox at Kora she was just like move fast and make a bunch of mistakes I was maybe employee 10 at Kora and uh everyone was shipping production code at that time we're all in this room it's like the two Founders my boss Rebecca who is essentially a pseudo co-founder and you know seven engineers and me I pushed a change to uh to production that took down the website and I didn't know how to fix it like I didn't even know what I'd broken at some point Adam the CEO stands up like in this tiny room takes off his headphones and in like a fairly Stern voice was like someone needs to get the site back up right now someone did all fine I was like well I'm gonna get fired like that was it like good two weeks like it's been fun literally like that hour Rebecca's like we're going for coffee we walk she lets me vent she lets me feel bad and then she was like if you're not breaking the site you're not pushing enough this is a good sign this is a sign that you're like trying stuff moving quickly in the line of fire that's about code but I think that ethos is something that I really care about I want designers taking big swings being in the thick of decision making that is going to mean missing some swings back to the coach analogy like that's what management is here for that's why you're you're there to understand it to like deal with the emotional Fallout the emotions of high stakes jobs are very real I I think people deserve to not only deserve to be treated as like whole people and supported in that way but the work gets infinitely better if you if you uh treat people that way
另一件我知道你非常在意的事是面试流程,你甚至称之为‘神圣的’。能谈谈为什么吗?以及这如何塑造了你构建这个流程的方式?我们在 Airtable 和 Anthropic 最终采用的流程可能看起来和其他流程没有太大不同,但我认为有一些小的经验教训,尤其是从 Airtable 学到的,塑造了它。Chad 和我经常讨论的一个问题是:你是否应该给出‘答案’?每个候选人都会问‘你们在找什么?你们想要案例研究 A 还是案例研究 B?’我们争论了很久,回答这个问题——几乎像是直接给出评分标准——是不是不好?我最终坚定地认为,你应该给候选人你的评分标准,让他们尽力展示。这最近体现在我们刚刚招聘了第一位设计工程师。当我理解这个角色的范围时——顺便说一句,现在‘设计工程师’这个伞下涵盖的技能和创意天赋真是令人难以置信——我们最终认为我们关心两种品质:一是深厚的工艺和交互专长,二是系统和规模,以及提升整个团队的工作。所以我们把这两点都写进了职位描述。在面试中,候选人们会说‘我可以展示我自己做的交互,也可以展示我构建的设计系统,你们想要什么?’与其让他们猜测,我们直接说‘对于这个角色,我们寻找的第一个人,我们非常关心工艺和交互卓越,所以我们希望你的作品集 70% 是关于你如何看待执行工艺,另外我们也喜欢看到一些系统和规模的东西。’这样每个人都赢了:我们清晰地看到了我们关心的技能,候选人的体验也更好。我们在 Airtable 做的另一件事,我也带到了这里,是一个生成式练习,一种头脑风暴练习:给候选人一个虚构的机会,让他们即兴发挥一个小时。我认为这有很多好处,一个明显的和一个不那么明显的。明显的是,我认为构思能力是作品集评审中最难筛选的之一。现在的设计师太擅长作品集评审了,他们投入的用心、工艺和叙事水平令人惊叹。
Something else I know you care a lot about too is the interview process you went as far as to call it sacred to me so can you talk a little bit about why and then like how does that shape the way that you structure this process where we've landed both at air table and at anthropic is something that doesn't maybe look all that different from other processes but I think in some small ways some lessons learned especially airable have shaped it so one thing that Chad and I used to talk about a lot is do you give away the answer key the question that every candidate has is what are you looking for like do you want case study a or case study B and we debated for a long time like is it bad to answer that question of sort of like almost literally like what is your rubric and I've just come down strongly on the like you should give candidates your rubric and let them like give it their best shot and so this was manifested very recently in that we just hired our first design engineer and as I was understanding the sort of the scope of the role side note the of skills and creative talents that come under the umbrella of design engineer right now truly mindbending but you know we ended up like thinking there were these sort of two qualities that we cared about one was like deep craft deep interaction expertise the other was like systems and scale and elevating the work of the whole the whole team as a as a unit and so you know we put both of them in the job description we had all these interviews candidates were like hey I can show interactions I've made myself I can show Design Systems I've built like what do you want rather than than having them guess we were like the first role the first person that we're looking for we deeply care about this craft and this like interaction Excellence so we'd like 70% of your portfolio to be about just like how you view the craft of execution as a side note we love to see a few sort of systems and scale things and it just everyone wins like we get a clean look at the skill we care about and the candidate experience I think is much better another thing that we've done another another slot that that we sort of uh had at air table that I ended up bringing over here is a a generative exercise a sort of a a brainstorming exercise you give someone a sort of a a fake opportunity uh and you just sort of like riff for an hour I think there's a lot to like about that one obvious one and one maybe not as obvious one one is just I think ideation is one of the hardest things to screen for in a portfolio review people are designers are so so good at portfolio reviews now I mean it just the level of care and craft and storytelling that people put into these narratives is astonishing
我认为你确实能很好地了解他们的执行能力。但我觉得你不太能了解的是,面对一个奇怪、困难、模糊的问题——顺便说一句,Anthropic 全是这种奇怪、困难、模糊的问题——他们会怎么处理?我们对各种探索方式都持开放态度。你可以是那种在前 10 分钟抛出 100 个想法、知道大部分都是垃圾的人。你可以是框架型的人,思考这个问题的空间有哪些维度,以及如何推理。你也可以是需要 10 分钟独处思考、然后再讨论的人。通过面试的方式有很多,但我觉得通过作品集评审很难评估这项技能。
And I think you do get a good sense for their execution work. I think what you get less of a good sense of is, given a weird, hard, ambiguous problem — side note, Anthropic is nothing but weird, hard, ambiguous problems — where do they go with it? And we were open to lots of different ways of exploring. You could be a throw-a-hundred-ideas-out-in-the-first-10-minutes-and-know-that-most-of-them-are-garbage person. You could be a frameworks person, you could think, what are the dimensions of this problem space and how do I sort of reason through it? You could be an I-need-10-minutes-to-myself-to-just-think-and-then-we-can-talk-about-it person. There's lots of ways to pass this interview, but that's a skill that I found very difficult to assess through portfolio reviews.
它不太明显的好处是,对面试官来说真的很有趣。在 Scaling 公司,你只是要求你的团队每年做几十次面试,因为你希望面试过程可预测且公式化,以公平公正地对待候选人,这对面试官来说可能相当枯燥、无聊和重复。而生成性的内容真的很有趣。我们鼓励面试官参与进来,抛出想法,获得灵感。我在 Airtable 主持了无数次这样的面试。我们有一个面试题目是,如果 Zoom 想添加一个离线社区聚会功能会怎样?我经常对出现的想法感到惊讶。我一直与候选人同在,而不是仅仅等待关键词。我会想,哦,你把这个带到了一个我没想到的方向。让我们稍微玩一下这个。我认为这会带来更好的候选人体验和更好的评估。
The less obvious benefit of it is it's really fun for interviewers. At a scaling company, you're just asking your team to do dozens of interviews a year, and because you want the interview process to be predictable and formulaic in a good way for fairness and equity to candidates, it can just feel pretty dry and boring and repetitive for your interviewers. And the generative stuff is really fun. We encouraged our interviewers to get in the mix and throw out ideas, be inspired. I conducted countless of these at Airtable. We had an interview around like, what if Zoom wanted to add a sort of offline community meetups feature? I was constantly surprised by the ideas that came up. I was constantly present with the candidate. I wasn't just waiting for keywords. I was like, oh, you're taking this in a direction I didn't expect. Let's play with this a little bit. And I think that leads to better candidate experience and a better evaluation.
好了,在你走之前,我想把视角拉远,因为我知道你正在深入思考 AI 的长期影响及其对设计师的影响,比很多没有深入这个领域的人想得更多。所以一个非常宽泛的问题:当你展望未来,想象这可能走向何方时,你现在在想什么?
Alright, before I let you go, I want to zoom all the way out because I know you're thinking a lot about some of the long-term implications of AI and its impact on designers, much more than a lot of people who are not so deeply embedded in this space. So super broad question: what's something that's on your mind right now when you look into the future and imagine where this could be headed?
我是“待办任务”框架的忠实粉丝,该框架中的一个区分是功能性任务与社会和情感任务。我对 AI 能够完成的社会和情感任务非常感兴趣。我认为那里有一个非常丰富、有趣的空间,值得设计去探索。我认为这主要是在应用层。我知道你几周前邀请了 Jason。我认为 Dot 正在以最有趣的方式之一探索这一点,并且真正深入人们需要但生产力工具未能提供的东西。很久以前,我曾与一位用户进行过研究,他心爱的宠物快要死了,他必须决定何时实施安乐死。这是一种在陪伴爱宠和结束其痛苦之间的权衡。他广泛地与 Claude 讨论这件事。每天他都会报告宠物的状况,Claude 会安慰他。这个人分享说,你知道,他今天看起来好多了,我想我可能还能再撑一周。Claude 会说,我想提醒你,昨天是你的低谷之一,不要对这个变化过于兴奋。看到这个模式,我认为我们接近这个你需要跨越的时刻。关于功能性内容的讨论很多。关于 AI 能够工作时会发生什么的经济和社会分析也很多。我认为作为设计师,我们对此负责,并确保一切顺利,但也要关注人性中非功能性的部分,那些关乎我们个人生活、情感、与自己和世界的关系的部分。我认为这项技术在成为伙伴方面的潜力,与在更执行性的生产力领域一样大,甚至更大。
I'm a big fan of the jobs to be done framework, and one of the distinctions made in that framework is functional jobs and social and emotional jobs. I'm really interested in the social and emotional jobs that AI can fulfill. I think there's just such a rich, interesting space there that is ripe for design to explore. I think it is very much at the application layer. I know you had Jason on a few weeks ago. I think Dot is exploring this in one of the most interesting ways and really leaning into the things that people need that productivity tools have not delivered. I did user research with someone a long time ago whose beloved pet was dying and they had to decide when to euthanize. There was this kind of decision of trading off time with this beloved pet versus putting them out of their pain. And they talked to Claude about it extensively. Every day they would sort of report how the pet was doing, Claude would comfort them. And this person was sharing like, you know, he's looking better today, I think I might have another week. And Claude would say, I want to remind you that yesterday was one of your low points and to not get too excited about this change. Looking at this pattern, I think we're close to this moment that you will need to cross. There's so much dialogue about the functional stuff. There's so much economic and societal analysis about what happens when AI can do work. I think as designers, we're responsible for that and that going well, but also the parts of humanity that are not functional, the parts that are about our personal lives and our emotions and our relationship to ourselves and to the world. And I think this technology has as much or more potential to be a partner there as it does in the more executional productivity space.
我想不出比这更美好的结尾了。Joel,这真是太棒了。时间价值极高。听你说话时,我全程都面带微笑。很明显你对此很在意,你对自己的工作充满热情。非常感谢你今天抽出时间与我们分享。
I can't imagine a more beautiful place to end. Joel, this has been so great. Super high time to value. I've just had a smile on my face the entire time listening to you. It's so clear that you care about this, that you're energized by what you're working on. So thank you so much for taking the time today to share a little bit with us.
我很荣幸来到这里。我是这个播客的忠实粉丝,所以谢谢你邀请我。
I'm honored to be here. I'm a huge fan of the podcast, so thanks for having me.
嘿,我是 Red。别忘了,如果你想每周更深入,我会向超过 10,000 名设计师发送邮件,提供这些对话的额外资源和关键要点。所以请访问 dive.club/ 注册。好了,下周见。
Hey, it's Red. Don't forget, if you want to go even deeper each week, I send an email out to over 10,000 designers with bonus resources and key takeaways from these conversations. So head to dive.club/ to sign up. Okay, I'll see you next week.