Lenny's Podcast: Product | Career | Growth
00:20:08 · Jenny Wen, Lenny Rachitsky
[00:20:08] S0: Yeah, Figmates, yeah. [00:20:17] S1: Yeah. Yeah. Okay. So I know there's this big debate on Twitter, just like, is code the future of design? Do we need many more, do we need a design? What's your sense? Figma's still important?
00:20:27 · Jenny Wen
[00:20:27] S0: I mean, as a former Figmate, maybe I'm biased in that way, but I think there is still ... When I use Figma, I'm like, "Yes, this is what I should be using." And it still fills a very good gap for me. I think a lot of that is actually just, one is exploring a lot of different options. I think that's a really important part of the design process, to be able to just think about 8 to 10 different ways to do something. I think the best design happens when you're able to just throw a bunch of ideas at the wall, and curate and push yourself to come up with a bunch of these different directions. Right now, coding, or right now working with some of these coding tools doesn't lend itself super well to that, because it's super linear, you get super invested in one direction and you just iterate with Claude on them, for example. So Figma has been really great at just exploring all these different options, and I think it's still going to exist that way to some extent. And then I think there's really fine visual and interaction details that are also really great to be able to just try out in Figma. Again, it's a lot of different directions, but it's micro directions. It's being able to think about different typography or styles. Having those in a canvas where you can just explore that specifically is still so, so helpful, and is not something that I always want to go directly to code in.
00:21:51 · Lenny Rachitsky, Jenny Wen
[00:21:51] S1: It's interesting you still use an IDE, because in engineering, it's clearly shifting to command lines, agents, IDEs are kind of moving to not be cool anymore. And it makes a lot of sense. You just want to edit some CSS things, some color stuff. And so I could see why not just telling the agent, "Hey, just come on, change this one hex value." Just changing it is so much easier. [00:22:12] S0: Yeah. It's really annoying to be like, "Can you change this to this class?" When you can just go in and change it to a different class. [00:22:18] S1: So it's interesting. I wonder if IDEs now become the useful for designers and PMs, and engineers have moved on? [00:22:24] S0: Yeah, maybe. Yeah. [00:22:27] S1: Okay. So a lot of your time you spend working with engineers, giving feedback, nudging them in the right direction. There's a sense, I feel, of just your advice is let go. Don't feel like you need to be this gatekeeper, but there's this piece of, okay, help them move in a direction that is cohesive and is creating products we're proud of. A lot of designers I think are in this boat right now, just like, "Oh my God, I can't keep up with all these engineers shipping stuff all day." What's something you learned about just either how to help your engineers get better at design so that it just ends up being better, or just keeping on top of this and not going crazy?
00:23:04 · Jenny Wen, Lenny Rachitsky
[00:23:04] S0: Whenever I do work with engineers on projects, and it's more on a consulting basis, I do just try to explain why I'm thinking a way that I'm thinking, to help them extract principles. As opposed to me just being like, "No, I don't think this should go here." It's like, "No, I think we should have a button here because not everybody realizes you can prompt this." And here's an example where it comes from research and whatnot. So I also just try to point engineers to our design system and stuff like that in code, because right now Claude is writing a lot of the code and it's not always picking up stuff in the design system and whatnot. So as much as I can equip them with stuff that they can use in the future without me, if that's helpful. And then on your point of trying not to go crazy, I think it's hard. I think it's really hard right now. And I see this a lot from actually both engineers and designers, where it's like now that we're sort of capable of doing so much, we want to do more. And so I think it's not just designers who are feeling like, oh yeah, we have to keep up with engineers. I think even engineers are like, "How do we keep up with ourselves right now?" So that's something I'm hearing a lot. [00:24:13] S1: So true. Oh man, how to keep up with all our agents, our seven agents we're constantly running? [00:24:13] S0: Yeah.
00:24:13 · Jenny Wen, Lenny Rachitsky
[00:24:13] S0: Yeah. [00:24:18] S1: Okay. So then as a designer where in this profession, craft and great experience and quality and trust are such a core part of the job, to help instill that in the products, because that in theory leads to really successful products in companies, how do you just think about maintaining craft quality, trust, as your products are just shipping 1,000 times a day, and you're not able to stay on top of them and there's no designer involved?
00:24:46 · Jenny Wen
[00:24:46] S0: It's not that there's no designer involved. It's more just like it's almost that there's too much for one designer to handle. But I think with this, I think about where the features or products are, where they are in the cycle of adoption versus early preview. So for example, we sometimes will launch things and we will say, "Hey, this is a research preview. It's early. It's going to have a bunch of these flaws," and we caveat that a bunch. I think Claude Cowork is actually a good example of this, where we labeled it a research preview and we put it out there knowing that, "Hey, this is similar to our models. This is the worst it's ever going to be, but we're going to put it out there because we believe, internally we've tried it a bunch, and there's something really powerful here that some people will benefit from. It might not yet be the easiest to work with. It might not be the highest quality. It might have some issues with it, but we're going to put it out there because we believe the benefits outweigh the cons." I think that is okay to do, especially when there is something really valuable with the product already, and it's worth putting it out there. But I think the promise you sort of have to make your users is like, "Hey, we're going to put it out there, but we're going to iterate. We're going to take your feedback and we're going to iterate and we're going to make it better." And you have to commit that. You have to show that to the world, you have to respond to people's feedback, and you have to show that you are continuously shipping and improving it. Because I think the way that you really lose trust around quality and releasing something early, is if you release it early and then nothing ever happens. That is something that degrades a brand. But whenever you put something out early, it's possible to do that and maintain the brand of your company. And I think that's something that we've been doing pretty well. And I think anyone who's listening can take away from it, it's like, yeah, well, we're continuing to do that. And I think that is actually really fun for me as a designer, because you put something out there and you actually learn and you get feedback about it immediately, and you know what to do next.