从技术演示到十亿美元产品：Perplexity 的设计之旅

欢迎来到 Dive Club，我是 Ridd，这里是设计师永不停止学习的地方。本周的嘉宾是 Henry Modisett，他领导 Perplexity 的设计团队。我们将深入探讨他们独特的设计流程思考方式、如何作为创始设计师茁壮成长，甚至还会涉及设计动态界面带来的一些挑战。但为了开始这段对话，我们必须回到最初，因为尽管 Perplexity 如今深受业界喜爱且价值数十亿美元，但当 Henry 最初加入时，这家公司还只是一个技术演示。

Welcome to Dive Club. My name is Ridd, and this is where designers never stop learning. This week's episode is with Henry Modisett, who leads the design team at Perplexity. So we go deep into the unique ways that they think about the design process, how to thrive as a founding designer, and we even get into some of the challenges that come with designing dynamic interfaces. But to start this conversation, we got to go all the way back to the beginning, because even though Perplexity is beloved by the industry and worth billions of dollars today, when Henry first joined, the company was little more than a tech demo.

我之前和两位联合创始人一起工作过，我们在 Quora 共事。当他们创办公司时，他们的背景是机器学习和 AI，他们开始构建东西，试图弄清楚自己想做什么。他们很大程度上只是在探索技术，特别是大语言模型。在某个时候，我想只是开始打勾，有人说‘我们应该有个设计师’，而且我很确定我是他们见过的唯一设计师。所以我运气很好。他们敲了我的门，我最初只是作为顾问进来，帮他们整理一些界面。他们不太确定设计是怎么运作的，但知道需要帮助。那段时间我做了很多从 0 到 1 的咨询，也在做自己的创业项目。我强烈学到的一点是：无论你构建什么，都要让自己容易构建。所以我做的第一件事就是为他们构建了一个组件库。我们不知道产品会是什么，不知道它会如何运作，但它可能需要按钮、网格、字体系统和色彩系统。所以我不仅以每天可以组合一次产品的方式构建了这些，而且让系统非常容易更改。如果我们需要改变颜色、更换字体，我都用 React 为他们构建了这一切，作为第一件事，不知道我们要构建什么。然后这让我们经历了很多快速的迭代。第一个产品是探索自然语言生成 SQL，然后最终我们能够将大语言模型与搜索引擎 API 结合起来，看看会发生什么。自然地，我们只是问问题，看看它能做什么。在最简陋的版本中，它是我用过的最重要的软件。我可能说得夸张，但在 Quora 工作过，思考人们如何获取信息，以及提问和得到答案意味着什么，现状可能是非常慢，可能永远得不到答案。所以，你可以输入任何内容并立即得到回应的想法——这就是围绕大语言模型的聊天体验的美妙之处：无论如何，它总会立即说些什么，即使错了。所以让它工作起来绝对是一个个人的顿悟时刻，给了我很大的信念：如果我们能让这个东西每次人们使用时都很好，并且让人们知道它，那么它怎么可能不是一个重要的产品？我们开始快速行动。我们从 Discord 机器人原型变成了简陋的 React 应用，然后我们在推特上发布了它。我们没有发布策略，我们做错了一切。品牌是我在几个小时内拼凑出来的，没有上市计划。只是让东西工作起来并分享。所以我们构建了它，发了推文，它有点病毒式传播。然后我们构建了第二个只搜索 Twitter 的应用，它很酷，因为它比 Twitter 搜索好得多。Jack Dorsey 转发了它，所以它也火了。我们就这样不断推出这些技术演示。但我们注意到人们一直在使用它。它绝对不是一个真正的产品，我们只是试图展示它可以做到，而且可以快速做到。但我们注意到流量并没有停止。从我的角度来看，那算是开始。然后我们知道我们应该真正利用这一点。

I worked with two of the co-founders previously; we worked together at Quora. When they started the company, their background being in machine learning and AI, they started building stuff, trying to figure out what they wanted to do. They were very much just exploring the technology, specifically LLMs. At one point, I think just start of checking boxes, they someone was like, 'We should have a designer,' and I'm pretty sure I'm the only designer they'd ever met. So I got lucky. They knocked on my door, and I came in really just as a consultant, just to kind of help them get some interfaces put together. They weren't really sure how design worked, but they knew that they needed some help. This was in an era for me where I was doing a lot of 0-to-1 consulting and I'd been doing my own startup. What I really learned very strongly was: regardless of what you build, you need to make it really easy for yourself to build. And so the first thing I did was build a component library for them. We didn't know what the product was going to be, we didn't know how it was going to work, but it probably needed buttons, it probably needed a grid, probably needed a type system and a color system. So I built all that out, not only in a way that you could compose a product once a day if you wanted to, but also in a way that would be very easy to change that system. So if we did need to change the colors, swap out a typeface, I built all this for them in React as the first thing, not knowing what we were going to build. And then that let us go through a lot of very quick evolutions. The first product being an exploration around natural language to SQL generation, and then eventually we were able to combine the LLM with a search engine API just to see what would happen. Naturally, we were just asking questions just to see what it could do. And in the crappiest version of that, it was the most important piece of software I ever used. I'm being dramatic, but having worked at Quora and thinking about how people get information a lot, and what it means to ask a question and get an answer, and how basically the status quo is it could be really slow, it could take forever, it could never happen. So the idea that you could just get your answer, you could type in anything and it would respond — I mean that's the beauty of the chat experience around an LLM: no matter what, it will always say something instantly, even if it's wrong. So getting that working was definitely a personal aha moment that gave me a lot of conviction: hey, if we can get this thing to be good every single time people use it, and we can get people to know about it, then how could this not be an important product? We started going fast. We went from Discord bot prototype to crappy React app, and then we tweeted it. We didn't do a launch strategy, we did everything wrong. The brand was something that I put together in a few hours, there was no go-to-market plan. It was just like: get something working and share it. So we built that, we tweeted it, it kind of went viral. And then we built a second app that searched only over Twitter, and it was cool because it was significantly better than Twitter search. And Jack Dorsey retweeted that, so that went viral. So we were just pumping out these essentially tech demos. But what we noticed is that people kept using it. It was definitely not really a product, we were just trying to show that it could be done and it could be done quickly. But we noticed the traffic didn't really stop. And then that was sort of the beginning from my perspective. Then we knew that we should really try to capitalize on this.

我们来玩个游戏：我现在说的是哪个产品？首先，它在 2023 年被 Product Hunt 评为年度设计工具，就在几周前，它在 Contra Creator Tools Awards 中被评为最佳动画工具。猜不到？这个产品叫 Jitter。它就像 Figma，但用于动效设计，而且现在绝对火爆，理由也很充分。创建高质量动画从未如此简单，他们甚至有一个很好的 Figma 插件，让你一键导入设计。所以如果你还在观望，快去 dive。

Let's play a game: which product am I talking about right now? First, they were named the design tool of the year in 2023 by Product Hunt, and just a few weeks ago, they were named the top animation tool in Contra Creator Tools Awards. Give up? The product is called Jitter. It's like Figma but for motion design, and it is absolutely blowing up right now for good reason too. It has never been easier to create really high quality animations, and they even have a nice Figma plugin so you can bring your designs in in a single click. So if you're still sleeping, head to dive.

不是每件事都需要完美，不是每个方面都同等重要。幂律无处不在。我们必须追求投资回报率，决定我们真正要把什么做得很好，因为这样你才能把精力花在正确的地方。如果文化是这样，那么你就可以说：‘看，这个体验需要痴迷，我们要回去反复打磨直到它准备好。’如果你建立一种文化，让人们真的觉得这是他们的孩子，当它不够好时他们会失眠，那么这种事自然会发生。它不需要成为流程的一部分。如果不够好，那会很尴尬。这不是流程问题，而是授权问题。

Not everything needs to be perfect, not every surface area is equal. There's power laws everywhere. We have to chase ROI in terms of what we are actually going to make great, because then you get to spend that right. If that's the culture, then you can be like, 'Look, this experience needs obsession, and we are going to go back and we're going to work on it until it's ready.' If you build a culture where people really feel like this is their baby and they lose sleep when it's not as good as they want it to be, this stuff just happens. It doesn't need to be like part of the process. It's embarrassing if it's not good. It's not like a process problem, it's just like an empowerment problem.

听你谈到组件系统是第一步，这很有意思，因为我注意到现在有一种情绪变化，人们开始有点反设计系统了，钟摆又摆回来了。我们有点把洗澡水连同孩子一起倒掉了。就好像在说，不，我们不能考虑组件。但实际上，你应该优先考虑组件，因为你不知道要构建什么，这很有意思。就像 Notion 的 Ivan 说，我们没有设计系统。我想我明白他的意思，但又不完全明白，因为你的工程团队不可能不写可复用的代码，否则他们工作做得不好。所以我猜他指的是 Figma 里的设计系统，那确实可能浪费时间。但你必须——我的意思是，当你在代码里创建一个按钮时，你肯定不想每次都重写，你也不希望人们能在产品不同部分添加不同字体。所以如果真是这样，那你其实有设计系统，对吧？我的意思是，这只是语义上的争论，而且并不重要。因为你需要产品感觉一致，同时也要让工程团队轻松——你怎么能不写可复用的代码呢？重点就是快，就是让生活轻松，不重复造轮子。事实的真相是代码，因为那是用户交互的东西，对吧？

It's interesting to hear you talk about the component system as one of the first steps, because I think there is this sentiment change happening right now that I'm noticing where people are kind of becoming anti-design systems and the pendulum swinging back. We kind of throw the baby out with the bathwater a little bit. It's like, no, we can't think about components. And it's like, no, you actually prioritize components because you didn't know what you're going to build, which is interesting. Like Ivan from Notion said, oh, we don't have a design system. And I think I know what he means by that, but I don't know what he means, because there's no way your engineering team isn't writing reusable code. Like, otherwise they're not doing a good job. So I'm assuming he means like in Figma, which yeah, sure, I mean that's probably a waste of time. But you got to make—I mean, surely when you're making a button in the code, you don't want to rewrite that every time, and you don't want it to be like—you don't want people to be able to add different typefaces and different parts of the product. So if that's true, like you've got a design system, right? I mean, we're just—it's just like semantic, it's just a semantic argument, and it's not a very important one. Because you need the product to feel coherent, and then you also need to make it easy for your engineering—how could you not write reusable code? The whole point is to go fast, the whole point is to make your life easy, and not reinvent the wheel. The ground truth is the code, because that's what users interact with, right?

我想让自己更容易构建新功能。我认为交互元素和功能之间有非常清晰的区分，我想给自己一个工具箱，这样即使不知道产品具体是什么或如何运作，也能很容易地组装出产品体验。比如，有些东西是绝对需要的：你需要按钮，需要能在屏幕上显示文字，需要色块等等。所以过去几年我建立的任何初创公司，这总是我做的第一件事，因为它让我能快速行动，让我能随意摆弄，而不会卡在某个具体事情上。

I wanted to make it really easy for myself to build new features. I think there's a very kind of clean distinction between interactive elements and features, and I wanted to just give myself a toolbox so that, not knowing exactly what the product would be or how it would work, I could make it very easy to assemble that product experience. Like, there's stuff that you absolutely need: you need buttons, you need to be able to put text on the screen, you need blocks of color and things like that. So any startup that I've built over the last couple years, that's always the first thing I build, because that lets me go fast and lets me kind of tinker and not be stuck in any specific thing.

好的，那我们继续讲故事。然后你有了这一套原始的技术演示，很明显有些东西在那里，现在你有点负责帮助普通人建立对 Perplexity 的好感。你能谈谈你对 Perplexity 整体创意方向的策略吗？以及让这个品牌面向消费者需要做些什么？

Okay, so let's keep going in the story. Then you have this raw set of technology demos, it's very clear that something is there, and now you're kind of responsible for helping everyday people build an affinity with Perplexity. So can you talk a little bit about your strategy for the creative direction for Perplexity as a whole, and also what did it take to consumerize this brand?

当然。我最初的很多贡献就是思考，好吧，鉴于这项技术的工作原理，什么能让它对人们有用？它如何真正融入人们的生活？这让我试图找到一个非常口语化的框架，那就是“答案”——任何人都能理解的东西。这也是我熟悉并思考的东西，所以我知道它在概念上能引起共鸣。人们每天都需要知道事情，无论你是高中生、投资银行家，还是在酒吧里争论的人，对吧？这真的很普遍。所以我认为你的问题有一个产品机制层面的答案，那就是产品需要超级精简。有一些消费品设计原则能让产品真正成功。但首要的是，它必须快——不仅是技术上的快，还需要认知上的快。它需要容易理解、容易尝试。你不能让用户做任何工作。它必须有非常好的默认设置。它需要完美运行，用户几乎不需要思考。当时的市场全是疯狂的技术演示。没有什么是容易理解的，一切都非常复杂，框架非常 AI 导向，更多的是摆弄和享受我们当时都沉浸其中的新奇效应——比如，天哪，这些模型太酷了，它们能做不同的事情，有些网站可以并排运行两个模型，比较差异，对吧？那些东西很惊人，但那不是消费品。所以知道这个区别在初期帮助很大。就像，好吧，我们正在努力做一个人们会放在手机上、每天在世界各地使用的应用。这才是这项技术的优势——不是技术本身，而是包装、框架以及贴近用户的方式。所以有一个产品机制层面的答案，我认为中间还有一点，对我来说，Perplexity 是一个赋予你力量的工具。它就像一个地铁系统，像一个公用事业。你使用它并从中获得价值。产品应该不碍事。你不应该思考产品，不应该体验产品，你应该获得价值。品牌在你使用时应该退居幕后。与此相关的一个重大决定是，我们在多大程度上将 AI 拟人化，甚至提及 AI。我真的不希望人们在使用 Perplexity 时思考 AI。我希望他们思考我需要知道什么，然后直接问，然后放下手机。对我们来说，就是让我们非常擅长提供答案，但我们可以做到不谈论 AI，因为 AI 只是它的工作方式。我认为人们并不真正关心事物如何运作，他们只想要价值。尤其是当你构建一个免费消费品时，它只需要好用和快速——仅此而已。所以在品牌方面，我认为品牌战略是一场对比的游戏。我们所有的竞争对手——各种类型都有。尤其是在初期，就像，好吧，有很多其他初创公司，我们如何脱颖而出？嗯，在每个小细节上都做得与众不同。不把自己定位为 AI 公司，与一家通常不做科技领域的品牌机构合作——这会导致不同的美学结果。而且，从一开始就投资品牌，比其他人可能更早，因为嘿，这突然让我们看起来比实际大得多，让我们显得比实际严肃得多。所以投资那种门面。我还认为，品牌战略的很大一部分，尤其是对初创公司来说，应该是为了招聘。这实际上是你在初期获得的大部分价值。人们希望为让他们自豪地穿在身上的东西工作。所以如果你想做大……

Yeah, for sure. A lot of my original contribution was just getting to think about, okay, given how this technology works, what would make it useful for people? How does it actually fit into people's lives? That led me to try to find a very colloquial framing, which is 'answers'—something that anyone can understand. It's also something I'm familiar with and thinking about, and so I know that it resonates conceptually. People need to know things every day, whether you're a high school student or an investment banker or you're selling an argument in a bar, right? It's truly very universal. So I think there's sort of a product mechanics answer to your question, which is the product needs to be super streamlined. There are a few consumer product design principles that make a product actually successful. Primarily, though, it needs to be fast—and not just technically fast, but it needs to be cognitively fast. It needs to be easy to understand, easy to try. You can't make the user do any work. It has to have really good defaults. It needs to just work perfectly without the user barely even able to think about it. The market at that time was just all crazy tech demos. Nothing was easy to understand, everything was really complicated, very AI-forward in the framing, more about tinkering and enjoying the novelty effect that we were all in—like, oh my God, these models, they're all so cool, they can do different things, there's websites where you can run two side by side and see compare the difference, right? That stuff's amazing, but that's not a consumer product. And so just kind of knowing the difference helped a lot at the beginning. It's like, okay, we're trying to make an app that people are going to put on their phones and use every day all over the world. That's the upside of this technology—it's not the technology itself, it's the packaging and the framing and the sort of meeting people where they are. So there's a product mechanics answer, and I think there's something in the middle, which is for me, Perplexity is a tool that you use that empowers you. It's a like a subway system, it's like a utility. You are using it and getting value out of it. The product should be out of the way. You shouldn't be thinking about the product, you shouldn't be experiencing the product, you should be getting the value. The brand is really meant to be pulled back when you're using it. And a big decision with that is to the extent that we do or do not anthropomorphize the AI or even mention the AI. I really don't want people to have to think about AI when they're using Perplexity. I want them to think about what do I need to know, and then just ask for that, and then you put your phone away. For us, it's just kind of been, let's just be really good at answers, but we can do it in a way without really talking about AI, because the AI is just how it works. And I don't think people really care how things work, they just want the value. And especially when you're building a free consumer product, it just has to work and it has to be fast—that's pretty much it. So then on the brand side, I think brand strategy is a game of contrast. All of the different competitors that we have—it's a bit of everything. Especially at the beginning, it was really like, okay, there's a lot of other startups, how do we distinguish ourselves? Well, do things differently than everyone else at every little detail. Not presenting ourselves as an AI company, going and working with a brand agency that doesn't normally do tech—that kind of leads to a different aesthetic outcome. And also just kind of investing in brand in the first place, like earlier than maybe anyone else would have, just because hey, suddenly it lets us look a lot bigger than we are, it lets us kind of appear a lot more serious than we are. So investing in that sort of facade. I also think a big part of brand strategy, especially for a startup, should be about recruiting. That's like actually most of the value you get at the beginning. People want to work for something that they're proud to wear. So if you're trying to be big and...

你知道你需要招聘很多人，你必须投资品牌，这会带来回报，然后它就会变成一个自我实现的预言，产品和公司之所以成功，是因为你打造了一个能吸引人才的品牌，就这样。我肯定想聊聊招聘和人员方面，但也许在此之前，我想多了解一点你在 Perplexity 担任唯一设计师的那段时间。你的初始角色是否以其他方式存在于我们想象的传统设计师框架之外？

You know you need to hire a lot of people, you have to invest in brand that's going to pay dividends, and then it becomes a self-fulfilling prophecy where the product in the company becomes successful because you made a brand that recruited people, and there you go. I want to talk about the recruiting and people part for sure, but maybe before we get into that, I want to learn a little bit more about your role as the only designer for this chunk of time at Perplexity. Were there other ways that your initial role existed outside of the traditional designer box that we imagine?

我认为在初期，作为创始设计师，你能拥有的美好篇章就是那种“不惜一切代价”的心态。我喜欢思考产品策略，喜欢思考设计，也喜欢做工程。我想弄清楚我们在构建什么以及为什么，我想尽快让一些东西跑起来，看看我们是否找到了方向。所以我认为我的优势在于那个快速探路并具备相应技能的阶段。你知道，很快做出一个可交互的东西让我很开心——让东西跑起来，分享出去，然后看别人尝试使用它。所以我初期的大部分工作就是那种快速开发，让产品体验跑起来并塑造它。我经历了无数次迭代：尝试某个东西，自己讨厌它，修改它，分享它，等等。如果你在这方面变得非常擅长，作为初创公司你更有可能存活下来，因为在早期以那样的节奏运作时，你可以更快地排除或加倍投入。

I think at the beginning, you know, the sort of beautiful chapter that you get to have of being a founding designer is the kind of whatever-it-takes mentality. I love thinking about product strategy, I love thinking about design, and I love doing engineering. I want to figure out what we're building and why, and I want to get something working as fast as we can to sort of see if we're onto something. So I think my strength is that era of just rapidly pathfinding and having the skills to do it. You know, getting to an interactive thing really quickly makes me happy — to get something working, to share it, and see somebody try to use it. So a lot of my job at the beginning was just that rapid development of getting the product experience working and shaping it. I went through a million revolutions of just trying something, hating it myself, changing it, sharing it, whatever. If you get really good at that, you're much more likely to survive as a startup because you get to rule out or double down more quickly when you're operating at that much pace in the early days.

你的迭代有多少是受外部反馈启发，又有多少是来自你自己的品味和判断？

How much of your iterations are inspired by outside feedback versus your own taste and judgment?

我会说大约 90% 来自我自己的品味和判断，因为如果你想构建新颖的东西，大多数人不会帮你做到这一点。你必须坚持到底，你必须有一些信念，你必须在脑海中有一个北极星。有很多方法可以探索，但我认为即使你做了线框图或原型，并在那种工具中达到了那个北极星，你也不能真正与他人分享，因为他们不会以真实的方式体验它，所以你学不到太多东西。我的意思是，你可能会得到一些视觉反馈，但在这个阶段这几乎没用。你真正需要确保的是你在构建一个能为某人做点什么的产品。有实用型产品，也有娱乐型产品。如果是实用型，它必须有用——必须有用到让替代方案突然看起来很糟糕。我认为得出这个结论并不难，但你必须看到你正在构建的最终状态。你必须对它是什么有一些愿景，并且必须有信念坚持到底。我认为在半途获得反馈通常并没有那么有帮助，除非你们有共同的愿景。

I would say like 90% my own taste and judgment, because if you want to build something novel, most people are not going to help you do that. You have to see something through, you have to have some conviction, you have to have some North Star in your head. There are a variety of ways to explore that, but I think even if you did mockups or prototypes and got to that North Star in that type of tool, you can't really share it with other people because they're not going to experience it in the real way, and so you're not going to learn that much. I mean, you might get like visual feedback, but that's pretty useless at this stage. You really want to make sure that you're building a product that is doing something for somebody. There are utility products and then there are entertainment products. If it's utility, it's got to be useful — it's got to be so useful that the alternative looks pretty bad suddenly. I think it's not that hard to come to that conclusion, but you have to sort of see the end state of what you're building. You have to have some vision for what that is, and you have to have the conviction to see it all the way through. I think getting feedback halfway through often isn't actually that helpful unless you've got the shared vision.

你能多分享一点你的工程背景吗？你已经提到过几次代码了。比如当你朝着这个北极星冲刺时，尤其是在非常早期，你写代码的比例是多少，相比之下在设计工具或其他东西中探索的比例又是多少？

Can you share a little bit more about your background with engineering? You've mentioned code a couple times now. Like when you are sprinting at this North Star, especially in the very early days, how much are you writing code versus exploring in design tools or something else?

我一直以设计师的身份工作，但我的大部分工作都写过 UI 代码。当我在用户实际使用的环境中工作时，它能帮助我更清晰地思考。它帮助我更快地建立这种同理心，思考流程、悬停状态、细节。比如，当你加载浏览器，窗口大小很奇怪时，它是否仍然合理？因为一切都是如此动态。我有点厌倦静态的表示——它缺少所有真正重要的细节。我说在这一点上，我在静态工具中有点不舒服。显然我会做颜色探索或餐巾纸草图，比如这里有一些灰色框来设置网格，或者这里有一些布局选项——这些东西显然快得多。但任何交互式的或应该是真实的东西，我在代码中更自在。这大概就是我的大脑运作方式。然后好处是，当我把设计做对了，我们就完成了。你完成了。是的，或者我在网站上发现一个 bug，我就去修复它。我对产品有情感依恋，对吧？就像这是我的东西，我做的，如果它不好我会彻夜难眠，因为我是唯一能让它变得更好的人。我认为在初创公司拥有这种感觉很重要——一种生死攸关的心态。当你自己写代码时，你知道只有你一个人。所以我给别人看，他们发现一个 bug，我会受伤。我想，我需要那个 bug，但我能修复它。我被赋予了权力。这是赋权和问责的结合。正因为如此，产品中融入了很多爱。

I've always worked as a designer, but most of my jobs I've written UI code. It helps me think more clearly when I'm working in the environment that users are actually going to use. It helps me kind of build this sort of empathy quicker, thinking through the flows, the hover states, the details. Like, okay, when you load up your browser and it's in this weird size, does it still make sense? Because everything's so dynamic. I get sort of bored in a static representation of that — it's missing all the details that really matter. I say at this point I'm kind of uncomfortable in a static tool. Obviously I'll do things like color exploration or I'll do napkin sketches, like okay here's some gray boxes that kind of set the grid, or here's some layout options — that stuff is obviously way faster. But anything that's interactive or meant to be the real thing, I'm more comfortable in code. This is kind of how my brain works. And then the nice thing is, when I get the design right, well, we're done. You're done. Yeah, or I find a bug on the site, I go fix it. I have an emotional attachment to the product, right? It's like this is my thing, I made this, and I lose sleep overnight if it's not good because I'm the only one that can make it better. I think that's an important feeling to have in a startup — sort of a live-or-die mentality. And when you're the one writing the code, you know it's just you. So I'll show somebody and they'll find a bug, and I'll be hurt. I'm like, I need that bug, but I can fix that. I'm empowered. It's sort of the combination of empowerment and accountability. There's a lot of love that comes through in the product because of that.

这让我想起 Dan Levita 说过的话，他是 Play 的联合创始人之一。他谈到你离最终产品越抽象，你感受到的责任就越少。所以听到你谈论另一面很有趣。

It reminds me of something that Dan Levita said, one of the co-founders of Play. He talked about how the more abstracted you are away from the end product, the less accountability you feel. So it's interesting to hear you talk about the flip side of that.

是的，没错，这说得通。作为设计师的挑战总是保持那种同理心，并努力记住第一次看到和使用它是什么感觉。你想稍微清空一下头脑，出去走走再回来重新看或重新尝试。我认为当我在代码中工作时，对我来说更容易达到那种状态。

Yeah, no, that makes sense. The challenge of being a designer is always sort of maintaining that empathy and trying to remember what it's like to see this and use this for the first time. You want to clear your head a little bit, go outside and come back and look at it again or try it again. And I think it's so much easier for me to get to that when I'm working on it in code.

我们不仅仅是在朝着产品可能的愿景冲刺；你还在从零开始设计 Perplexity 的流程和设计文化。你之前对我说过一句我觉得很酷的话：你说“整个事情就是一个激情项目，以及我希望它如何运作”。是的。这在 Perplexity 的设计运作方式中是如何体现的？

We're not just sprinting at this vision for what the product can be; you also are kind of designing the process and the design culture at Perplexity from the ground up. And something that you said to me that I thought was pretty cool: you said "the whole thing is a passion project and how I wanted it to work." Yeah. How is that reflected in the way that design operates at Perplexity?

当我身处一个流程非常僵化的团队时，我总感觉格格不入。很久以前我在 Gmail 工作过，但那时我们用的是 Photoshop，流程是每个人都需要探索他们每个想法的五个版本，我们会打印出所有想法并贴在板上，然后大家聚在一起给反馈。当时我觉得那有很多问题，特别是因为 Gmail——在不实际使用的情况下很难对邮件产品做出决策。它是一个动态系统，你知道。所以即使你想评估像未读指示器长什么样这样的基本问题，直到你尝试它并可能错过一封邮件……

I've always felt like a fish out of water when I've been on a team that has a very rigid process. I worked on Gmail a long time ago, but at that time we were using Photoshop, and the process was everyone needs to explore five versions of every idea they have, and we would print out all of our ideas and put them on a board, and everyone would huddle and give feedback. At the time I felt there were a lot of things wrong with that, specifically because Gmail — it's really hard to make decisions about an email product without actually using it. It's a dynamic system, you know. So if you're trying to evaluate even a basic thing like what the unread indicator looks like, until you try it and maybe miss an email...

那对你来说很重要。你连那个微小的 UI 决策都无法真正自信，更不用说任何更深层的产品机制了。我接下来做的一件事是在 Quora 工作，那里有非常严格的设计流程，但方式不同：每个设计师都在写代码，就像我们一开始写 Python 那样。这也导致在那里工作的是特定类型的人，我们的技能和优势存在某种集体局限性。我的意思是，这确实带来了特别的东西，但经历这一切后，我的感觉是：我想建立一个不同类型人的集合体，而不是围绕流程或技能持有某种教条。我认为很多公司会觉得这就是理想的设计师，比如他们应该这样思考我们的产品，而我想把它颠倒过来。我想引进那些思维方式不同、背景不同的人，并创造一种交叉授粉的文化。我试图做的本质上是吸纳那种会成为创始设计师的人——非常全能，有坚持到底的毅力，有能力树立旗帜并对一个想法有信念，然后有能力沟通和传播。所以这些人非常独立、自我驱动且多才多艺。如果你有一群这样的人，那么你就有了一个有趣的团队。我喜欢用的笑话是，就像《十一罗汉》的劫案蒙太奇：你组建一个团队，每个人都带来某种完全不同的技能，但正是这些技能的总和导致了劫案的成功。所以我认为我围绕这一点建立的过程是某种程度的去中心化。我首先最关心的是我们行动要非常快，所以思考设计团队可能拖慢公司速度的所有方式，并试图消除过度探索、过度批评和辩论、过度痴迷于视觉设计。相反，我们没有固定的每周评审之类的。我们更多地谈论产品机制，思考它如何运作。对于任何项目，我会尝试在 Notion 和文档中写下：这是愿景，这是它应该如何工作，让我们开始构建。每个人都有很多自主权，每个人都能发布很多东西。不然我们在做什么？我们试图为世界上的用户制作软件，我想感觉自己做了很多东西，并与世界、与朋友分享了很多东西。我希望我们团队中的每个人都能带着一座可以分享的工作大山离开，看看我做的所有事情。我可能很累，但我很自豪。

That was important to you. You can't really be confident in that tiny UI decision, let alone any deeper product mechanics. The next thing I did was I worked at Quora, which had a very strict design process in a different way, where every designer was coding like when we were writing Python at the beginning. And that also led to a certain type of person working there, and there was sort of collective limitations of our skills and our strengths. I mean, it certainly led to something special, but my feeling coming out of all of that was I want to just build a collective of different types of people rather than have a dogma around process or skills. I think a lot of companies will feel like this is the sort of ideal designer for like this is how they're supposed to think on our product, and I'd like to flip that upside down. I want to bring in people that think different ways, that have different backgrounds, and sort of create a culture of cross-pollination. What I'm trying to do is essentially take the type of person who would be a founding designer, so someone who's very versatile, has the grit to sort of see things through, has the sort of ability to plant flags and have conviction about an idea, and then the ability to sort of communicate and evangelize. And so these people are very independent and sort of self-motivated and versatile. And so if you get a bunch of those people, well then you've got like kind of an interesting team. The joke I like to use is it's like your you know the Oceans 11 heist montage: you're putting together a squad and they all bring some kind of totally different skill, but it's like the sum that leads to the heist. So I think the process that I've tried to build around that is one of a bit of decentralization. I really care first and foremost that we go really fast, and so thinking about all the ways in which a design team can slow down a company and trying to just get rid of that over exploration, over sort of critique and debate and talking, over sort of obsession on visual design. Whereas instead we don't have like a fixed critique on you know every week or anything like that. We talk much more about like product mechanics, thinking about like well how's it going to work. And you know like I'll any project I'll try to just write in Notion and a doc, say here's the vision, here's how it should work, let's start building. Everyone has a lot of ownership and everyone gets to ship a lot of things. What are we doing otherwise? We're trying to make software for humans out in the world, and I want to feel like I made a lot of stuff and I got to share a lot of things with the world, with my friends. I want anyone that has a chapter on our team to sort of walk away with this mountain of work that they can share, look at all the stuff I did. You know, I'm maybe exhausted but I'm proud.

好的，我想深入探讨这种“不惜一切代价追求速度”的心态。你列出了三个类别：花太多时间在设计辩论、设计探索和视觉设计上。是的，也许我们可以逐一讨论，看看实际上需要做什么来确保你不会在这些方面花太多时间。对于辩论，你提到了文档。我的假设是，可能需要一定程度的自上而下的愿景，以确保速度而不过度辩论。这个策略还有更多内容吗？

Okay, so I want to go pretty deep on this velocity at all costs mentality. You listed three categories: spending too much time on debating designs, exploring designs, and visual design. Yeah, and maybe we could even just touch on each individually to figure out what actually needs to happen to ensure that you're not spending too much time on these. So for debating, you mentioned the documents. My assumption is that maybe there is a level of top-down vision that is required to ensure velocity without over debating things. Is there more to that strategy?

我认为首先你必须有一个非常清晰的决策结构，对吧？人们需要知道谁在做决定，项目中的设计师需要知道他们可以自己做决定，或者知道我可以做决定，然后事情就结束了。你知道，它不需要得到一大堆人的批准。组织需要以重视果断的方式建立，因为另一种选择就是死亡。如果是用户体验的问题，产品上的设计师只需要决定。如果他们需要帮助或反馈，那就为这个问题建立一个智囊团。我期望每个人都这样做，对吧？你不应该孤立地工作，但你应该知道什么时候需要帮助，或者什么时候帮助实际上是有用的。很多时候反馈其实并没有那么有帮助。当你发现某些东西可以改进时，这很容易看出来。在微观层面，我认为我们整天都在做很多小决定，其中大多数并不那么重要。所以最好相信你的第一直觉，然后把它发布出去。真正的答案是，如果你如此痴迷于快速前进，那么你上周做的不喜欢的东西，这周就可以修复它。你并不是把所有这些半成品都抛在脑后。这是一个持续的迭代过程。尤其是对于像我们这样的产品，用户体验是完全非确定性的——每次使用你都会得到不同的东西，不同的结果，对吧？所以对我来说，让任何东西先跑起来非常重要，然后像捏粘土一样痴迷于它，直到你觉得它足够好。然后你就完成了。如果还不够好，下周你可以做一个新的。这并不难。

I think first and foremost you have to have a very clear decision-making structure, right? People need to feel like they know who makes decisions, and designers on a project need to feel like they know that they can make a decision or they know that I can make a decision and that's the end of it. You know, it doesn't need to get approval from a bunch of different people. The organization needs to be set up in a way where decisiveness is valued, because the alternative is death. If it's a question of user experience, the designer on the product needs to just decide. And if they want help or feedback, build a brain trust for this problem. And I expect everyone to do that, right? You know, you shouldn't work in isolation, but you should be able to know when you need help or when help would be actually helpful. Right? Like a lot of times feedback is actually not that helpful. It's pretty easy to spot when you know that something could be better. And on a micro level, I think there's a lot of little decisions that we make all day, and most of them don't matter that much. And so it's better to just go with your first gut and get it out the door. The real answer is if you're so obsessed with going fast, then whatever you did last week that you don't like, you can now fix it this week. It's not like you're just leaving all this half-thought-through stuff in the dust. It's a constant iteration. And especially with a product like ours where the user experience is completely non-deterministic—every time you use it you get a different thing, you get a different outcome, right? And so it's really important for me to get anything working and then just kind of obsess over it like molding clay until you feel like it's good enough. And then you're done. And then if it's not good enough, you can make a new one next week. It's not that hard.

那么，只要你投资了创造的速度，对吧？但如何创造一种文化，让你真正回去改进东西呢？我听过很多领导者谈论这个，但最终发生的是你没有尽可能多地探索，你在一些视觉设计上偷工减料，然后你把一些线性任务移到一个快速跟进桶里，然后你再也不看它们了。你在两个季度内这样做了 15 次，然后你发现产品有点像一个弗兰肯斯坦，整体感觉很差。尤其是作为一个消费产品，你与其他拥有非常高标准的界面竞争。当你不惜一切代价优先考虑速度时，如何确保不会陷入那种境地？

So then as long as you've invested in the pace of creating, right? How do you create a culture where you actually do go back and improve things though? I've heard a lot of leaders talk about this, and then what ends up happening is you don't explore as much as you can, you cut corners on some visual design, and then you move some linear tasks into a fast follow bucket, and then you never look at them again. And you do that 15 times over two quarters, and the next thing you know you have a little bit of a Frankenstein product where you feel it in aggregate. Especially as a consumer product where you're competing against other interfaces that have really, really high bars. How do you ensure you don't end up in that place when prioritizing velocity at all costs?

对这个问题的第一个答案是，并不总是值得回去改进，这是设计师必须接受的。不是每件事都需要完美。不是每个表面区域都同等重要。幂律无处不在。移动网页上的设置页面不如 iPhone 上的好，这没关系。这有点“欢迎来到现实”的价值。我们必须根据我们实际要做得好的东西来追求 ROI，因为这样你才能把精力花在那里。对吧？如果那是文化，那么你可以说，看，这个体验需要痴迷，我们会回去，一直工作到它准备好。我可以打出这张牌，因为否则我对其他事情很谨慎。如果我对每件事都这么说，那每件事都……

The first answer to the question is it's not always worth going back, and that's something designers have to accept. Not everything needs to be perfect. There's like not every surface area is equal. There's power laws everywhere. It's okay that the settings page in mobile web isn't as good as the one in the iPhone. And there's a bit of a welcome to reality value. We have to chase ROI in terms of what we are actually going to make great, because then you get to spend that. Right? If that's the culture, then you can be like, look, this experience needs obsession, and we are going to go back and we're going to work on it until it's ready. I get to play that card because I'm otherwise quite thoughtful about it. If I said that about everything, everything's...

很重要，每个小角落都需要完美。好吧，那我们要花很久才能做出任何东西，而且我也没有那种可信度，对吧？但如果我说，好吧，大多数时候这没那么重要，而且你知道，我觉得显然有一个最低标准，对吧？达到那个最低标准的方法是有一个好的组件库。应该很难做出看起来很糟糕的东西。应该很难编程出看起来很糟糕的东西。所以就有那么一个层次，你知道，我不想发布任何糟糕的东西。但无论是下拉菜单还是模态框，这些都是你可以争论的东西，我觉得你应该稍微争论一下，但你应该相信你的直觉，如果你以后想改，你可以改。

Important, every little corner needs to be perfect. Well, it'll take us forever to build anything, and I also would kind of not have the credibility, right? But if I'm like, okay, most of the time this isn't that important, and you know, I think obviously there's a minimum bar, right? And the way you get to that minimum bar is with a good component library. It should be really hard to make something that looks shitty. It should be hard to program something that looks shitty. So there's like that level of, you know, I don't want to ship anything bad. But whether it's a dropdown menu or a modal, those are things that you could debate, and I think you should a little bit, but you should go with your gut, and if you want to change it later, you can.

我认为我和我们团队的小窍门是，如果你有会写代码的设计师，这种事自然就发生了。我会回去修复东西或让东西变得更好，只是因为我有一个小时。这不像是一个流程问题，而是一个授权问题。或者如果你有设计工程师，他们有那些价值观，不管是什么，对吧？如果你建立一种文化，让人们真的觉得这是他们的孩子，当它不如他们想要的那样好时他们会失眠，这种事就会发生。它不需要成为流程的一部分。如果它不好，那很尴尬，对吧？我就是这么觉得的。如果你让那发生，如果你创造那种文化并授权那些人，当然作为领导者，我也想一直奖励那些这样做的人。我团队里的某个人会主动进去把某个小东西做得非常好，然后我想确保他们因此得到认可，因为那是我会做的事。这就是小窍门：如果你有会写代码的设计师，或者你有真正关心并感到被授权的设计工程师，那么这种事情实际上会自动发生。

I think the hack that I have and that our team has is, if you have designers that code, this just happens. I'll go back and fix things or make things better just because I have an hour. It's not like a process problem, it's just like an empowerment problem. Or if you have design engineers that sort of have those values, like whatever it is, right? If you build a culture where people really feel like this is their baby and they lose sleep when it's not as good as they want it to be, this stuff just happens. It doesn't need to be part of the process. It's embarrassing if it's not good, right? That's how I feel. If you let that happen, if you create that culture and empower those people, and also of course as a leader I want to reward people for doing that all the time. Someone on my team will just go in and make some little thing really nice unprompted, and then so I want to make sure that they're acknowledged for that, because that's what I would have done. That's the hack: if you have designers that code or you have design engineers that really care and feel empowered, then this kind of thing actually just happens automatically.

我喜欢流程问题与授权问题之间的区别。所以你是对的。我在不同类型的环境中工作过，当我接入代码库时，我可以自己创建 PR 并修复东西。我这样做是因为我想做，而且我对一个小交互或修复悬停状态或某种溢出错误感到深深的自豪。而当我远离代码，必须通过工程师时，这给初始发布带来了更多压力，因为我知道我将不得不再次向别人推销为什么他们应该花时间做这个，而不是他们那周被期望做的工作。

I love the distinction between a process problem versus an empowerment problem. So you're right. I've worked in different types of environments where when I am hooked into the codebase, I can spin up my own PRs and just fix things. I do it because I want to, and I take a deep level of pride in a little interaction or fixing a hover state or some kind of an overflow bug. Whereas when I'm removed from the code and I have to go through engineers, it puts more pressure on the initial release, because I know that I'm going to have to effectively resell all over again to someone else on why they should take the time to do this, versus what they're being expected to work on that week.

当然。你最后说的那点就是一切消亡的地方，对吧？即使你和一个工程师合作，他说“哦，100%，我同意你，这完全值得修复或改进”，但然后他说“但我的老板让我做另一件事，我必须做”。就像我一开始说的，有时那完全正确。我们都必须有战略品味，知道什么值得花时间。但我认为很多缺乏打磨的地方其实很容易修复，只要你从一开始就让它容易修复。甚至回到我们开始谈话的地方，我完全没计划，但就像 Notion，对吧？我们现在有一个完整的对话，关于 Notion 没有一个设计系统。事实是，是的，但他们在早期只雇佣了会写代码的设计师，这是使那成为可能并让它仍然是一个高度精雕细琢的产品的重要原因。

For sure. And that last thing you said is where it all dies, right? Even if you work with an engineer who's like, "Oh, 100%, I'm with you, that's totally worth fixing or making better," but then they're like, "But my boss is telling me to work on this other thing, and I have to do it." And like I said at the beginning, sometimes that's totally right. We all have to have the sort of strategic taste to know what's worth spending time on. But I think a lot of the lack of polish is just so easy to fix, as long as you made it easy to fix from the beginning. Even coming full circle to where we kind of started this conversation, which I didn't plan to at all, but like with Notion, right? We have this whole dialogue that's happening right now about, well, Notion doesn't have a design system. And the fact is, like, yeah, but they hired exclusively designers who can code in the early days, and that's a big part of what makes that possible and allows it still to be a highly crafted product.

所以我的问题是，鉴于所有这些背景、思维方式和工作方式，你在早期有多刻意地雇佣会写代码的设计师？

So my question is, given all of this context and way of thinking and way of working, how intentionally have you hired designers who can code in the early days?

所以在公司可能的前六个月，我自己做所有事情：产品设计，我做了品牌。好吧，我的成名作是我在我们重新品牌之前，成为了“Under Consideration”博客中的“之前”品牌。所以我上了“之前”部分。但是，你知道，为了弥补我觉得自己缺乏的东西，我雇佣了一位品牌设计师 Fee，他是个天才，他非常快乐，你可以从他的作品中看到这一点。那段时间我主要在想：好吧，我不擅长什么，我如何弥补，只是为了平衡自己，开始平衡团队。但随着我们越来越成功，知道我会越来越难找到时间做个人贡献者工作，我基本上想替换自己。所以我确实雇佣了一个会写代码的设计师，因为实际上在公司的大部分历史中，没有工程师知道如何写 CSS。我试过一次去度假，结果是一场灾难。这就像是我解决前端如何构建而不必雇佣两个人的方法，对吧？我可以雇佣一个设计师，我们可以雇佣一个前端工程师。我碰巧认识另一个会写代码的设计师，所以这是一个容易的胜利。我确实相信那种影响。然而，现实是大多数设计师没有写过生产级代码。他们没有解决过 Safari 中的奇怪错误，他们不知道如何进行代码审查，以及所有重要的东西。你知道，我们是工程团队的一部分，我们必须遵守规则并遵循流程。所以我认为要求找到一个之前做过或对此感到舒适的设计师是很多的。所以有一个完整的工程能力谱系，对吧？一直到原型制作、修补，甚至只是好奇心。

So for the maybe first six months of the company, I was doing everything myself: product design, I did the brand. Well, my claim to fame is I got to be the "before" brand in the "Under Consideration" blog before we did our rebrand. So I got to be on the "before" section. But, you know, trying to compensate for what I felt like I was lacking, I hired a brand designer, Fee, who's a genius, and he's just so happy, and you can see it coming through in his work. That was mostly what I was thinking for a while: just like, okay, what am I not good at, and how can I compensate for that, just to like balance myself out, start balancing the team out. But as we were becoming more successful, knowing that it would be harder and harder for me to find the time to do IC work, I definitely wanted to basically replace myself. And so I did hire a designer that codes, because actually for most of the history of the company, no engineer even knew how to write CSS. I tried to take vacation once and it was a disaster. It was like a way for me to solve the problem of how frontend gets built without having to hire two people, right? I could hire a designer and we could hire a frontend engineer. I happen to know another designer that codes, and so it was like an easy win. I do believe in that impact. However, the reality is most designers have not written production-level code. They've not had to solve weird bugs in Safari, and they don't know how to do code reviews, and all the stuff that is important. You know, we are part of the engineering team, we have to play by the rules and follow the processes. And so I think it's a lot to ask to find a designer that has done that before or is comfortable in that. So there's a whole spectrum of sort of engineering capability, right? All the way down to like prototyping and tinkering and even just curiosity.

我想具体谈谈你们如何作为团队工作，听你讲话时清楚的一点是，在 Perplexity 没有单一的流程或做事方式。所以也许我可以创造一个小的谱系，给你一个机会谈谈你们如何工作。一端是 Perplexity Pages，另一端是移动端的语音体验。你能用这些例子来强调你们在 Perplexity 设计和发布产品的不同方式吗？

I wanted to get into specifics on how you work as a team, and something that's clear listening to your talk is that there is like no one process or way of doing things at Perplexity. So maybe I can even create a little bit of a spectrum to give you an opportunity to talk about how you work. So on one end is Perplexity Pages, and on the other is the voice experience on mobile. Can you use these as examples to highlight the different ways that you design and ship products at Perplexity?

是的，当然。语音的功能北极星是预先确定的，对吧？如果我说我们要构建语音到语音，每个人都会说，“好的，我知道你的意思。”在工程方面，在交互设计的细节方面，有很多挑战才能达到那个北极星。所以我真的认为这是一个品牌和交互设计问题。那么，好吧，我们找出它的最佳流程是什么？因为我们已经知道它将如何工作，它并不复杂。所以对我来说，这是原型制作的完美候选。而且它的一个关键组成部分将是动画，所以我们将使用 After Effects 或某种方式来练习和探索动画。这就是我喜欢开始一切的方式，对吧？好的，如果你来找我说，好的，我们要做这个项目，然后我们经历，好的，我们如何……

Yeah, for sure. The functional Northstar for voice is like predetermined, right? If I said we're going to build voice-to-voice, everyone's like, "Okay, I know what you mean." There are lots of challenges to getting it to that Northstar in terms of engineering, in terms of like sort of the details of interaction design. And so I really think of that as like a brand and interaction design problem. And so, okay, what's our best process for figuring that out? Because we already know how it's going to work, it's not complicated. And so to me, that's like the perfect candidate for prototyping. And also a key component of it is going to be animation, so we're going to use After Effects or some way to sort of practice and explore animations. And that's kind of how I like to start everything off, right? Okay, if you came to me with that, okay, we're going to work on this project, then we go through like, okay, how do we...

就像，你知道谁有合适的技能，用什么工具，我们内部是否具备所需的所有人？如果我们决定接手，我就想把它做得出色、特别，因为如果你开始失去每个项目那种生死攸关的感觉，我认为你就在某种程度上失去了公司的时代精神。

It's like, who you know who's got the right skills, what are the right tools, do we have everyone we need internally to do this? If we're going to take it on, I want to nail it and I want it to be special, because if you start to lose that live-or-die aspect of every project, I think you kind of lose the zeitgeist of the company.

负责这个的设计师叫 Gunner。他在 After Effects 里做了一堆动画原型，在 Figma 和原型工具里迭代了几轮，比如怎么进入这个功能、怎么退出，它如何融入产品、如何连接现有概念？它是覆盖所有其他概念的一个层，还是一个完全独立的不同产品体验？

The designer that worked on it, his name's Gunner. He did prototype a bunch of animations in After Effects, he went through some iterations in Figma and in prototyping, kind of like how do you get into this and how do you get out of it, how does this fit into the product and how does it connect to the existing concepts? Is it sort of like a layer over all of her other concepts? Is it a totally different product experience that's disconnected?

其中一个有趣且困难的问题是，我们是用按键通话还是语音激活？这个问题我们争论了很久，实际上必须通过构建来感受差异。我一直觉得语音激活很令人沮丧，必须学会说一个关键词，比如“嘿，嘿 Perplexity”。最终，这感觉很慢。产品需要以你思考的速度运行。直接点一下然后开始说话要容易得多，也快得多，你不需要学习任何东西，进入体验的出错空间也更小。所以过程就是尝试这些东西，验证或推翻一些想法。Gunner 做了一些很酷的动画，就这样。

One of the interesting hard problems is, do we do push-to-talk or voice activated? This is something that we did debate a lot, and we had to actually build to sort of feel the difference. I've always felt that voice activated is really frustrating, having to learn like a keyword that you say, 'Hey, hey Perplexity.' In the end, that feels slow. The product needs to operate at the speed that you can think. It's a lot easier to just tap something and start talking. It's a lot faster to do that, you don't have to learn anything, there's less room for error in getting into the experience. So that was the process, just trying out these things and sort of validating or invalidating some of that. And Gunner made some cool animations, and that was it.

Pages 则完全相反。我们甚至不知道它能不能行，不知道是否可能。所以它始于一个基本愿景：如果任何人都可以创建一个关于某个主题的网站，而无需任何相关知识，只需提供一个标题，会怎样？唯一能验证的方法就是开始做原型，看看它是否真的可行。以尽可能低保真的方式，我们直接在终端里通过一些 API 调用来看看会发生什么。它能生成章节标题吗？好，看起来可以。它能生成章节内容吗？好，看起来也可以。就这样一步步添加功能，直到感觉我们有所发现，甚至值得为它构建一个界面。

Pages, total opposite. We didn't even know if it would work, we didn't know if it was possible. So it started with a basic vision: what if anyone could make a website about something without knowing anything about it, and all they had to do was give it a title? The only way to see it through would be to start prototyping and start seeing if it would even work. In the most low-fidelity way possible, we literally started in terminal with some API calls just to see what would happen. Could it generate section titles? Okay, looks like it can. Could it generate section content? Okay, looks like it can. Just going through and adding to this stuff until it felt like we were onto something, and it was even worth building an interface for.

嘿，各位，快速说一下，如果你了解我，就知道我热爱产品。所以我想花 30 秒介绍我最喜欢的三款产品。现在，每当我设计和构建网站时，你最好相信我一定会用 Framer。我最近刚切换过来，再也不会回去了。当需要为设计添加动画并展示作品时，我会用 Jitter。它就像 Figma，但专门用于动效设计。而每一步我都会持续使用 Raycast。它是我使用电脑的基石，也是我工作时保持心流状态的方式。我亲自挑选了 Framer、Raycast 和 Jitter 作为合作伙伴，这样我才能全职做这些访谈。所以如果你想支持它们，那对我来说意义重大。好了，现在继续节目的剩余部分。

Hey guys, real quick, if you know me then you know I love products. So I want to take just 30 seconds to tell you about three of my favorites. Now, anytime that I'm designing and building a website, you better believe that I'm going to use Framer. I made the switch recently and I'm never going back. Now, once it's time to animate my designs and showcase my work, that's when I'm going to use Jitter. It's like Figma, only for motion design. And every step of the way, I'm going to be using Raycast constantly. It's the cornerstone of how I use my computer and the way that I stay in flow while I work. Now, I hand selected Framer, Raycast, and Jitter to partner with me so that I could do these interviews full-time. So if you want to show them some love, it would mean a lot. Okay, now on to the rest of the episode.

我想再深入聊聊 Perplexity 的界面，因为你提到过消费品需要具备一种“引力”，我觉得这很有意思。所以也许你可以分享一下这对你来说是什么样的，以及随着产品越来越强大，你如何确保简洁性？

I want to go even deeper into the Perplexity interface a little bit, because something that you talk about is this idea of the gravitational pull that is required for consumer products, which I found pretty interesting. So maybe you could share a little bit about what that looks like for you, and also how do you ensure simplicity as the product becomes more and more powerful?

好的，有一种现象叫“知识的诅咒”。知识的诅咒是指你对某件事了解得越多，就越难教给别人，因为你很难记起自己不知道那件事时的状态。我认为，如果你是一名教师，你必须时刻思考这一点：记住你了解这个主题之前是什么样子。一位优秀的老师总能保持与学生的这种沟通渠道。我认为这也是作为设计师的重要部分：首先，不要太在意那些人们甚至不会真正体验到的细节，要么是因为他们不挑剔，要么是因为他们只是点击东西，并不太在意；但同时也要知道有些细节确实很重要，并且能够闭上眼睛再睁开，重新审视你盯了几个小时的东西，仿佛第一次看到它，试着想象新用户或早期用户的体验会是什么样。

Okay, so there's this thing called the curse of knowledge. The curse of knowledge is the more you know about something, the harder it is to teach somebody, because you can't really remember what it's like to not know that thing. I think that's like, if you're a teacher, it's something you have to think about all the time: remembering what it was like before you knew the subject. A great teacher can sort of keep that channel to the student always. I also think that's a big part of being a designer: first of all, not caring so much about the sort of details that people don't even really experience, either because they're not discerning or because they're just clicking on stuff and they don't really care too much, but also knowing that some of those details really do matter, and being able to kind of close your eyes and open them again and see the thing you've just been staring at for hours, seeing it for the first time, trying to imagine what that new user experience would be, or that early user, whatever.

我认为优秀的消费产品有一种引力。你会觉得没有错误的使用方式。你打开它，哪怕你眯着眼或者喝醉了，你也能轻松上手。没有决策负担。用户不需要思考，或者他们需要做的决定非常明显和清晰，感觉就像走在一条引导路径上。我认为这是消费设计的高标准：让第一次使用的人觉得如此显而易见，以至于无法想象其他方式。有很多策略可以实现这一点。首先，不要试图在交互设计上创新，因为大多数时候这不值得。大多数时候，你应该呈现熟悉的东西，让人们觉得尝试起来很舒服。如果你觉得需要构建某种教学体验，那你可能已经偏离了重点，因为人们——这是非常消费设计、免费产品的视角——当然，这不是制作软件的唯一方式。如果你做一款视频游戏，人们花了 60 美元，里面有教程，他们会学习。或者你做一些复杂的东西，有学习的激励，人们也会学习。人们学习如何使用 Photoshop，它真的很难用，对吧？所以以前人们会买手册。但我告诉我的团队：你必须假设用户需要在 300 毫秒内搞懂这个东西。这会迫使你做出很多权衡。如果你到了把所有东西都放在屏幕上，然后说“哦，用户会自己选他们想做的”，那行不通。人们会对不突出的 UI 视而不见。如果它一直存在，或者所有东西都有同样的突出程度，那么人们会感到迷失，因为感觉不到路径。所以很大程度上，消费设计需要感觉熟悉，感觉显而易见。现在，在你的第一个产品中做到这一点其实很容易，比如产品的第一个版本，当你还没有那么多功能的时候。想想 Medium。当 Medium 刚推出时，每个人都觉得“它太简洁、太漂亮了”，确实如此，但它也没有任何功能。

I think great consumer products, they kind of have a gravitational pull. You feel like there's no wrong way to use it. You open it up and you just, you could be squinting or you could be drunk, you're just falling through it. There are no decisions. The user doesn't have to think, or the decisions they have to make are just so obvious and clear, it feels like they're on a guided path. I think that's kind of the high bar of consumer design: making it feel so obvious the first time you use it that you can't really imagine another way. There are a lot of tactics to this. First and foremost, don't bother trying to innovate on interaction design, because most of the time it's not worth it. Most of the time you want to present things that feel familiar, so that people feel comfortable trying it. If you feel like you need to build some teaching experience, you probably lost the plot, because people—and this is very consumer design, free product perspective—it's not the only way to make software, of course. If you make a video game, people paid 60 bucks for it and there's a tutorial, they'll learn it. Or you make some complex thing that has incentives to learn it, people will learn it. People learn how to use Photoshop, it's really hard to use, right? So people used to buy manuals. But what I tell my team is: you have to assume that the user needs to be able to figure this thing out in 300 milliseconds. That kind of forces you into a lot of trade-offs. If you get to a point where you just put everything on the screen and you're like, 'Oh, the user will just pick which one they want to do,' it doesn't work like that. People will become blind to UI that's not prominent. If it's always there, or if everything has the same prominence, then people will feel lost because it doesn't feel like there's a path. So a lot of it is consumer design needs to feel familiar, needs to feel obvious. Now, it's really quite easy to get that right in your first product, like the first version of the product, right when you don't even have that many features. I think about Medium. When Medium first came out, everyone was like, 'It's so clean and it's beautiful,' and it certainly was, but it also had no features.

通过好的设计、好的图形设计和排版，做到这一点相当容易。你可以做出那种感觉的东西，但规模化很难。我们的机会在于，有了机器学习和 AI，我们可以根据用户想做的事情创造近乎无限的体验，按需展示高度定制化的界面。比如你想找一家咖啡店，我们可以给你完美的界面；如果你想学一个数学主题，我们可以给你最完美的信息呈现方式。能够动态分类和组装界面，让我们受益匪浅。就当前技术而言，这在几年前是做不到的。我的产品原则是：产品每天都要变得更强大，但不要让人觉得更复杂。对我来说，这就是优雅软件的巅峰，尤其是有了这种分类和组装 UI 的技术。看 Perplexity 的时候，我觉得你们比市场上任何人都更有机会构建真正的生成式 UI。你们已经在用 co-pilot 功能做类似的事情了。所以也许你可以谈谈你的愿景，这个方向在产品中会如何发展，以及它如何影响你设计产品和底层系统的方式？

Pretty easy to do that with good design, good graphic design, good typography. You can make something that feels like that, but scaling that is hard. What our opportunity is, given that we have machine learning and AI available to us, is we can create kind of infinite experiences based on what the user is trying to do. We can show them a very opinionated UI on demand. So if you're trying to find a coffee shop, we can show you the perfect interface for that. If you're trying to learn about a math subject, we can show you the perfect representation of that information for you. We benefit so much from being able to classify and assemble interfaces on the fly. Given how the technology works, as of today, that wasn't really available to us years ago. My product principle is that every day the product needs to get more powerful without feeling more complex. That's to me the sort of pinnacle of elegant software, given that tech to classify and assemble UI. When I look at Perplexity, I think you all have the best shot at building a truly generative UI as anyone in the market. You're already kind of doing this a little bit with the co-pilot stuff. So maybe you could even talk about your vision for where this might head in the product, and how does that impact the way that you design not only the product but the underlying system today?

愿景说起来容易做起来难。愿景是：无论用户想看什么，我们都应该以最完美的形式呈现信息；无论用户想做什么操作，我们都应该以最熟悉、最直观的形式呈现操作。比如我想看英伟达的股价，我可以用 markdown 纯文本展示，加粗最新股价，用列表列出历史数据，但更好的方式是给你一个可交互的图表，那才是更好的信息呈现。从操作角度，如果你想规划一次旅行，我可以给你一个聊天界面，你说“我想去这里旅行”，然后它问你日期，你打字输入。但旅行网站是 A/B 测试最极致的网站，Booking.com 是优化 UI 的教科书，你应该向它们学习。而且你要知道，它们流量巨大，用户对如何订机票、订酒店有既定的期望。这种熟悉感我们不需要放弃。这又是一个容易掉入的陷阱：试图在交互设计上创新。而如果你思考的是“人们现在怎么做，我如何以熟悉但更强大的方式重现它？”那么你只是在做一个带日期选择器和下拉菜单的表单。我们可以根据你的偏好动态生成完美的表单，但用户不需要思考这些。人们知道怎么用日期选择器，它熟悉、真实、精确。所以类似这样：我们会为你正在做的事情展示正确的 UI。这就是愿景。从设计角度看，从概念上思考会更有帮助，就像我刚才解释的那样。我觉得你懂了。如果我去把所有结果都做成 mockup，那要花很长时间，而且并不能真正说服你去构建它，也不能让所有人理解它是什么。更简单的方式是直接说“这是计划”，用论点、一些用例和几张草图来呈现，然后直接进入代码。所以我们的流程变了：设计师在思考这种体验，但他们不是用 mockup 来沟通，而是用指导原则。这些指导原则可以通过想法、对话和少量基础 mockup 来传达。这就是流程的变化。它变成了一个协作式的端到端产品构建过程，而不是设计交接给工程然后期望一切正常。因为你无法设计所有情况，你只需要解释用户会得到什么，产品体验的愿景是什么，然后你和工程师一起通过协作对话来构建它。

The vision is, I guess, very easy to say and hard to execute. The vision is: no matter what the user wants to see, we should represent that information in its most perfect form; and no matter what the user wants to do in terms of actions, we should represent that action in the most familiar, most intuitive form. Let's say I want a stock price of NVIDIA. I could show you that in markdown with just text, right? I could bold the latest stock price and do a bullet list of the history, but it would be a lot better if I showed you a graph that you could then interact with. That's a much better representation of that information. From an action perspective, if you want to plan a trip, I could show you a chat UI and you could say 'I want to go on a trip here' and then it'll ask you what dates, and I could type all that out. But travel websites are like the most A/B tested websites ever. Booking.com is a master class in optimization UI. You should go learn from them. Also, you have to assume that they're heavily trafficked, so there's an expectation that users have on how booking a flight works and how booking a hotel works. There's a familiarity that we don't need to let go of. Again, this is the trap it's so easy to fall into: trying to innovate on interaction design. Whereas if you're thinking more 'okay, what do people do now and how can I recreate that in a way that feels familiar but maybe a little bit more powerful?' Well then, yeah, you're just making a form with date pickers and dropdowns. And we may be dynamically generating that perfectly for you based on your preferences, but the user doesn't need to think about any of that. People know what to do with a date picker. It feels familiar, it feels real, it feels precise. So things like that: we'll show you the right UI for the thing you're trying to do. That's the vision. I think from a design perspective, it helps to be thinking about it more conceptually, like I just explained it to you. I think you get it. If I went and tried to mock up all these outcomes, it would take me forever, and it doesn't really help me convince you to build it. It doesn't really help everyone understand what it is. It's a lot easier to just be like 'here's the plan,' represent that with a thesis and maybe some use cases and a few napkin drawings, and then just get into the code. So our process changes: designers are thinking about this experience, but they're not communicating it with mockups; they're communicating it with guidance. And that guidance can be represented with just ideas and conversation and maybe a few basic mockups. That's how the process changes. It becomes much more of a collaborative end-to-end product crafting process, rather than design handoff to engineering and then something's working right. Because you cannot design all the cases. You have to just explain what the user is going to get and what the vision for the product experience is, and then you and the engineers build it together in a very collaborative, conversational process.

你在推动一个看似有无限界面组合的世界。短期内你还没完全做到。那么你如何组织并跟踪代表不同状态的不同模板或视觉产物？因为对我来说，这些组合呈指数级增长，就越难跟踪我们的产品能变成什么样。你如何应对这种张力？

You're pushing toward this world with seemingly infinite interface combinations. In the short run, you're not quite there yet. So how do you organize and keep track of the different templates or visual artifacts that represent the states? Because to me, it's like the more that you exponentially increase these combinations, the more difficult it is to even keep track of what our product can become. How do you deal with that tension moving forward?

这是一个 UI 系统问题。我给你举个例子。我们正在设计一个我们称之为“实体对比”的 UI。如果你有两个实体，用户需要帮助在它们之间做选择，或者三个、五个、一百个，我们需要一个界面。这些实体可以是狗品种、电影或餐厅。实际上所有这些的界面不需要不同。所以我们设计它，并在我们能想到的案例上测试。但到了某个点，你只能相信它也能适用于其他你没想到的案例，并接受这一点。设计这样的产品，一部分就是要接受百分比结果。有时候它会很糟糕。我们现在就有这个问题：LLM 在写 markdown，它可以选择用哪些 markdown 元素，有时格式很漂亮，有时会输出一团糟。我写再多 CSS 也修不好。但我接受这一点，并努力通过找到问题的根源来降低那个百分比。你在构建系统，给它工具使用，并希望它大部分时间能正常工作。这就是你能做的最好的了。

It is a UI systems problem. I'll give you an example. We're designing a UI for what we call entity comparison. So if you have two entities and the user wants help picking between them, or three, or five, or 100, we need an interface for that. And those entities could be dog breeds, or movies, or restaurants. The interface actually for all of those doesn't need to be different. So we design that and we test it on cases that we can think of. But then at some point, you just have to trust that it'll work for all the other ones that you didn't think of, and be okay with that. Part of designing a product like this is being okay with percentage outcomes. Sometimes it's going to suck. We have this in a very basic sense right now: the LLM is writing markdown. It has the choice on which markdown elements to use, and sometimes it does wonderful formatting, and sometimes it vomits out this awful thing. And there's no amount of CSS I can write to fix it. But I accept that, and try to squash that percentage down by getting to the root of the problem. You're building the system, you're giving it tools to use, and hoping that it works most of the time. That's the best you can do.

我想从 Perplexity 稍微放大一点，谈谈设计师如何在自己的产品中识别利用 AI 的机会，这些产品可能在利用这项新技术方面比较滞后。你有一句话让我印象深刻：你说产品会经历一个过渡期，在生成式体验中进进出出。是的。你认为一旦他们的公司突然变成 AI 公司，这需要其他设计师思考什么？如果我能洗掉所有人的焦虑，我会的。而且我认为焦虑有多种形式。

I want to zoom out from Perplexity a little bit and talk about how designers can identify opportunities to leverage AI in their own products that are probably lagging in terms of making use of this new technology. Something that you said that stood out to me was: you said products are going to go through a period of transition where they move in and out of generative experiences. Yeah. What do you think this is going to require other designers to think through once their company all of a sudden kind of becomes an AI company? If I could wash away everyone's anxiety, I would. And I think there's anxiety in a bunch of ways.

人们焦虑这对设计和设计师意味着什么——我们会被取代吗？大家都在讨论这个。

There's anxiety about what does it mean for design and designers. Can we be replaced? There's sort of conversation around that.

但我认为我们现在拥有的基本上是以前没有的新工具，可以用来解决问题。你能够改变界面上很多事物的呈现方式，这是以前做不到的。例如，在我们甚至还没做登录功能之前，Perplexity 就已经支持所有语言了，这完全是因为大语言模型的特性。实现这个并不难，反而构建登录功能更费劲。而 10 年前，这会是疯狂的努力，比如产品国际化要花巨大成本。如果你理解什么是可能的，同时深刻理解你的产品要做什么、用户要做什么，你会发现产品体验方面有很多以前没有的捷径。

But I think what we have available to us are basically new tools to solve problems that we didn't have before. You have the ability to change how a lot of things are represented on the interface that you wouldn't have been able to do before. For example, before we had even built login, Perplexity worked in every language, which is just because of the nature of LLMs. It wasn't that hard to get that working. It was more work to build login. And 10 years ago, that would have been an insane effort, like a huge expensive thing to internationalize the product. If you understand what's possible and you also understand deeply what your product is trying to do and what your users are trying to do, you'll find that there are actually all these shortcuts available to you that weren't before in terms of the product experience.

我也认为这是初创公司颠覆大公司的时代，那些大公司固守自己的运营方式和产品模式。有机会拿一个非常流行的产品，让它感觉更快、更强大或更神奇，你可以迅速做到这一点，然后呈现一个非常疯狂的替代品。我看不出这为什么不能到处发生。所以我希望每个人现在都能这样看世界。我觉得这非常令人兴奋。我确实认为会有更多小公司去构建有挑战性的东西。

I also think this is an age for startups to disrupt bigger companies that are stuck in how they operate, stuck in how their product works. There's an opportunity to just take a really popular product and make it feel faster or more powerful or more magical, and you can rapidly get yourself there and then present a really crazy alternative to a popular thing. I don't see any reason why that can't happen all over the place. So I would love for everyone to see the world that way right now. I think it's very exciting. I do think there will be a lot more smaller companies building challenging things.

我非常同意，而且我希望很多这样的公司由设计师领导，使用 Cursor AI 之类的工具。很多事情感觉都是从理解技术可能性出发反向推导的，也许比产品制造史上任何时候都更如此。你能分享一下你摸索这些模型能做什么的过程吗？毕竟你在这个领域已经投入了很多。而且我不允许你说“我就是试了试”——你得说得更具体。

I very much so agree, and I hope that a lot of those companies are led by designers using Cursor AI or something like that. A lot of it does feel like it works backwards from this understanding of what is possible from a technological standpoint, perhaps more so than ever before in the history of making product. Can you share a little bit about your process for figuring out what is possible with these models now that you've had to really ramp up on this space? And I'm not going to let you say 'well I just experimented' — you have to get more specific than that.

有两件重要的事要理解：一是什么是可能的，二是什么是有用的或有趣的。没人能只考虑一件事了；你必须考虑产品的全部意义。你必须考虑它如何融入人们的生活。因为如果你真的相信某件事，你比以往任何时候都更有能力去构建它。但你必须相信一些东西——你必须相信你正在构建的东西是有用的，哪怕只对你和你的朋友有用；或者这个东西如果做出来会很有趣，而你要让它成真。那才是最重要的。理解技术——我觉得你不需要理解太多。你不需要去 arXiv 读论文。现在有很多技术演示。我们处在一个修补的时代，这太棒了。人们在尝试各种东西并分享：‘嘿，看看这个模型，它能做这个，我做了个原型。’而且做这些的大多不是设计师，他们根本没考虑产品，只是在展示技术。你可以很好地了解当前的水平。我觉得更难的是理解轨迹。很多人会对 AI 不屑一顾，因为它还不够好——‘它取代不了我’——而我认为它永远不会也不需要取代任何人。我觉得人们有防御心理是因为感到威胁。但如果你更多地看这个东西能做什么，我如何用它做出更有赋能感的东西——我们有责任去创建让世界更美好的公司和产品。我认为没有任何理由对它不屑一顾。而且你必须假设一切都会很快变得更好——更强大、更有能力。所以如果你真的在想‘如果这样的产品存在就好了’，那你不妨现在就开始构建，即使它还不完美。

There are two important things to understand: one is what's possible, but also what's useful or what's fun. Nobody gets to think about one thing anymore; you have to think about the whole point of the product. You have to think about how it fits in people's lives. Because if you really believe in something, you're more empowered than ever to build that. But you have to believe in something — you have to believe that this thing I'm building would be useful even if it's just for me and my friends, or this thing would be really fun if it worked and I'm going to make it work. That's the most important thing. Understanding the technology — I don't think you need to understand that much. You don't need to go read papers on arXiv. There are a lot of tech demos out there. We are in an era of tinkering, which is amazing. People are trying out all kinds of stuff and sharing it: 'Oh check out the model, it can do this, I built a prototype of that.' And these are mostly non-designers doing this, and they're not thinking about product at all; they're just showing off the technology. You can get a pretty good understanding of where things are. I think the harder part is understanding the trajectory. A lot of people will be very dismissive about AI because it's not good — 'it can't replace me' — and I don't think it ever will or needs to replace anybody. I think people are defensive because they feel under threat. But if you're looking more at what this thing is capable of and how can I use it and how can I make something with it that's more empowering — it's kind of on us to make companies and products that will make the world better. I don't think there's any reason to be dismissive of it. And you have to just assume that everything is going to get better really quickly — more powerful, more capable. So if you're really thinking 'it would be really great if such a product could exist,' you might as well start building it now, even if it's not perfect yet.

在开始录制之前，你暗示了一个你一直在琢磨的 AI 硬件预测。想跟我们分享一下吗？

Before we hit record, you hinted at a little AI hardware prediction that you've been mulling over. You want to share that with us?

在 2000 年之前——也就是 2000 年之前的 50 年或 40 年——人们最流行的产品之一是收音机。从迪尔·拉姆斯到 90 年代的索尼，工业设计竞争非常激烈。因为从技术角度看，收音机基本上是一个已解决的问题，而内容与界面无关——任何收音机都能接收相同的内容，任何人都能听。这并不总是成立，但有一个时代，设计是优势，人们因为设计、形式和功能而做出购买决定。实际上，在大多数行业，设计只是入场券，不是真正的护城河或竞争优势。所以我的预测——我希望这是一个充满希望的预测——是随着当前几件事的发生：第一，制造比以往任何时候都容易——你只需要和中国的工厂进入正确的 WhatsApp 聊天群，就能做出东西。但此外，由于所有这些前沿 AI 公司都提供了 API，基本的 AI 交互实际上已经商品化了。而进入的界面其实很简单——就是自然语言，一个普遍可理解的概念，任何人都能做到。所以如果你有这种已解决的技术，或者至少它对入口点无关紧要，我有点认为会有一波硬件公司像收音机时代那样在设计上竞争，形式和功能设计在市场上竞争，因为技术的力量是商品，进入的交互并不复杂。你不需要构建任何非常复杂的东西让人们使用和尝试。显然，这已经发生了一点，但我认为一旦有一家公司稍微胜出，就会加速一切。

Before the 2000s — 50 years or 40 years before the 2000s — one of the most popular products people had was radios. From, say, Deere & Rams up to Sony in the '90s, there was an amazing industrial design competition. Because the radio essentially is a solved problem from a technological perspective, and the content was agnostic to the interface — any radio hits the same content, anyone can listen to it. And this isn't always true, but there was an era where design was the edge, and people made purchasing decisions because of design, form, and function. Most industries, actually, design is table stakes; it's not an actual moat or competitive edge. So my prediction — and I kind of hope this is a hopeful prediction — is that with a few things happening right now: one, manufacturing is easier than ever — all you need is to get in the right WhatsApp chat with a factory in China and you can get something made. But also, because all these frontier AI companies have made APIs available, there's essentially a commodification of basic AI interaction. And the interface into that is actually quite simple — it's natural language, a universally understandable concept, and anyone can do it. So if you have this solved technology, or at the very least it's agnostic to the entry point, I kind of think there will be a wave of hardware companies competing on design in the way that there was with radios, where form and function design competition in the market, because the power of the technology is a commodity and the interaction to get into it is not complicated. You don't need to build anything very sophisticated for people to use it and try it. Obviously, there's a little bit of this already happening, but I think as soon as one company wins a little bit, it'll just accelerate everything.

我喜欢这个观点，因为随着越来越多的 AI 硬件公司推出产品，这几乎成了一个梗：‘他们为什么不请时装设计师？’因为实际上没有一样好看。但这是新的，是第一批产品，所以可以理解。但我同意，也许这确实是一个有点乐观的预测，因为我对目前市面上产品的美学并不特别着迷。但问题就在这里——如果这就是我们所有的……

I like that take because as more of the AI hardware companies launch, it's almost becoming a meme at this point of 'why aren't they hiring fashion designers?' because nothing actually looks good. But it's new and it's the first one, so it makes sense. But I think I agree, and maybe it is a little bit of a hopeful prediction because I'm not particularly fascinated with the aesthetics of what is out there today. But that's the thing — if that's all we're...

作为设计师，评估一个竞争完全围绕设计的市场会令人兴奋。这样的市场并不多见。你知道，汽车和消费电子算，但软件肯定不是，我们做的肯定也不是。

Evaluating it would be exciting as a designer to sort of see a new market where the competition is all about design. There's just not that many markets like that. You know, there's cars and consumer electronics, but certainly not software, certainly not what we do.

所以你应该去看看老式收音机的设计，因为有无穷无尽的款式，它们都很酷，有些还很奇怪，但功能都一样。

And so you should go look at old radio designs because there's just like infinite of them and they're all so cool, and some of them are so weird, but they all work the same.

在你离开之前，我有一个经常问大家的问题，特别想听听你的看法：关于设计，你相信什么而很多其他设计师可能不同意？

Before I let you go, there is a question that I like to ask kind of everyone. I'm particularly interested in your take, which is: what's something that you believe about design that you think a lot of other designers might disagree with?

我不想创建一堆品牌指南，因为大公司品牌团队的做法是制作一些模板，所有人都必须使用，这是一种非常保守的品牌思维。一切都关乎保护品牌，对吧？多年前有人定义了品牌，现在其他人只能原封不动地沿用，也许每十年才重新品牌一次。品牌就是这么运作的。

I don't want to create a bunch of brand guidelines, because what happens at big corporate brand teams is they create these stencils that they all have to use, and it's a very conservative way to think about brand. It's all about protecting the brand, right? Someone years ago figured out the brand, and now the rest of us have to just keep using it exactly as it was defined, and maybe there's a rebrand once every 10 years. That's how brands operate.

我的理论是，品牌可以反过来。我是说，OB 你知道，logo 不需要变，但执行方式和周围语境可以非常动态。我认为这不仅对公司有好处，能让品牌保持新鲜感，还能适应不同场景——我们有高中生用户、投行用户、世界各国的用户。我们没理由搞一个超级死板的品牌。

My theory is instead you could have a brand. I mean, OB, you know, the logo doesn't need to change, but the implementation and the context around all of that can be super dynamic. Not only do I think that's good for the company because it keeps the brand feeling fresh and also lets it adapt to different contexts — we have high school users, we have investment banker users, we have users in every country in the world. There's no reason for us to have some big super tight brand.

而且，我想做一些对团队设计师有益的事。部分原因是，你雇用了这些极具创造力的人，品牌应该成为他们表达自我的平台。我们可以通过协作创造凝聚力，也许一些细节让人感觉都来自公司，但我认为每件小事也带点个人色彩也没问题。这会让我开心。

But also, I think I want to do things that are good for the designers on the team. Part of that is you're hiring these incredibly creative people; the brand should be a platform for them to express themselves. We can create cohesion through collaboration, and maybe some details make it feel like it's all coming from the company, but I think it's okay if every little thing feels a bit like that individual too. It would make me happy.

这又回到我希望从事的工作。我当然不是世界上第一个有这种策略的人，但每当我向潜在的品牌设计师推销时，他们都说“听起来很棒”，然后问“为什么不是这样？为什么不常见？”至少，这是我的——我不知道这是否算激进观点，但这是我坚信的。

This comes back to what I wish I got to work on. I'm certainly not the first person in the world to have this strategy, but whenever I pitch it to a potential brand designer, they say 'that sounds great' and they like 'why doesn't it? Why is it uncommon?' At the very least, that's my — I don't know if it's a hot take, but it's something I believe.

我的意思是，你现在做的很有效，所以如果这是逆向观点，我认为未来不会如此。

I mean, whatever you're doing is working, so if it was a contrarian take, I don't think that it will be in the future.

非常感谢你今天来做客，稍微揭开了 Perplexity 旅程的面纱，以及你对团队建设和流程的思考。这真的很棒。我是你所有设计作品的忠实粉丝，感谢你抽出时间。

Thank you so much for coming on today and pulling back the curtain a little bit on the Perplexity journey and how you think about team building and process. It's been really awesome. Big fan of everything that you're designing, and thanks for taking the time today.

谢谢。

Thank you.

嘿，我是 Red。别忘了，如果你想每周更深入，我会给超过 10,000 名设计师发送邮件，提供额外资源和这些对话的关键要点。所以请访问 dive.club/slil 注册。好了，下周见。

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/slil to sign up. Okay, I'll see you next week.