AI 协作设计：从 Figma 到代码的 Notion 实践

AI 如何改变我们与工程师协作的方式？

How is AI changing the way that we collaborate with engineers?

我把 playground 里的那个目录喂给了一个大语言模型，说“让这个能在生产环境跑起来”。它一次性就搞定了，完美无缺。我和工程师 Rob 都惊呼“这也太酷了”。现在我用这些工具已经能搞定大部分前端工作，然后提交 PR，让这些工程师给我做高质量的代码审查。

I took the directory that this was in in the playground, fed it to an LLM, and said, 'Make this work in production.' And it one-shotted it and did it perfectly. It was flawless. That engineer, Rob, and I were both like, 'This is so sick.' I now have the skills, using these tools, to do most of the front end, and then ship PRs that I can get really high-quality reviews from these folks on.

最优秀的设计师是如何在代码中把控那最后一步工艺的？

What are the best designers doing to own that last mile of craft in code?

这些大语言模型在设计的最后一步并不擅长。这仍然是我们的超能力，也必须是我们的超能力。我们的工程师能把产品做到 80% 到 90%，然后我们设计师就要负责最终成果——这是我们在 Notion 的说法。我认为我们再没有借口不为那些我们想看到的改变负责了。

These LLMs are not very good at the last mile of design. And that's still our superpower, needs to be our superpower. Our engineers will bring it all the way up to 80 to 90%, and then it's up to us as designers to just own the outcome, is what we say here at Notion. And I think we have no excuse anymore to not be responsible for those changes that we want to see.

欢迎来到 Dive Club。我是 Rid，在这里设计师永不止步。本周的嘉宾是 Andy Madrick，他负责 Notion 会议笔记的设计。我们将深入探讨他的 AI 工作流，以及 AI 如何改变 Notion 的协作方式。这是一场非常实用的对话，包含大量屏幕共享，我们将从 Andy 如何设计 Notion 最受关注的界面之一开始。

Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with Andy Madrick, who's leading the design of Notion meeting notes. We're going to do a deep dive into his workflow with AI and all of the ways that it's changing what collaboration looks like at Notion. I mean, it's a super practical conversation with a lot of screen sharing, and we're going to start with a behind-the-scenes look at how Andy designed one of Notion's most viewed interfaces.

在 Notion，我们每年都会举办 Make with Notion 大会，发布一些新功能。产品内的触点总是一个弹窗。我们通过左上角那个大弹窗来宣布所有我们今年兴奋的功能。在 Notion，我不知道这算不算一种成人礼，但大家会说“谁来做这个弹窗？”而且关注度极高。Ivan 参与度很高，这太酷了，因为我入职 Notion 一个月后就开始了这个项目，然后每天都能和 Ivan 一起工作。

At Notion, we have our Make with Notion conference every year, where we announce certain features. So, the in-product touchpoint for that is always a modal. We announce everything via this big modal that you see on the top left, that announces all the features that we are excited about this year. And at Notion, I don't know if it's so much a rite of passage, but it's like, 'Who wants to build this modal?' And there's a ton of eyeballs on it. Ivan is very involved, which is so cool, because I started on this a month after I started at Notion, and then I got to work with Ivan like every day.

新订阅用户，太棒了。从零开始到做出这个备受瞩目、人人都会看到的弹窗，需要做些什么？

New subs. That's awesome. What does it take to actually go from zero to this modal that is celebrated and that everybody's going to see?

我们有了这个弹窗。这就是我们最终打磨出的最精致版本。我们非常兴奋，觉得它很有视觉吸引力，Make with Notion，真的很激动人心。Ivan 和 Alan Kay——我的两位偶像——同台了。但为了启动这个项目，我们做了大量迭代。对我个人来说，很幸运的是我和一位同样叫 Ivan 的优秀产品经理合作，他帮我梳理了很多事情，我只需要专注构建。所以我一开始就做了很多不同的迭代版本，对吧？我有这个版本，但同时还有无数个版本并行，我同时摆弄它们，差不多是同步调整。

We have this modal. Now, this is what we ended up getting to, our final most polished version. We were really excited about it. We thought it had a lot of visual intrigue, you know, Make with Notion. It's really exciting. Ivan was talking with Alan Kay, two heroes of mine, same place. But to get started on this, we just jammed on a lot of different iterations. And for me personally, what was really nice is I was working with a really great PM who's also named Ivan here at Notion. And he was able to kind of triage a lot of this stuff for me and I got to just build. So, I started out just creating a bunch of different iterations, right? So, I have this guy, but then I have like a million different ones in parallel, jamming on all of them, more or less fidgeting in tandem.

这些是线框图吗？你是在 Figma 里做，还是直接构建？

Are these mock-ups? Like are you doing this in Figma or are you building?

所以，这些全是在 Figma 里做的。我的工作流仍然大量使用 Figma 进行像素级调整。我现在展示的是幻灯片，因为我有点控制狂。所以在制作这类东西时，我在 Figma 里仍然很快。实际上我正越来越多地将初始原型或探索转向代码。但当时是 2025 年 9 月，我还在大量使用 Figma。所以我在 Figma 里做了所有这些迭代。然后，我不只是分享 Figma 链接，而是在我们的原型 playground 中创建原型，那是 Notion 代码库的一个轻量版本。我在那里用代码模拟出来，现在我有多个不同版本，可以发送给任何感兴趣的人。这样分享起来容易多了，对吧？所有东西都在一个空间里，可以点击浏览，我只需发个 URL 给大家，让他们自己看。

So, this is all in Figma. So, my workflow is I do a lot of pixel pushing in Figma still. I'm showing you slides right now because I'm a bit of a control freak. And so, when it comes to like crafting things like this, I'm pretty fast in Figma still. I'm actually migrating more and more toward my initial prototypes or my initial explorations being in code. But at this point, this was like September of 2025, I'm still doing a lot of Figma. So, I do all these iterations in Figma. And then instead of just sharing like Figma links with a bunch of people, I create this prototype in our prototype playground, which is like a very lightweight version of our Notion code base. Where I just mock these up in code and now I have a bunch of different versions that I can send out to whoever is interested in seeing this. So, it's a lot easier for sharing, right? Like I have this all in one space. It's click-through. I can just send a URL to folks and make them look through this.

我从未想过我的设计工作流会在过去几个月发生如此巨大的变化。其中很大一部分要归功于 Paper 的新快照工具。它是一个 Chrome 扩展，可以让你从实时网站复制任何组件或元素，然后直接粘贴到 Paper 中作为可编辑图层。所以我经常从生产环境抓取东西，让 Claude 立即在 Paper 画布上生成六种不同方案，然后当我想把概念发回给 Claude 时，无缝衔接，因为 Paper 的画布使用真实的 HTML 和 CSS。这个工作流对我来说非常像设计的未来，你现在就可以开始使用。只需访问 dive.club/paper 即可试用。

Never in a million years did I think my design workflow would change so drastically in the last few months. And a big part of it is Paper's new snapshot tool. It's a Chrome extension that lets you copy any component or element from your live website and then paste it directly into Paper as editable layers. So, all the time I'll grab something from prod, have Claude immediately spin it up six different ways on Paper's canvas, and then when I'm ready to send a concept back to Claude, it's seamless because Paper's canvas uses real HTML and CSS. That workflow feels a lot like the future of design to me, and you can start doing this today. Just head to dive.club/paper to try it out.

最近人们从 ChatGPT 和 Perplexity 这类工具获取答案的频率远高于点击 Google。所以如果你的网站不能被 AI 读取，你就会失去在分析中看不到的可见性。Framer 刚刚推出了一款免费的 AEO 工具，可以展示这些 AI 系统如何读取和理解你的网站。只需 10 秒，它就能扫描你的网站，给出 AEO 就绪评分，并指出哪些因素损害了你的可见性。我在 diveclub 网站上跑了一下，只得了 50 分（满分 100），但好在 Framer 给出了我需要采取的具体修复步骤。所以一定要花一分钟在你的网站上使用 Framer 的新 AEO 扫描器。你可以访问 framer.com/aeo 开始使用。

People are getting answers from tools like ChatGPT and Perplexity a lot more than they're clicking on Google lately. So, if your site isn't AI-readable, then you're losing visibility that you can't see in your analytics. So, Framer just launched a free AEO tool, which shows you how these AI systems read and understand your website. So, in 10 seconds it can scan your site, score it on AEO readiness, surface what's hurting your visibility. I ran it on the diveclub website, and I only got a 50 out of 100, but thankfully Framer gives me the exact steps that I need to take to fix it. So, definitely take a minute to use Framer's new AEO scanner on your website. You can head to framer.com/aeo to get started.

现在回到正题。接下来发生的事情是，大家开始决定自己喜欢什么、不喜欢什么。我们逐渐发现我们开始倾向于这个主题，对吧？左边是那些大脸，右边是一些素材。然后我们说：“好，我们接近目标了。”所以我回到 Figma 稍作细化，然后回到原型 playground，创建了一个使用该主题的新原型，并允许其他人随意编辑。这样，别人就不用在 Figma 文件上给我反馈了，而是可以在这里进行一定程度的自定义。Notion 的同事们可以进去点击、修改标题、调整素材数量、更改章节标题等等，然后截图发给我。我们就像在共同设计，但这有点像 iPhone 的主屏幕——你可以随意拖放，但最终你还是在 Apple 的轨道上，你仍然处于一个经过策划和定制的世界里。

Now, on to the episode. What happened from here is that people start deciding what they like, what they don't. Like, we started to find that this was the motif that we started to gravitate towards, right? We have the nosey faces on the left with some kind of asset on the right. And we're like, 'Okay, we're getting close to what we want.' So, I go in Figma, refine it a little, and then I go back into our prototype playground, and I create an additional prototype that uses that motif, and then I allow other people to edit this however they want. So, instead of someone giving me feedback on a Figma file, I'm able to allow a certain level of customizability here, and then different folks at Notion are able to go in, click around, you know, change the titles, change the number of assets here, change the section headers, whatever, and then they can take screenshots and send it back to me. And then we're all like co-designing together, but it's kind of like the home screen on your iPhone, where you can drag stuff around and drop stuff how you want it to be, but at the end of the day, you're still like on Apple's rails, and you're still like okay, I'm in this world that's a little curated and opinionated.

我很喜欢这个做法，因为我刚和一位设计师聊过，他在与内容团队协作时遇到了很大困难，因为在 Figma 里，别人可以直接点击并编辑文本。

I love this because I was just talking to a designer who is having so much difficulty collaborating with content teams again, because when it was in Figma, somebody could just click and just edit the text.

对于内容设计师来说，能够在内容实际存在的上下文中写作非常有价值，但现在他们一切都在代码里完成，所以他们没有这个。你做的这个真的很酷。

And for a content designer, there's so much value in being able to write within the context of where it would exist, and yet they're doing everything in code now, and so they didn't have this. Really, really cool what you built here.

构建这个其实非常简单。我拿了侧边栏的框架，然后想：“嘿，我们需要把这些文本输入做成链接到屏幕上的内容。” 我记得当时我用的是 Composer 1.5，或者可能是 Composer 1，它毫无问题地处理了。

Building this was really pretty simple. I took the chrome from our sidebar, and I was like, "Hey, we need to make these text inputs that are links to the content on the screen." And I think at the time I was using Composer 1.5, or maybe it was Composer 1 at the time, and it handled this no problem.

嗯，这很酷。我以前没见过这样的东西。对我来说完全合理。哦，酷，不错。

Um, that's cool. I have not seen something like this before. It makes total sense to me. Oh, cool. Nice.

然后我们收到了 CEO Ivan 的反馈——有一天我和他一起头脑风暴，他说：“让它感觉像电子游戏。” 然后他开始拖动各种元素，我们进入了 Figma，他说：“我希望那些 Nosey 脸出现在屏幕外，模态框外。我希望感觉像在玩电子游戏，我得到了一个奖品之类的。让它非常令人兴奋。” 所以我们就想：“好吧，稍微回到画板。” 但这就是有趣的部分，对吧？我们把所有碎片拿过来，稍微移动了一下。然后我在想如何制作动画，以及它看起来和感觉起来会怎样。对我来说，我展示这个截图是因为我仍然喜欢在 Figma 里做一点动画。我不做很多，但就像我说的，我是个控制狂。我觉得 Figma 仍然让我有能力以确定性的方式控制事物。所以我在 Figma 里做了一点原型，非常少。我从来不在 Figma 里做可点击的原型，但我会做像这样非常简单的东西。比如：“如果这个脸那样做，那么文本就这样移动。” 对于像我这样使用 Figma 多年的人来说，这很多时候比代码更快。我做前端大概有 10 年了。当我开始做这个时，Figma 仍然快得多。但现在这些编码工具变得非常好，速度开始提升。所以当时，这对我来说比 Figma 快。然后我开始勾勒这个动画应该看起来和感觉起来的样子。我没有告诉 LLM：“我希望这里的 Nosey 脸向右移动、缩小、淡出，然后这个移入。” 我通过绘制关键帧、截图并直接喂给 LLM 取得了很大成功。它很棒。现在的计算机视觉非常好。所以我开始在这里稍微打磨 UI。然后就像：“好的，我们有了一个非常喜欢的构图。” 我要更深入地研究细节。我要展示：“好的，我希望文本随着 Nosey 脸移动。” 然后我要展示：“好的，这是第一步、第二步、第三步。” 我希望它朝这个方向移动。所以我又截了这些图，喂给 Composer。然后我对它变得非常挑剔。

So then we got feedback from Ivan, our CEO, and he said—I was jamming with him one day—he's like, "Make it feel like a video game." And he started pulling things around, and we got into Figma, and he's like, "I want the nosey faces to be off the screen, off the modal. Like I want this to feel like I'm playing a video game, and I got like a prize or something like that. And make it really exciting." So then it's like, "Okay, a little bit back to the drawing board." But that's the fun part of this, right? We took all these pieces, moved them around a little bit. And then I was thinking about how I would animate this and what it would look like and feel like. For me, I'm showing this screenshot because I still like doing a little bit of animation in Figma. I don't do a lot, but like I said, I'm a control freak. I feel like Figma still gives me a little bit of an ability to control things in a deterministic way. So I did a little bit of prototyping in Figma, very little. I never make click-through prototypes in Figma, but I will make really simple things like this. It's like, "Well, if this face does that, then the text moves like this." And for someone like me who's been using Figma for years, this a lot of the time can be faster than code. I've been doing front-end for, let's say, 10 years. When I started doing this, Figma was still a lot faster. But now these coding tools are getting so good that the speed is starting to increase. So at the time, this is faster for me than Figma. But then I'm starting to sketch out what this animation should look and feel like. And instead of telling an LLM, "I want the nosey face here to move to the right and shrink and then fade out and then this will move in," I've had a lot of success sketching key frames, taking screenshots, and just feeding it to an LLM. And it rocks. Computer vision is so good these days. So I start polishing the UI a little bit here. And it's like, "Okay, we've got a composition we really like." I'm going to get into the nitty-gritty even more. I'm going to show like, "Okay, I want the text to move with the nosey faces." And then I'm going to show like, "Okay, this is step one, two, three." And I want it to move in this direction. So again, I'm taking screenshots of this and feeding it to Composer. And then I get really, really nitpicky about it.

哦，这非常细致。

Oh, this is super granular.

是的，我的意思是，我认为对于很多动效设计来说，编码工具非常擅长执行，但你必须非常非常详细地描述你想要什么，否则你会和这些东西斗争几个小时。你会抓狂，原地打转。所以对我来说，一张图真的胜过千言万语。所以我可以这样做：好的，这是 Nozi 最终要做的，它会回到这里，我会标记它处于什么状态。然后我们走出来，实际上有了在代码中工作的东西。这不是一次完成的，你需要随着时间的推移不断改进，但动画实际上效果很好。非常酷的是，当我和我们的工程师讨论时，问题是：如何把这个从简单的 playground 代码转化为生产代码？我所做的就是获取 playground 中的目录，喂给 LLM，然后说：“让它在生产环境中工作。” 它一次就完成了，而且做得完美。动画完美无瑕。它如此简单，工程师 Rob 和我都说：“这太棒了。” 然后我告诉我们的产品负责人 Max，他说：“我们能这样做真是太棒了，对吧？”

Yeah, I mean, I think with a lot of this motion design stuff, coding tools are so good at executing it, but you have to be very, very descriptive about what you want, otherwise you're going to be fighting these things for like hours. You're going to be pulling your hair out, going in circles. So, for me, it's like a picture's literally worth a thousand words. And so, I can just do this, make like, okay, here's what Nozi is going to do at the end, it's going to come back over here, and I'm going to label what state this is in. And then we come out the other side, and we actually have something that works in code. This wasn't one shot, it's like you have to refine it over time, but the animation actually worked really well. And what was really, really cool is when I go and speak with our engineers who are working on this, it's like, how do we translate this from simple playground code to production code? All I did was I took the directory that this was in in the playground, fed it to an LLM, and said, "Make this work in production." And it one-shotted it and did it perfectly. The animation was flawless. It was so simple that engineer Rob and I were both like, "This is so sick." And then I tell Max, our head of product, about that, he's like, "This is so sick that we can do this, right?"

我觉得这对很多团队来说是一种理想设置，但我们仍然处于每个人都需要从头构建的阶段。但就像你刚才描述的，你有轻量级的原型 playground，我猜它可能甚至超过了 Notion 的 80/20 原则。你真的得到了一个可以摆弄的前端，然后那个转换步骤，如果它接近一次完成，就像你描述的那样，感觉是几乎所有地方的理想工作流程。看到你的流程甚至涉及画布，真的很酷，整个管道很整洁。很整洁。我们必须在这些组织中为彼此构建自己的工作流程。给人们工具来做出非常有力的决定，这对我们来说是最强大的，对吧？作为设计师，我们可以做到，对吧？所以我们可以创建这些原型，给人们足够的自由来参与过程，同时也依赖我们作为设计师的训练来设定一些规则和观点。

I feel like that's kind of the dream setup for so many teams, but we're still in this phase where everybody has to build it out of the box right now, but like what you just described, where you have the lightweight prototype playground, I'm assuming it's probably even more than the 80/20 of Notion. Like you really get the front end that you can kind of play with, and then that translation step, if it's anything even close to a one-shot, like what you just described, it feels like the ideal workflow for teams kind of everywhere. It's really, really cool to see your process even involving the canvas, too, like that full pipeline is neat. It's neat. We have to build our own workflows for each other in these organizations. Giving people the tools to make really strong decisions is the strongest thing for us, right? Like, we as designers, we can do that, right? So, we can create these prototypes that give people enough freedom to involve them in the process, but also relying on our own training as designers to set some rules up the opinion.

我们最终实际上做了对冲，对吧？所以我们不得不构建三个不同版本，因为内部我们认为这个新的模态框变体非常棒，但可能会让人困惑。为什么它是方形的？模态框通常不是方形的。我们担心它可能转化效果不好。所以当要发布这个东西时，我们不得不：好的，我们需要一个有三个头的版本。我们需要一个四个头的版本，动画不那么有趣。然后我们还有，你知道，我称之为安全版本，在右边，显示我们的 Nosey 脸和右边播放的一些视频。当要发布时，我们为每个版本设置了静态增益，我们非常密切地观察。我们同时发布了所有三个版本。我们看哪个转化最好。我想问你，Rid，你猜哪个转化最多，最高？你的猜测是什么？我真的很希望是左边那个。

We ended up actually like we had a hedge, right? And so, we had to build three different versions of this because internally we're like, this new modal variant is really sick, but it could be confusing to people. Why is it a square? Modals aren't usually square. Like, we were worried that it might not convert super well. So, when it came to ship this thing, we had to be like, okay, we need one with three heads. We need one with four heads that doesn't animate as interestingly. And then we had, you know, what I call the safe version on the right where it's like, here are our nosey faces and some kind of video playing on the right. And when it came to ship it, we had static gains for each one and we were watching these really intensely. We shipped all three at the same time. We were seeing which one would convert the best. And I was left to ask you, Rid, what are your guess which one of these converted the most, like the highest? What would be your guess? I really want it to be the one on the left.

但是，我担心你会说是安全版本。

But, I'm nervous that you're going to say the safe one.

好吧，在我告诉你之前，我想说 Ivan 和我们的产品负责人 Max 打了个赌。他们说，好的，我们赌 500 美元哪个会赢。我说，我们不能赌钱。我们赌个礼物吧。

Well, before I tell you, I want to say like Ivan and then our head of product, Max, had a bet. And they're like, okay, let's bet like 500 bucks on which one's going to win. And I was like, well, we can't bet money. Let's bet like a gift.

然后他们两个……所以 Ivan 押了你选的那个，也就是四头版本，Max 押了三头。但我不想说，安全的那款赢了。是啊，我就知道。我几乎都害怕揭晓结果。

And they both... So, Ivan bet on the one that you bet on, or the four-head version, and Max bet on the three. But I hate to say that the safe one did. Yeah, I knew it. I was just almost dreading the reveal.

关于这件事，我的假设……你看看按钮的大小，老兄。一个按钮巨大，另一个按钮很小。我们为这个细节纠结了大概一个月，对吧？结果发现可能只是按钮大小的问题。你要是把按钮做大一点，它就会……但好吧，这只是个小插曲。

The thing about it, my hypothesis... Look at the size of the buttons, man. One had a huge button, the other had tiny buttons. So we sweat the details on this for like a month, right? And then it just turns out it's probably just the size of the button. Could you just make this button bigger, it would... But yeah, that's that little digression.

这挺好的。不过我很感谢你分享工作流程的幕后故事，看到我每天使用的产品的完整端到端过程很有趣。这也是我做这个播客最喜欢的一部分。你稍微提到了展示你是如何制作的，让人们可以在模态框里编辑内容之类的。我想知道我们能不能再深入一层，考虑到这种转变。你谈到前端做事更快了。现在你转向代码，可能更经常从代码开始。这如何改变你和团队协作的方式，当你不能再直接跳进 Figma 文件里高亮某个人时？

That's good. But I appreciate you giving a little behind the scenes of the workflow, and it's fun to see the full end-to-end process for a product that I use every day. That's always one of my favorite parts of even doing this podcast. You touched a little bit on showing how you made it so people can edit the content inside of the modal, that kind of thing. I'm wondering if maybe there's another layer we can go into around just given this shift. You talked about how it's a little bit faster to do things on the front end. Now you're moving toward code, maybe starting code more often. How's that changing the way you are collaborating with your team when you can't just hop into a Figma file and spotlight someone anymore?

如果我在做一个非常大的重构——就像我们现在在 Notion 做的——我们在重新思考 Notion 的一个非常基础的概念。我可以直接进 Figma 重新设计每一个屏幕，然后获得反馈。但我发现用 LLM 快速搭建一个 Notion 的粗略原型，让人们可以点击浏览并感受我们提出的所有新方案，要快得多。所以功能越大，我越可能从代码开始。但如果是小东西，比如一个模态框或者打磨、视觉打磨之类的，我觉得 Figma 仍然很有帮助。就我个人而言，我登录 Figma 是因为你可以直接用你的手、你的鼠标直接操作一切。但我仍然觉得它是我的延伸，而不是喂给 LLM 或写前端代码。所以如果是紧凑的功能或视觉打磨，我会进 Figma，画出草图，然后和团队分享。但如果是很大的东西，我们会让 LLM 画出所有这些不同的流程，然后一起评估和推进。

If I'm working on a really big reframe, which we're doing right now at Notion, it's like we're rethinking a really big foundational concept at Notion. And I could just go into Figma and redesign every single screen and get feedback on that. But I found that it's so much faster to just spin up a crude representation of Notion with an LLM that allows people to click around and feel all these new proposals that we're making. So the bigger the feature, the more likely I am to start in code. But if it's a smaller thing, like a modal or polish, visual polish, something like that, I find Figma to still be really helpful. And personally, I'm logged on Figma because you can just directly manipulate everything with your hand, your mouse. But I still feel like it's an extension of me rather than feeding an LLM or writing some front-end. So if it's a tight feature or visual polish, I'm going to get into Figma, sketch something out, and then share that with the team. But if it's something really big, we'll just sketch out having an LLM sketch out all these different flows, and then we can evaluate and work through those together.

协作这部分，更多的是……这也是最近经常出现的问题。你真的要摸清和你一起工作的人，他们想怎么和你合作。没有一刀切的答案。如果我和一个完全不想做前端的工程师合作，这个人只痴迷于深入后端，让东西高效且性能好，我现在有技能用这些工具做大部分前端，然后提交 PR，从这些人那里获得高质量审查，用这种方式分担工作，对吧？这些头衔正在被打破很多。但如果我和一个团队合作，他们有余力快速搞定前端，我可以搭建一个粗糙的原型，甚至快速的 Figma 草图，然后我们一起在代码上迭代，甚至截图、标红线，有时真相来源就飘在那里，更像是‘嗯，我们想打磨这个东西。我们没有放进 Figma，但代码里看起来不错。所以让我们截个图作为真相来源。’我想你会惊讶于 Notion 里有多少 Figma 文件只是产品的截图，然后一小块是一个新 Figma 画板在一个小标签页里。

The collaboration part of things, it's more about... and this is a question that's come up a lot lately. You really have to suss out what the people you're working with, how they want to work with you. And there's no one-size-fits-all answer. If I'm working with an engineer who really doesn't want to work on the front-end, and this person just is obsessed with doing a deep dive on the back-end making this thing efficient and performant, I now have the skills using these tools to do most of the front-ends, and then ship PRs that I can get really high-quality reviews from these folks on, and kind of share the work in that way, right? Like these titles are kind of breaking down a lot. But if I'm working with a team and they have bandwidth to just fly on the front-end, I can build a crude prototype or even quick Figma mocks, and then we go in and we can iterate on the code together and like even take screenshots, redline stuff, and then sometimes the source of truth is kind of floating up there, and it's more like, 'Well, we wanted to polish this thing. We didn't put it in Figma, but it looks good in code. So let's take a screenshot that's our source of truth.' And I think you'd be surprised how many Figma files in Notion are just screenshots of the product, and then a little chunk of it is a new Figma frame on a little tab.

是啊，我也做过不少截图生产环境然后在上画东西的事，但我在设计文件上也有点控制狂。所以我几乎总是认为这是真相来源，或者至少是生产环境的一个很好的呈现，而且整理得井井有条，当我知道某个设计部分没有跟上生产环境时，我几乎会感到缺失或错失恐惧症。现在这完全消失了。基本上画布上没有任何文档。唯一一次是我用 Paper Chrome 扩展从生产环境复制一个组件然后粘贴进去。嗯，也许你能做到。但真相来源已经完全转移到生产代码，我的画布现在是我整个职业生涯中最乱的，一开始让我有点抓狂，但我现在已经完全适应了。就像我根本不在乎画布里有什么了。

Yeah, I did my share of screenshotting prod and drawing something over it, but also I'm a bit of a control freak when it comes to a design file, too. So I was almost always had like this is the source of truth or at least a really good representation of what is in prod and it's neatly organized and I would almost feel this lack or FOMO when I knew that a piece of the design was not up to date with what is in prod. And now that is just completely went out the window. Like there's basically no documentation that lives in the canvas. The only time is like I'll use the Paper Chrome extension to just copy a component from prod and paste it in. Like yeah, maybe you can kind of get there. But the source of truth is entirely shifted to production code and my canvas is now the messiest that it has ever been in my entire career and it was freaking me out for a little bit but I totally settled into it now. It's like I just don't really care what's in the canvas anymore.

这就是每个人在申请设计师工作时说的。比如，我们寻找的第一技能是什么？处理模糊性，对吧？比如我们如何生活在这个一切都在变化的世界里，路线图可能模糊不清，你可能在抓不同的目标之类的。我认为就你的观点而言，我真的想让你教一课如何使用 Paper，因为我一直在关注你使用它的过程。我有时觉得自己活在石器时代，但没错，你只需要冷静地看待用户实际会看到的东西，痴迷于那个产物，确保无论迭代形式如何，都要做到 100% 正确。然后 Figma 和这些草图，归根结底只是参考工具。所以它们必须让你的团队能够访问，他们必须知道他们在看什么，但我知道答案是“看情况”，但我想更深入一点，了解你作为头衔只是设计师的人——你不是设计工程师或其他什么——那么，给定这一点，你实际上有多少次负责某个功能中上线的某个元素或某部分前端？代码只是更好的原型工具吗？你完全拥有前端吗？还是说大多数时候只是纯粹的草图？因为我现在也在经历类似的情况，感觉每个项目都完全是一次性的，我发消息给工程师说：“这个你想怎么做？”因为我们都在摸索。所以能不能再具体一点，说说你每个项目的具体交付物是如何变化的，大致分布是怎样的？

That's what everyone says when you're applying to a job as a designer. It's like, what is the number one skill we look for? Dealing with ambiguity, right? Like how do we live in this world where everything's changing and how the road map might be nebulous and you might be grasping at different objectives and things like that. And I think to your point, I honestly want you to teach a lesson on how to use Paper cuz I'm following your journey with that. I'm like I feel like I'm in the stone age sometimes, but yeah, you just have to be cool with looking at the thing that users are going to actually see and obsessing over that artifact and making sure whatever form of iteration on that takes, make sure that is going to be 100% right. And then Figma and these mocks, they're just reference tools at the end of the day. And so they have to be accessible by your team and they have to know what they're looking at, but I know the answer is it depends, but I want to go a little bit deeper just to understand how often you as someone your job title is just designer, right? You're not a design engineer or anything. Okay, so given that, how often are you actually responsible for some element or some piece of the front-end that is shipping on a given feature? Like, is code just a better prototyping tool? Are you owning the front-end at all? Or how often is it just pure mocks? Because I'm kind of experiencing that too, right now, where it feels like every single project has to be completely ad hoc, where I message the engineer and I'm like, 'How do you want to work on this one?' Because we're all just kind of figuring it out. So can we get one level more specific in terms of how the concrete deliverables change for you project to project and roughly what the spread is?

对于我们大多数项目，我会说我们的工程师会把事情做到 80%。

For the majority of our projects, I would say our engineers take things to 80%.

有些工程师如果有余力会做到 100%，但我在 Notion 的个人工作流中发现，我们的工程师会把所有东西都连接好，让它性能出色、真正可用，但最终成品看起来就像我们所说的“T-move 版本”的产品，对吧？就是还没完全到位。所以我们可以并行工作：我介入，提交一些很小的 PR，只做视觉打磨，完成最后那一公里。这些 LLM 在设计的最后阶段表现并不好，而这仍然是我们的超能力，也必须是我们的超能力。我们的工程师能把产品做到 80% 到 90%，然后，在 Notion 这样一家痴迷于工艺和品味的公司，交付一个包装精良的工具，最终结果由我们设计师来负责——就像我们在 Notion 常说的那样。这完全取决于我们。如果没人做，那就得有人去做，对吧？我认为我们再也没有借口不为那些我们想看到的改变负责了。归根结底，这些数字产物是我们自身的延伸。我有点跑题了。但这些数字产物是我们工作和实践的延伸。我们现在有能力完全掌控它如何被交付。所以，回答你的问题：大多数时候，我接手的是最后 20%，或者说 5% 到 20% 的前端工作。我不怎么从头构建功能，也不做很多连接工作，但我做大量动画、大量视觉设计，以及任何只要我描述得足够清晰、能用语言告诉 LLM 做什么，它就能做得很好的事情。

Some will go 100% if there's bandwidth, but I think that what I've found, my personal workflow here at Notion, is I think our engineers will wire everything up, make it very performant, make it actually work, but then it looks like we call it the T-move version of the product, right? Where it's like it's not 100% there. And so, what we can do is parallelize the work, where I could come in and make itty-bitty PRs for just visual polish and finish that last mile, right? These LLMs are not very good at the last mile of design. And that's still like our superpower and needs to be our superpower. Our engineers will bring it all the way up to 80 to 90% and then, you know, working at a company like Notion, where we are obsessed with craft, taste in delivering a very well-boxed tool, well-packaged tool, it's up to us as designers to just own the outcome, as we say here at Notion. Like, it's just on us. If it's not going to get done, then someone else has to do it, right? And I think we have no excuse anymore to not be responsible for those changes that we want to see. And at the end of the day, these artifacts are extensions of us. I'm on a tangent now. But, like, these digital artifacts are extensions of our work and our practice. And we have the ability now to just own how that gets delivered. So, yeah, the answer to your question is most of the time for me I'm picking up the last 20, or let's say 5 to 20% of the front-end work. And I'm not doing a lot of building features from scratch. I'm not building a lot of wiring things up, but I am doing a lot of animation, a lot of visual design, and just anything that an LLM can be really good at if I'm very descriptive and have the language to tell it what to do.

那么，是否可以这样理解：如果你的流程是从代码开始的，面对一个较大的项目，你想用 LLM 来搭建一堆不同概念的脚手架，那所有这些最终都会被丢弃，不会有太多交接。到某个时候，你只会说：“好了，我们就这么做。”工程师可能会从头开始，然后你又在最后阶段介入。这样感觉对吗？还是说存在不适用的情况？

So, is it safe to say then that if your process is going to start in code given something larger where you want to have an LLM to scaffold a bunch of different concepts, all of that is going to be throwaway. That's not going to be much of a handoff. At some point you're just going to be like, "Okay, this is what we're going to do." The engineer is going to probably start from scratch, and then you're going to come in again at the end. Does that feel correct, or is there situations where that doesn't apply?

我觉得完全正确。但我不一定认为那些初始的脚手架工作、你做的那些大型原型——即使是一个庞大的原型——把它归类为“可丢弃的工作”可能有点用词不当。因为归根结底，我不希望任何人用 Claude 一次性生成我每天使用的应用，对吧？我希望有一个非常深思熟虑的工程师团队去做他们擅长的事，大干一场。而我拼凑出来的工作，只是用另一种媒介在画布上呈现东西而已。

I think that's it exactly. But I wouldn't say that necessarily that that initial scaffolding work, the big prototyping that you're doing, like even if it's a massive prototype, I think classifying that as throwaway work, I don't know, it might be a misnomer because at the end of the day, I don't think I'd want anyone to build the app I use every day just one-shotting it with Claude, right? I would want a very thoughtful team of engineers to do what they do and go to town on it. And then the work that I put together, it was just a different medium of putting something on canvas.

我想在这里多聊一会儿，因为这个问题我一直在想。我知道我们聊得很深，但这确实很有挑战性。我也在经历同样的事。有太多不同的顺序安排可以尝试：什么时候介入，你负责什么，谁最终发布产品。就在我们通话之前，我手头有一个 Teemu 版本的东西，我正在做你描述的一模一样的事。我大概是最后 15%，我负责前端的一切。我也会是最后一个碰这段代码的人。在它发布之前，我掌控着 UX 的每一个细节——它的感觉、它的外观，我很喜欢这样。这对我来说比较明确。但棘手的是，昨天我在做一个原型，要引入一个代码中完全不存在的全新视觉原语。我甚至不知道它好不好，这正是重点。我通过原型来探索它。我想把它发给别人，让他们使用、录下操作过程并给我反馈。这时就变得棘手了，因为我可以完美地用生产代码库搭建出 80% 的原型，但有一个 schema 级别的改动和一两个小的 mutator 需要添加，而我不想在非必要的情况下深入底层。我只是想快速做一个原型。所以，我现在做的东西大概 50% 是模拟数据。感觉足够真实，但显然不能用于生产。不过视觉效果很好，工程师肯定不想从头再来。于是我们稍微颠倒了顺序：我说，“嘿，我已经搭好了脚手架，效果不错。你能把后端的数据层搞定吗？”这里面有很多利弊，而且情况一直在变。我不知道你在多大程度上尝试这类东西，但当你用代码玩耍时，根据你介入的时间和方式，流程确实会发生很大变化。自私地说，我很好奇，这个问题解决了吗？你喜欢这样工作吗？

I kind of want to hang out here for a second because this is so top of mind for me. I know we're going really deep, but it's so challenging. Like I'm experiencing this too. There's just so many different sequencing ideas to play with, and like when do you insert yourself, and what do you own, and who actually ships the thing, because I'm right now, before we jumped on this call, I have a Teemu version of something and I'm doing the exact same thing that you're describing. Like I'm probably the last maybe 15% and I'm owning everything about the front end. I'm going to be the last person that touches this code, too. Like before this goes out the door, I'm the one that's owning every single piece of the UX, how it feels, how it looks, and I love that. That is a little bit more cut and dry for me. Where it gets trickier is, you know, yesterday I'm doing a prototype where I'm going to introduce an entirely new visual primitive that doesn't exist in the code. And I have no idea if it's even going to be good. That's the whole point. I'm prototyping to explore it. I want to send it to people. I want to have them use it, record themselves playing with it, and give me feedback. Then it gets a little bit trickier because I can get 80% of that prototype wired up using the production code base perfectly. But then there's like one schema level change and one or two little mutators that have to be added and I don't really want to go down there if I don't have to. I'm just trying to make a quick prototype. So, now I'm making something that is maybe 50% mock data. Feels real enough, but like it's obviously not production ready. But the visuals are pretty good, you know, like the engineer definitely does not want to have to start over on this. And so, now we've kind of flipped the sequencing a little bit where it's like, "Hey, I've built the scaffold. It's good. Can you just get the data layer to work on the back end?" And there's so many different pros and cons and it just keeps changing, but I don't know how much you're experimenting with that type of stuff, but it really changes the process depending on when and how you insert yourself when you're playing in code. Selfishly, I'm curious, has that been resolved? Like how do you like working like that?

我认为这又回到了你之前说的：你几乎必须和工程师沟通，了解他们是什么样的人，然后问“你想怎么处理这件事？”我还没有好的答案。我正在积极探索很多事情，这也是为什么我想听听你的想法。因为我注意到自己实践中的另一个转变，你可以告诉我这有没有共鸣，或者能否激发其他想法。当我们构建一个较小的功能，目标是真正发布时，大多数情况下如果只是前端代码，那就没问题，对吧？做出好的 UI 代码并不难。但一旦涉及到任何更具战略性的东西，就会变得不确定。我见过一些 PR，工程师说：“你构建这个的基本前提就是错的。我现在为什么要看代码 diff？你采用的根本方法就是错的。”不管你有多少 Claude 和 Codex 的审查，这仍然是错的。所以现在审查更多地转向了规划模式，而不是代码本身。我会先进入规划模式，弄清楚我想做什么，然后把它作为一个 MD 文件发过去。工程师会审查那个计划。如果计划看起来不错，他基本上可以相信这不会搞砸事情，对吧？因为其他所有东西都已经设计好了。我开始更多地这样做，但这就是我提出这个问题的原因，也是为什么我比平时说得更多——因为我真的在努力想清楚这件事，我不知道该怎么办。

I think it goes back to what you were saying where you almost have to message the engineer, have an understanding of who they are, too, and just like "How do you want to handle this thing?" And I don't have a good answer yet. I'm actively exploring a lot of things, which is why I kind of seeing what you're thinking about because I'll give one other shift that I've noticed in my own practice, and you can tell me if this resonates or sparks other ideas, too. But like, when we are building a smaller feature that the goal is to actually put something out the door, most of the time if it's just front-end code, it's good, you know? It's not hard to make good UI-based code. As soon as it touches anything else more strategic is where it gets iffy. I've seen some PRs where the engineer is like, "The fundamental premise of how you built this is wrong. Why am I looking at a code diff right now? The fundamental approach that you took is wrong." And it doesn't matter how many little Claude and Codex reviews you had, this is wrong. So now more of the review is actually shifting to planning mode rather than the code itself. Where I will go through a planning mode, get an idea of what I want to do, and then I'll just send that as an MD file. The engineer will review that. If the plan looks good, he can mostly trust that this is not going to destroy things, you know? Like everything else is designed at this point. I'm starting to do that a little bit more, but this is why I was bringing it up and why I'm talking way more than I normally do because it's like I'm really trying to figure this out right now because I don't know what to do.

我们都有这种状态，一聊到这个我就说：“快给我讲讲。”是啊，我也想学。我个人发现，我要让 LLM 或智能体在我们的生产代码库里做什么，但我并不太懂需要用哪些语言来让它做对事情，对吧？我不是科班软件工程师。这些智能体非常擅长充当翻译层。比如我可以构建一个在生产代码库里很糟糕的东西，但看起来特别棒。然后我发现我们可以这样做。接着工程师可以构建实际的功能。然后，不是扔掉我们做的所有工作，而是让智能体说：“好，我有这个功能，我构建了它。我是设计师，它很烂，但看起来超酷。”然后我们有一个工程师的功能，性能很好，但这是团队版本。你能保留工程师版本的所有功能，并赋予它我这里的全部样式吗？我认为这能比直觉预期的更接近目标。因为突然之间，它不需要翻译任何东西。它已经有了前端代码，只需要把正确的值应用到正确的地方。所以，即使在我们做 Make with Notion 模式时，那也是完全不同的代码库，对吧？Notion 不用 Tailwind 或 shadcn。但我构建那个代码库时两者都用了。那是大约 6 个月前，我记得用的是 Opus 4.5。它一次就搞定了。

We're all in this state where you start talking about this, I'm like, "Give me the pitch." Yeah, same. I want to steal these. One thing that I found personally is like what I'm going to tell an LLM to do, that like an agent to do in our production code base, I don't know a lot of the language that I need to use to get it to do the right thing for me, right? I'm just not a software engineer by trade. These agents can be really good at acting as translation layers. So like I could build something that just absolutely sucks in production code base, but man, it looks so good. And then what I found is we can do that. And then an engineer can build the actual feature. And then, instead of throwing away all the work that we did, is like have an agent be like, "Okay, I have this feature. I built it. I'm a designer. It sucks, but it looks so sick." And then we have an engineer's feature that's so performant, but it's the team version of this. Can you keep all the functionality of the engineer's version and give it all the styling that I have here. And I think that can get you so much closer than our intuition says it would. Because all of a sudden, it just doesn't have to translate anything. It already has the front-end code. It just has to apply the right values to the right things. And so, even on the Make with Notion mode when we did, that was a totally different code base, right? Notion doesn't use Tailwind or shadcn. But the code base I built that in used both. And this was like 6 months ago with I think it was Opus 4.5. It crushed it. It did it in one shot.

这挺让人惊讶的。我本来没料到。说到底，那是 CSS 和 JavaScript，Opus 尤其，Claude 整体上非常擅长前端。Composer 非常擅长前端，对吧？而且它们每天都在变得更好。我非常喜欢用 Cursor 的一个原因是它的 harness 非常棒。我就知道如果让 Composer 做前端功能，我非常有信心它能做得很好，对吧？而不是我自己在 Claude Code 里乱搞，试图找到正确的做法。我觉得有些工具可以当作脚手架来用。里面已经有很多预先做好的工作，我基本上可以直接拿来用，然后跟着感觉走。

That's surprising. I wouldn't have expected that. I mean at the end of the day it's CSS and JavaScript and Opus in particular and Claude in general really really great at front-end. Composer really great at front-end, right? And they're only getting better every day. And one of the reasons why I've really enjoyed using Cursor is because their harness is incredible. And I just know if I have Composer do a front-end feature, I'm ultra confident that it's going to do a really good job at that, right? Rather than me hacking in like Claude Code and trying to find my way to the right thing. I think there are these tools where you can kind of use them as scaffolds. And there's a bunch of pre-work that already went in there that I can just kind of steal from and vibe with, essentially.

这是第一次有人对我说，Cursor 的 harness 可能让前端变得更容易一些。所以我作为一个 6 个月前用过 Cursor 但现在还在用 Conductor 的人，正在消化这一点。我知道你最近抛弃了我，又回到了 Cursor。所以今天很难跟上。

It's the first time somebody has actually said that to me where maybe the harness from Cursor is making front end a little bit easier. So I'm just sitting with it as somebody who yeah, I used Cursor 6 months ago, but I'm still in Conductor, which I know you've recently abandoned me and my back to Cursor. So it's hard to keep up today.

在你和 Brian Love 的对话中，他非常敏锐地说我们不能对这些工具有部落主义，对吧？我们只需要在合适的时机用合适的工具。我偶尔还在用 Conductor。我觉得它是个很棒的工​​具，但过去一个月左右，Notion 这里的一位设计师问我：“你试过 Cursor 3.0、Cursor Glass 吗？”我说：“没有，老兄。我是 Conductor 信徒，我永远不会转。”然后我打开 Cursor，心想：“我靠。”当然，Rio 做的。那边的团队太棒了。Composer 是个很好玩的模型。而且，你知道，他们有工作树，有多智能体工作流。最近我很喜欢 Cursor 的一点是计划模式。我让某个模型制定计划，生成一个 MD 文件，然后渲染得非常漂亮，甚至包括 Mermaid 图表之类的东西。我就想：“哦，作为一个视觉型的人，这是对你将要做什么的美丽呈现。”

In your conversation with Brian Love, he was very astute and said we cannot get tribal about these tools, right? We just have to use the right tool at the right moment. I'm still driving with Conductor every now and then. I think it's an amazing tool, but I think for the past month or so, one of the designers at Notion here was like, "Have you tried Cursor 3.0, Cursor Glass?" I was like, "No, dude. I am a Conductor life. I'm never going to turn." And then I open up Cursor and I'm like, "Holy shit." And of course Rio made it. The team over there is just so good. Composer is such a fun model to jam with. And then, you know, they have work trees, they have multi-agent workflows. Something about Cursor that I'm loving these days is plan mode. So I have like whatever model make a plan, creates an MD file, and then it renders it really really beautifully, and it even includes things like mermaid charts and things like that. And I'm like, "Oh, as a visual person, this is a beautiful representation of what you're going to do."

是啊，很酷。而且都在一个框架里，对吧？我有浏览器窗口，有终端。如果我想在云端运行，我有个虚拟机，我可以合上笔记本，去做我的事。我知道 Conductor 也在做同样的事。作为设计师，看到 Cursor 那边真是火力全开。非常非常棒。我觉得我们有漂亮的工具来创造漂亮的工具。我认为这是一个反馈循环，看到创造这些工具的人如此有创意和有趣，总是很鼓舞人心。这又增加了一层灵感。

Yeah, that's cool. And it's all in one frame, right? I've got my browser window, my terminal there. If I want to run it in the cloud, I have a VM there, and I can just shut my laptop, go do my thing. I know Conductor's working on the same thing. As a designer, seeing Cursor just absolutely they're cooking with gas over there. Really really sick. And I feel like we have beautiful tools to create beautiful tools. And I think that that is a feedback loop, and it's always inspiring to see people who are creating these things are so creative and interesting. It just adds another layer of inspiration.

有一个我忍不住问自己的问题：如果公司主动申请和你对话，而不是反过来呢？这个问题是全新 Dive Talent Network 的基础。它正在发挥作用。现在，我正在帮助许多我知道的最令人兴奋的初创公司，招聘收听本节目的设计师和构建者。所以，如果你好奇外面有什么机会，或者想加入我的名单，甚至正在寻找你的下一个设计招聘，请访问 dive.club/talent 立即加入。

There's one question that I can't stop asking myself. What if companies applied to talk to you rather than the other way around? And that question is the foundation for the all new Dive Talent Network. And it's working. Like, right now, I'm helping many of the most exciting startups that I know to hire the designers and builders who listen to this show. So, if you're curious what might be out there, and maybe you want to get on my list, or maybe you're even looking for your next design hire, head to dive.club/talent to join today.

我们能谈谈最后那部分吗？也许最后那部分有 20% 那么大，那很多了，你知道，前端设计中 20% 真的很多。所以，我有点好奇，当你写提示时，我猜你实际上会进入代码并在 Cursor 里写 CSS。我也猜仍然有相当多的提示。那么在提示这个类别里，有多少呢？我觉得有个频谱，对吧？一端是你在 Figma 中创建精细的图表来精确描述你想要的东西，就像你展示模态动画时那样。另一端是给 AI 留一点发挥空间，也许我故意不那么详细描述，因为我就是想看看会出来什么。你在这个频谱的不同部分之间切换的频率如何？你现在如何看待把最后一些前端细节落地？

Can we talk about the last mile piece? Maybe the last mile is as big as 20%, which in that case, that's a lot, you know, 20% of the design, really, in the front end. That's a lot. So, I guess I'm kind of curious, when you are prompting, I'm assuming there's some you're actually getting into the code and writing CSS in Cursor. I would also assume there's still a decent amount of prompting too. So, in the prompting category, how much of this? I guess there's this spectrum, right? On one end of the spectrum is you are creating granular diagrams in Figma to describe exactly what you want, like you were showing with the modal animation. On the other end is allowing for a little bit of wiggle room with AI, where maybe I'm intentionally going to not be as descriptive because I kind of just want to see what comes out. How often are you moving between different parts of that spectrum? How do you think about landing the plane on some of the finer front-end details right now?

但是，当我开始使用 Conductor 时，我真的很慌，因为我不再 24/7 看代码了，对吧？我认为这是他们使命的一部分，对吧？他们希望人们不要写代码。因为在 Conductor 之前我写很多前端代码，还在 Cursor 里工作，做 tab 补全等各种手动编码方法。但现在，如果我在做最后比如 20% 到 15% 的功能，我让 LLM 构建它，然后我把它调整到想要的状态。我不会在它工作时试图对抗它，手动做一堆事情。一旦它达到我想要的状态，我就看大量的 diff。

But, when I started using Conductor, I got really freaked out because I was not looking at code 24/7, right? And I think this is part of their mission, right? They want people to not use to like not write code. Because I was writing a lot of front-end code before Conductor, and still just working in Cursor and doing, you know, tab complete, all these different manual coding methods. But now like if I'm doing the last let's say 20 to 15% of a feature, I let the LLM build it and I get it to where I want it to be. And I'm not trying to fight it and do a bunch of stuff manually while it's working. And then once it gets it to where I want it to be, I just look at a lot of diffs.

好，它这里做了什么？那里做了什么？我给很多问这类工作流的人的建议是：作为设计师，而不是受过完整工程师训练的人，你的 PR 应该非常非常小且可控。如果你自己不放心审查代码或自己写代码，我觉得经验法则是：如果你期望别人花在阅读 PR 上的时间比你制作它花的时间还多，那就是工作量不匹配，对吧？写文档之类也是同理。我想把那个五行 PR 打磨得完美，这样它足够小、容易发布，我审查时就知道它不会出问题。然后交给工程师，他们就说：“好，没问题。盖章。搞定。”我们必须把工作拆成可控的块。五行不太现实，但一百行左右的 PR 是我的一般建议：不要一股脑写一堆代码，然后丢给工程师一个你没审查过的五百行 PR。因为那样会很尴尬，对吧？他们会问：“嘿，这个 PR 怎么回事？”你就说：“你告诉我吧，我就是玩了一下。”呃，这个对话现在有点太贴近现实了。

Okay, what did it do here? What did it do there? And some of the advice that I tell a lot of folks who are asking you about these exact kind of workflows is like your PRs as a designer and not an engineer who's got all the training of an engineer, your PR should be very very small and manageable. If you're not comfortable reviewing the code yourself or writing the code yourself. I think the rule of thumb here is that if you are expecting someone to put more time into reading something like a PR than you put into making it, if there's a mismatch of work being performed, right? And then it goes for like writing docs and stuff, too. I want to finesse the out of this five-line PR. And so then it's so small and easy to ship that I can review it and know like this isn't going to cause problems. And I give it to an engineer, they're like, "Okay, cool. Stamp. Boom. Out the door." We have to break the work into manageable chunks. Like five lines is not very realistic, but a hundred-line PR, that's my general advice of like don't five-code a bunch of stuff and send an engineer a 500-line PR that you didn't even review yourself. Cuz then it's just like an awkward conversation, right? You're like They're like, "Hey, uh what's up with this PR, man?" And it's like, "You tell me, man. I just kind of like had some fun." Uh this conversation's hitting a little bit too close to home right now.

不，我也一样。这些都是我吃过亏才学会的，对吧？是的。

No, same for me. I learned these things the hard way, right? Yeah.

我想在你回答的开头部分再深入一层，你谈到如何用模型把最初的东西放到页面上。你的目标有多大程度是精确复现脑海中的画面，还是说你也会有点随性看看会发生什么？这是你实践的一部分吗？我问这个是因为我看了你那些带小动画表情的模型。我昨天也做了个非常类似的东西，只是一个网站的小功能卡片，没那么复杂，因为我用 CSS 遮罩把边缘淡出了，算是开了简单模式。但我脑子里其实没有太多想法。我知道我想要一些 logo 循环展示，但我就只想让它水平移动并在边缘淡出，仅此而已。我故意没有给出更多意图，因为我就想看看它会不会带我走向不同的方向。这也是你实践的一部分吗？你是这样思考的，还是说更像是“我看到东西，我们就做出来”？

I'm going to go one level deeper on the beginning part of that answer where you talked about how you kind of just get the initial thing onto the page with the model. How much of your goal with that initial thing is exactly what you were picturing in your mind versus Did you ever kind of just see what happens a little bit? Like is that part of your practice? And the reason I ask is because I was looking at your models with the animation with the little motion faces. I built something very similar yesterday. And it was just for a website little feature card. Not as complex cuz I was able to fade out the edges with a little bit of like a CSS mask. So I kind of got to play on easy mode a bit. But I didn't really actually have that much in my head. I knew I wanted something to cycle through these logos. But I kind of was like I just wanted it to move horizontally and fade out at the edges. And that's it. And I very intentionally did not give any more intent there because I kind of just wanted to see to see if it would take me a different direction. Is that part of your practice at all? Like do you think that way or is it very much so like I see the thing, let's build the thing.

这 1000% 是我的流程。我想一年半前我在 Tone/Lightfield 的时候，那是我第一次开始把 Claude 当作协作伙伴。不完全是 Claude Code 和它写的前端，而是像问 Claude 问题：“嘿，我做了这个功能。好了，我在 Figma 里有了。你觉得怎么样？”在 Notion 工作我最喜欢的一点是，身边都是非常有创意、超级善于表达的人。但有时候他们没空。去年我几乎是唯一的设计师，对吧？所以我必须用不同的方式使用这些工具。我喜欢看 Claude——它索引了整个互联网——能想出什么，以及它如何评价我的工作。我不认为它每次都能给出精准的建议，但它会产生很多替代想法，比如“天哪，我从没想过可以这样做”。至于你提到的做出狂野的东西，让一些东西给你惊喜，然后说“好，不错”，我觉得我特别喜欢的一点是，在 Notion 这样的公司工作，有很多一次性组件。我们把这个菜单做成了它自己的东西，比如我们给菜单项做了自己的样式。但我们的代码库有一个非常强大的菜单系统。如果我们直接用它呢？我就问 Claude：“好，我们需要重做这个菜单，我想尽可能多地使用设计系统。”它会把东西组合起来，让我觉得：“天哪，我们所有零件都在这里，只是用了很久的遗留代码。现在我们有了这个新版本，甚至不需要做什么。它性能更好，看起来更棒，更符合我们最近在做的方向。”从最初的草图版本开始，我大量使用 Claude Artifacts，比如“给我看看你这个图表的版本会是什么样”。它会创造出有无数渐变和标签的东西，看起来像个软糖工厂，对吧？

That is 1,000% of my process. Like I think a year and a half ago when I was at Tone/Lightfield, that was when I first started using Claude as a collaborative partner. And less so like Claude code and like the front end that it's writing, but just like asking Claude questions about, "Hey, I built this feature. All right, I have it in Figma. What do you think of this?" My favorite thing about working in Notion is you're just surrounded by really creative, super super articulate people. But sometimes they're not available. And like last year I was like the only designer, right? So I have to like use these tools in a different way. I love seeing what Claude, which has indexed the entire internet, comes up with and how it evaluates my work. I don't think it's going to like give me spot-on advice every time, but it'll generate a lot of alternate ideas. And like, "Oh my god, I never thought about doing it that way." And then when it comes to your point to about making something wild, like having something surprise you and then be like, "Okay, cool." I think one thing that I've really enjoyed is that working at a company like Notion, there's a lot of like one-off components. And we like made this menu its own kind of thing. Like we made a menu item its own menu item style. But our code base has an entire like really robust menu system. What if we just built that? Like and and and I'll just ask Claude. I'm like, "Okay, we need to like remake this menu, for instance. I want to use the design system as much as I can." And it'll put things together in a way that I'm like, "Oh my god. Like we had all the pieces here. We were just like using legacy code for so long. And now we have this fresh version of it. We didn't even have to like do anything. Now it's more performant. It looks better. It's more in line with like what we've been jamming on recently." So like all the way from the initial sketching version. And this is I was using like Claude artifacts a lot. Like, "Show me what your version of this chart would look like." And it'll create something with like a million gradients and like a million tags. And it looks like a jelly bean factory, right?

你会说：“天哪。”但然后，你知道，我们可以把它修剪成你真正放心发布的样子。我完全要偷走“软糖工厂”这个说法，我太喜欢了。立刻就有多个 UI 在我脑海里浮现。然后我想：“对，这就是描述它的最佳方式。”好，我们来谈谈这一点。因为我认为，为 Claude 或任何 Codex 创造发挥空间，只有在你能够抵制它给出的通用结果时才有价值。它可以用独特的方式组合东西，但结果仍然会是通用的，在视觉、动效和几乎所有方面仍然会很无聊。那么，你对此怎么看？也许我们可以和一位职业生涯稍早的设计师聊聊，你知道，我们过去常说：“做大量临摹工作，手工制作每一个视觉元素。”但现在，你不再那么频繁地做这些了。所以某种程度上，我担心我们会失去那些造就优秀视觉设计、让你能创造出差异化且克制的作品的实践。那么，你认为如何持续超越 AI 直接给出的东西？

You're like, "Oh my god." But then, you know, we can you can kind of like trim it down to something that you'd actually be comfortable shipping. I'm totally stealing jelly bean factory. I like that a lot. Like immediately multiple UIs just popped into my head. Then I'm like, "Yes, that's exactly how to describe that." Yeah. Let's talk about this piece then, because I think creating wiggle room for Claude or whatever Codex is only valuable if you're able to push back what you're going to get that is generic, because it can combine things in unique ways, but like it's still going to be generic. It's still going to be boring visually, motion-wise, and kind of almost everything. And so, how do you think about that a little bit? Maybe we could talk to a designer who is potentially slightly earlier in their career where that you know, we used to say like, "Do a bunch of copy work, make every single visual by hand and now it's like well, you don't really do that as often. And so in some ways I think maybe I have some concern that we lose the practice of what makes for great visual design and what allows you to be creating things that are differentiated, show restraint. So, how do you think about the way to consistently push past what AI is going to give you out of the box?

培养品味或发展高工艺、高速度的实践没有捷径。我认为有了 AI，我们在创造很多东西上有了捷径。但归根结底，还是要回归到发现和学习视觉设计的语言。通过重复，理解你用的那个词——克制，这个词非常完美。作为设计师，在如今无限 UI 的世界里，我们的工作是如何取其精华，做出一个克制的版本，让形式服从功能，避免为装饰而装饰。所以，我想我给你的无聊答案是：做大量的视觉设计，和很多人交流。

There is no shortcut to having taste or developing like a high craft high velocity practice. I think that with AI, we have shortcuts to creating a lot of things. But at the end of the day, it comes back to discovering and learning the language of visual design. Through repetitions, understanding like you said that you used the word restraint, which is like the perfect word. We as designers, our job now with limitless UI out there, is how do we take it and make a restrained version of this where form follows function and we're avoiding decoration for decoration's sake. And so I think my boring answer to you is like do a lot of visual design, talk to a lot of people.

如果你有非常敬重的设计师，不妨问问他们是如何培养眼光的、如何形成品味的。他们在看什么？看什么电影？喜欢什么书、什么艺术画册？

If there's someone you really respect as a designer, ask them about how they developed their eye, about their taste. What are they looking at? What movies are they watching? Like what books like what art books do they like?

对我而言，在之前做建筑的时候，每个人的作品集看起来都一模一样——主图、一段文字，诸如此类。这是因为网上有成堆的作品集可以看、可以找灵感。我当时就想：我不要做成那样。那时我在学校上绘画课，看了很多艺术画册。这些画册呈现作品的方式、网格的划分、以及那种极其克制、只围绕作品本身的文字——全出血展示作品。我仅仅通过模仿就做出了很不一样的东西。所以，针对你刚才说的“我们不再逐像素复制 UI”，我仍然认为那是一个有价值的练习。重点不在于逐像素地复刻一个静态界面，而在于像 Linear 的侧边栏逻辑就非常有趣：当窗口缩小到某个临界点，侧边栏会自动隐藏，窗口会重构和重排；当你来回拉伸窗口时，交互非常优雅。所以，与其在每个实例中重复做同样的事，不如思考如何重新设计那种交互模式？又如何从某个缓动曲线中学习？

I think for me in a previous life where I was working in architecture, everyone's portfolio looked exactly the same. It's like hero shot, chunk of text, whatever. And it's because online there's just a bunch of portfolios that you can look at and get inspiration from. And I was like I don't want mine to look like that. And I was at the time I was like taking a painting class in school. And I was looking at a lot of art books. And the way that these art books like represented the work and the way that they chunked up the grid and like the really restrained text that is all about the work, just show the work full bleed. And I was able to create something really just by copying. And so, to your point about like we don't like copy a UI pixel for pixel as much anymore, I still tell people that's a worthwhile exercise. It's less so about, you know, doing a static frame pixel for pixel, but like the linear sidebar logic is really interesting because if you minimize the window past a certain point, it'll automatically hide itself. And the window kind of refactors and reflows. And then as you expand it back and forth, you see it's really elegant interaction. And so, instead of like remaking that in every instance of itself, how can you like redesign that interaction pattern? And how do you learn from like the easing curve of something?

说得好。你怎么知道他们用了哪些断点？我们都有这些最佳实践，但我觉得所有优秀的人、优秀的设计师，都是把这些常识性建议经过自己极致品味的过滤，然后输出到世界上，深入细节，理解某个动画的关键帧。这对我来说仍然很有价值。我真的很喜欢这一点。重现交互——你在任何领域都需要视觉设计基础，但重现交互是最好的练习方式之一。你刚才说的也让我想起，我开始更多关注的是：最好的产品在哪些地方没有使用任何交互？哪些地方用了瞬间过渡？尤其是你提到的那个心智模型——我在做这些小粒度的 PR，你也是。我基本上负责所有 P3 级别的 bug。当你盯着一个 P3 bug 时，很容易把它做到完美无瑕——每个小细节都调得恰到好处，动效也美极了。但当你拉远视角，就会发现界面的每一部分都过度设计了，因为我一直在孤立地看东西，现在我可以控制所有交互细节。Linear 在哪些地方展示了瞬间过渡？因为钟摆几乎摆向了另一个极端。我自己能感觉到，相信听众也有同感。

That's good. How do you know like what are the break points that they're using? We have like best practices for all this stuff, but I think all the great people, all the great designers are taking like this common knowledge advice and passing it through their filter of ultra taste and like putting something out into the world and like getting into the nitty-gritty and understanding like the keyframes of a certain animation. It still is worthwhile to me. I know, I like that a lot, actually. Like recreating interactions. You need the visual design foundation in all worlds, but recreating interactions is one of the best ways to practice. And even as you're talking, it's reminding me like something that I've started paying attention to more is where are the best products not using any interactions? Where are instant transitions applied? Because especially, you know, your mental model where you're talking about, you know, I'm working on these bite-sized PRs, which is you very much so for me, too. Like I basically own every P3 bug, right? It's like when you're just staring at a single P3 bug, it's really easy to just make that thing immaculate, man. Every little detail is so dialed in and perfect and moves and it's gorgeous. But then you you run the risk of zooming out and you realize like every single piece of the interface is overcooked because I've been looking at things in isolation and now I can control all of those interaction details. So I'm That's right. Yeah. Where does linear exhibit? Where do they do just instant transitions? Because the pendulum swung almost too far in the opposite direction. I can feel that for myself, you know, I'm sure people listening feel that as well.

还有一件事，当我做作品集评审时，如果是年轻设计师，现在找工作比以往更难，所以你必须脱颖而出。我看到很多作品集，心想：天哪，你做了这么多——这里有个动画，那个按钮有特效，还有一整节讲这个。但归根结底，脱颖而出的最好方式是展示你最好的作品，让它自己说话。为了装饰而装饰，没人想要，对吧？我不需要看你度假时的互动版照片。就给我看你上周做了什么。微动效和动画本身，用十个字就能说清楚“很酷”，但你可以开一门课来教，甚至有人写了书。但我认为默认做法应该是：这个东西在没有装饰、统一字号、没有动画时是什么样子？然后在此基础上说：好，我可以在哪里加一点令人愉悦的点缀？它如何帮助用户，而不是干扰用户正在做的事情？

That's another thing like when I'm looking at or doing like a portfolio review and it's a young designer and it's like it's harder than ever to get a design job these days. And so you've got to stand out. And I see so many portfolios where I'm like, holy like you did so much here. Like you've got an animation here and this button does that and you've got a whole section on this. And at the end of the day, the best way to stand out is to show your best work. And to show your best work, like let it speak for itself. The decoration for decoration's sake, no one wants that, right? Like I don't need to see an interactive version photo of you on vacation or something like that. Like just show me what you made last week. And micro animations and animations in general like they're cool 10 words. And like you could teach a whole class. Right, there's books written on them. But I think the default is like, what does this thing look like with no decoration? With the same size typeface, with no animations. Take that and say, okay, where can I add a little flourish of delight here? And how does that help the user instead of detract away from what they're trying to do with this thing?

我知道你有一门课程，涵盖了这些内容——从工具视角，到训练视觉眼光、反复练习以及整个过程中的方方面面。在最后几个问题之前，我很好奇你能不能多分享一些，给那些想深入学习的听众：这门课适合谁？他们能从中得到什么？

I know you have a course where you're thinking about a lot of these things, everything from like the tooling perspective, but also training this visual eye and all of the reps and everything that's put into and everything that goes into that process. So before I get to the final couple questions, I'm curious if you could just share a little bit more for people who do want to go deeper. Just who's it's for, what they can expect to get out of it, that kind of thing.

这门课叫 Craft at Speed。核心思想是：虽然成为顶尖设计师没有捷径，但作为设计师、产品经理、工程师或想进入科技行业的人，你可以学到一些高杠杆的东西——它们能训练你的眼光，让你把视觉水平从 40% 瞬间提升到 80%。比如思考排版、构图等不同方面。实际上，我认为存在一些客观的优秀设计原则。我试图把多年来积累的知识都融入到这门课里。而学习这些东西最好的方式就是动手做。所以，与其教大家如何使用 Claude Code，不如直接展示我日常的工作流程。这门课是双管齐下的：培养视觉理解并付诸实践，然后运用这些技能真正创造出一个作品。课程结束时，你会拥有一个新的作品集网站，或者一个你想推送到生产环境的功能。我们可以一起打磨它，讨论那些细小的 PR 等等。整个目标就是打下当今设计师所需的基础，能够用前沿工具交付高工艺、有品位的作品。我会提供大量反馈，我们以班级形式进行，我会主持评审会。我觉得很多非设计师会觉得评审很吓人，对吧？

So the course is called Craft at Speed, right? And the whole thing is about like even though there are no shortcuts to becoming a really really strong designer, there are some really high leverage things that you can learn as a designer or PM or an engineer or someone trying to get into tech. There are really high leverage things that you can learn that can train your eye and instantly make something that's like, you know, let's say a 40% on the visual scale to a 80%, right? Just thinking about typography and composition and all these different things. And it's like, there's actually some what I think are objective principles of good design. And I'm trying to just like share the knowledge that I've I've I've gained over the years into that course. And then, when it comes to like learning about these things, the best way to learn them deeply is to actually do them. So, rather than like teach everyone how to use Claude Code, it's like I just show what does my workflow look like on a day-to-day basis. It's like a two-pronged course developing a visual understanding and being able to put that into practice, and then using all these skills to actually like create an artifact yourself. And you'll leave the class with a new portfolio website or a no a feature that you want to push to production. And you and I can work on that and jam on that a little bit. And we could talk about these itty-bitty PRs and things like that. And the whole goal is to just build up the foundation of what it means to be a designer today. And being able to ship high-craft tasteful things using cutting-edge leading-edge tools, essentially. And then, you know, I'm there to give a lot of feedback. We work as a class and I try to lead critique sessions. I think a lot of folks who aren't designers, critique is really like kind of intimidating, right?

完全同意。

Totally.

所以我想先铺垫一下：作为设计师，最能让我们受益的事情之一就是像爵士乐队一样工作，对吧？分享你的作品，让别人按自己的方式去理解，同时培养厚脸皮，这样我们就能采纳最好的想法并执行下去，不管它来自哪里。有时候残酷的真相是：‘嘿，这东西还不够好，但你有工具，我们可以帮你达到目标。’所以这门课有点像是一个速成班，教你如何在像 Notion 这样的公司里成为一名没有头衔的设计师。说到转变经历，我想回顾一下上次我们谈话时你说过的话——你说在 Tome 工作让你感觉自己出来后变成了 10 倍设计师。我很好奇，对你个人而言，那次转变是怎么发生的？

So, I just want to set it up where it's like, 'Hey, as designers, one of the things that we can do that's going to benefit us the most is working as a jazz band, right? Sharing our work with people, let people take it a certain way, and developing that thick skin so that we can just take the best idea and run with it, no matter where it comes from. And sometimes the brutal truth is like, 'Hey, this thing isn't really good yet, but you have the tools and we can help you get there.' So, yeah, the course does a little bit of like it's like a crash course on being one of these titleless designers at a company like Notion these days. Speaking of transformation experiences, I want to call back to something that you said to me the last time we talked where you said how uh working at Tome felt like you came out of the other side feeling like a 10x designer. So, I'm curious for your own journey, what was that transformation that happened for you?

Tome 是市场上品味最高的产品。它是一个幻灯片 AI 生成演示工具。就在这些工具开始兴起的时候，它是一家 80 人的公司。我加入时它实际上缩减到了 12 人，我们从演示工具转向了一个完全不同的市场——AI CRM。我们仍然有创始人 Henry 和 Keith，他们是走在最前沿、品味极高的人，正在构建这个新工具。对我来说，我是唯一的产品设计师。我们有一位非常出色的创意总监，叫 Alex Cannon。然后是我、Alex 和联合创始人 Henry Liriani——他之前一直负责 Facebook Messenger，后来创立了 Tome。我们三个人每天在一个房间里待三个小时，讨论我们正在做的工作。这迫使我能够清晰地阐述我做出每个设计决策的原因。我身处一个充满冒名顶替综合征的房间——和这些大牛在一起。我做了个东西，他们问：‘你为什么要这么做？’我说：‘兄弟，它看起来很酷。’Henry 的原话是，这就像‘平面设计戏剧’。你不能为了做而做。所以你必须解释你的工作，深入第一性原理：你为什么用那种方式做那件事？这让我对自己的过程有了元认知。比如，我想让这个东西看起来某种样子。为什么把所有东西都放在卡片里？放开它，直接呈现信息，用空间代替线条。所有这些非常基础的 UI 技巧都能自动让你的作品更好。但归根结底，就是去掉我们叠加在作品上的所有东西。因为很多时候，你和真正优秀的设计师在一起，你会过度设计问题。就像中等智商图表一样，真正优秀的设计师做得更少，对吧？所以，一年里每天三个小时的密集批评。有时我出来后感觉非常好，心想 Henry 今天喜欢我的作品，我要回家喝杯啤酒庆祝。其他时候，可能会变成五个小时，因为我做得太差了，我会想：‘天哪。’然后我在办公室待到午夜，甚至重做东西。所以，拥有这些机会——接受批评反馈——是令人生畏、可怕的，把自己暴露出来是脆弱的。但归根结底，这是作为任何领域的创意人员提升作品水平的最佳方式。

So, Tome was the highest of taste product out there on the market. And it was like a slide deck AI generation presentation tool. Then right when these tools started coming along and it was like an 80-person company. And then when I joined it actually collapsed into like a 12-person company and we pivoted from presentation tools to actually like totally different market of being an AI CRM. And so, we still had our founders Henry and Keith who were like bleeding edge, high taste individuals and we're building this new tool. And so, for me there like I was the only product designer. We had a really really excellent creative director his name's Alex Cannon. And like myself, Alex, and then Henry, one of the co-founders Henry Liriani who his baby was Facebook Messenger forever and then he built Tome. It was just us three in a room every day for three hours talking about the work that we were doing. What that did for me is it forced me to be able to articulate why I made the decisions that I made based when I was creating something. I'm in a room like talk about imposter syndrome. It's like I'm in a room with these heavy hitters. And I make something and they're like, 'Did you choose to do that?' I'm like, 'Bro, it looked really cool.' And they're like, I think Henry's word was it's like graphic design theater. Like, you can't do something for the sake of doing. And so, you have to explain the work and you have to dig into first principles. Like, why did you do that thing the way you did it? And it made me so much more like it gave me a meta awareness of my process. And so, it's like, well, I want this to look a certain way. Why are you putting everything in a card? Like, uncontain it. Just present the information. Use space instead of lines. All these very basic level UI tricks that automatically make your work better. But at the end of the day, it's just like the taking away of all these things that we layer on top of our work. Because I think a lot of the time it's like you're in a room with really great designers. You want to overdesign the problem. I think it's like the midwit chart of like the really great designers just do less, right? And so, I think just 3 hours a day for a year of just really intense crits. Sometimes I came out of it, I feel so good. I'm like, Henry loved my work today. I'm going to go home and I'm going to have a beer and celebrate. Other days, it'd be like a 5-hour day because I did so bad. I'd be like, 'Oh my god.' And I'm at the office till like midnight or even reworking something. So, having those opportunities like critical feedback is intimidating, scary, putting ourselves out there is vulnerable. But at the end of the day, it is the best possible thing that you can do as a creative in any field, really, to level up your work.

好吧，也许作为最后一个问题，我想多了解一点你在 Notion 的经历，因为我觉得你快要满一年了。你开始做 Notion 会议笔记。那里的文化太棒了，对吧？我一直很钦佩那群人、那些设计师，以及多年来他们推出的产品质量。那么，你能回顾一下你到目前为止的旅程，看看在那个环境中，你是如何继续成长和塑造自己作为设计师的吗？

Well, maybe as a parting question, I'd love to learn just a little bit more about your experience at Notion because I think you're coming up kind of getting close to a year now. You started working on Notion meeting notes. And that culture is so incredible, right? I've always looked up to that group of people and the designers and just the quality of product that's come out for years now. So, are you able to reflect on your journey so far and see ways that being in that environment has continued to grow and shape you as a designer?

有句话说：如果你是房间里最聪明的人，那你就进错了房间。我觉得在 Notion，无论我走进哪个房间，我都会想：‘好吧，我进对了房间，因为那个人在这儿，那个人也在。’我就坐在我们的设计工程师 Colby Miss 旁边，Brian Lovin 在两张桌子之外，还有这一排全世界人才密度最高的人。我认为，在日常工作中，你会从别人身上学到一些小习惯。我们的设计师 Kathy 非常擅长与他人合作，我观察她如何随时把别人带入流程。还有 Ken Chen，他是我见过的最好的设计师，他能看着你花了六个月做的东西——你心想：‘啊，它需要完美，但就是不行。’他会看着你说：‘哦，那个地方不对。如果你那样做，整个东西就会好起来。’你会想：‘天哪。’这太棒了。但这一切都始于高层，Notion 的联合创始人 Ivan 和 Simon——Ivan 让我惊叹，因为他不仅是公司里最有品味、最永恒的设计师，还是一位极其优秀的工程师。另一位联合创始人 Simon 则始终走在使用这些工具构建不同事物的最前沿。我第一次来这里面试时没拿到工作。第二次面试时，我心想：‘我要确保他们不会后悔这个决定。’所以我努力把每天学到的一切都融入我的工作流程。这是一个很棒的地方，因为我们总有新东西要构建，而且我们有这么多客户以各种方式使用我们的产品，可能性是无限的。正因如此，这是我工作过的最模糊的地方。我们的工作范围非常广泛，这太棒了。每天做困难的事情，晚上回家时很累，你会想：‘天哪，我明天怎么再来一遍？’但工作如此有趣和好玩，以至于你总是会回来，不断地咀嚼它。

The saying like if you're the smartest person in the room, you're in the wrong room. And I feel like any room I go to in Notion, I'm like, 'Okay, I'm in the right room because that person's here and that person's here.' And I sit right next to one of our design engineers, Colby Miss, and then I got Brian Lovin, you know, two desks away, and then I got all these like just the most talent dense row over here in the world. And I think that just on a day-to-day basis, the small habits you pick up from other people. Kathy, our designer, is so so good at collaborating with other people, and I watch her and how she brings other people into the process at all times. And then like Ken Chen, he's the best designer I've ever met who can look at something that you've been working on for 6 months. You're like, 'Ah, it's needed to be perfect, but it's not working.' He'll look at you and he'll be like, 'Oh, well, that one thing is off. If you do that, the whole thing's going to be good.' You're like, 'Oh my god.' And it's just so nice, but it all starts at the top and Notion and Ivan and Simon, our co-founders, are like Ivan, he freaks me out because not only is he the most tasteful timeless designer at the company, he's also extremely an extremely good engineer. And Simon, our other co-founder, is constantly on the bleeding edge of using these tools to build different things and things like that. So, I came in here like the first time I interviewed here, I didn't get the job. And so the second time I interviewed, I was like, 'I'm going to make sure they don't regret this decision, right?' And so I just try to take everything that I'm learning day-to-day, put it into my workflow. It's such a wonderful place to be because there's always some new thing we're going to build, and we have so many customers that use our product in so many different ways that the possibilities are endless. It's the most ambiguous place I've ever worked because of that. We have such broad range of work, and it's just a blast. And doing something hard every day, you go home at night and you're tired, and you're like, 'Oh my god, how am I going to do this again tomorrow?' But the work is so interesting and fun that you just keep coming back and you just keep chewing on it more and more.

好吧，我很感激你今天抽出时间来，让我们一窥这个工作流程。

Well, I'm grateful that you took the time to come on today and give us a little glimpse into this workflow.

很明显，你对这些问题思考得很深，也很在意。我们现在这个时代，即兴发挥和实验非常有帮助，但能有这样的时刻互相交流心得也很棒。比如，你在做什么？什么方法有效？你懂的。所以，真的很感谢你今天带着你的笔记来和我们分享，和你聊天很开心。

It's very clear that you think deeply about this stuff, that you care about it, and so it's just... Man, we're in a time right now where it's so helpful to riff and experiment, but then have these moments where we can just kind of like share notes. Hey, what are you doing? What's working? What's, you know? So I really appreciate you kind of bringing your notepad today with us, and it's great hanging in.

谢谢你，Red。这太棒了。我会继续从你这里偷学点子的，所以请继续分享吧。

Thank you. Thank you, Red. This is amazing. I'm going to keep stealing ideas from you, so keep them coming.