Jenny Wen (Design Lead, Anthropic) – Craft is Counter-Intuitive
In this keynote, Jenny Wen, Design Lead at Anthropic and former design leader at Figma and Dropbox, argues that the prevailing design paradigm—heavy on strategy, data, and low‑fidelity processes—has become a barrier to creating truly crafted digital experiences. She traces the historical shift from craft‑heavy graphic design to strategy‑driven product design, noting how design thinking, design systems, and data‑centric decision‑making have unintentionally flattened the artistry of software. Wen highlights how AI tools now enable rapid generation of UI elements, but also how a renewed appreciation for craft is emerging in products like Not Boring Software’s habit tracker, Stripe’s Black Friday counter, Linear, and Notion’s calendar. She proposes that the industry must rebalance toward craft, even if that feels counter‑intuitive. To illustrate, she deconstructs five “old rules” (fall in love with problems, start lo‑fi then hi‑fi, measure twice cut once, back everything with data, stay out of the work) and replaces each with a “new rule” that emphasizes flirting with novel solutions, early high‑fidelity exploration, biasing toward building and iterating, trusting intuition built from experience, and hands‑on leadership. Real‑world examples include FigJam’s AI‑driven summarization feature, Claude’s “artifacts” that emerged from a developer’s personal frustration, and FigJam’s CursorChat built through rapid hack‑and‑feedback cycles. Throughout, Wen stresses that intuition, rapid prototyping, and leadership involvement are essential to achieve high‑quality, joyful products in the AI‑augmented era. She concludes with a call to action for designers and leaders to embrace discomfort, adapt their processes, and champion craft as a differentiator.
Chapters
Also, hi. My name is Jenny Wen. I'm normally based in Brooklyn, New York, but it actually feels really good for me to be here right now because I'm sort of in my hood. I grew up mostly in Burlington, Ontario, not too far away from here. Yeah, Burlington. Nobody ever. But I actually went to the University of Waterloo also, where I studied urban planning and systems design engineering. Work-wise, I'm currently design lead at Anthropic, and I work on the core of our Claude.ai product, which is the consumer-facing chatbot that's built on top of the Claude foundational models. And I've actually just joined a few weeks ago, so it's actually really exciting for me to be here and represent Anthropic for the first time. Before that, I was at Figma for 5 and a half years where I was Director of Design, and I led a handful of teams that represented our new products and our growth team. So things like FigJam, like Figma Slides, which I'm using right now, Community, and a few of our top secret products as well. And as a designer, I also led the design of FigJam, where I brought it to market as Figma's second product. And it's a whiteboard tool that teams love to use if you haven't used it before. Before that, I was also at Dropbox for a few years where I worked on Dropbox Paper, which was this really well-crafted document editor. It was, I think, one of the first document editors to really break the norms of, you know, the Google Docs type of like editing interactions. Okay, so I was telling you everything we know about design is wrong. Let's first talk about how we got here and why I think they're wrong and why it's very important to acknowledge that right now in this moment. So for simplicity, let's think about our jobs as like these 2 parts. Obviously there's like a lot of other things, but just for simplicity, like let's think about it as strategy— actually strategy's this way— and craft. So strategy is the thinking about our users, the problems, doing research, analyzing that, and just carefully plotting our work so it makes sense. But then there's also the craft element, which there are also lots of definitions of design, of craft that we could talk about. But let's think about this as all the stuff that goes into like the actual solution, the visual design, the interaction design, the parts that you feel, the parts that you see, all the ex— that executional work that goes into building something. So around the time, you know, in the 2000s, I actually think that the balances were tipped this way where design was actually very craft heavy. You know, designers mostly came from a background of graphic design and they were mostly known as like web designers and people who would sort of skin a website. We would get handed product requirements and we would just like make things look really nice. But at this point, software was getting more complex. You know, it wasn't just a website. You could actually like order a taxi from your phone. And design wanted to get a seat at the table. We wanted to be known as more than just aesthetics and not just spend hours and hours making a skeuomorphic button, even though they are beautiful. We wanted to weigh in on decisions that impacted our design and be a part of that thinking. So then there was this explosion, I think, in the idea of design thinking and user-centric design and designers getting MBAs. These are all generally good things, I think, because they considered not just how things looked, but also how they felt, how they worked, how they could affect the day-to-day of people's lives, and how we could impact the business. And I think that's been the prevailing method of design, in software design at least, for the last 10 to 15 years. So we took the skills. But I think over time, we actually maybe tilted too much over to the other side. We focused a lot on like making diagrams and journeys and crafting the perfect problem statements. And I think we actually started to deem the actual outcome, like the thing that you see and feel, less important. So one thing too is like today in portfolios, I see a lot of diagrams, a lot of writing, and then maybe just one screen mockup. And I think that represents where we're at. We got a seat at the table, but we lost a lot of the artistry and the craft of what we do. And then came design systems. You know, we weren't crafting every part of the UI anymore. We were making them modular. And we used them to put together pieces of UI like a puzzle. But I think honestly what that ended up doing is like making design a little boring and predictable. And in a way, we were already automating our jobs ourselves. We were taking away the artistry. We were moving around pieces and fitting them in just sort of like it felt like this. And I think the next step in that automation is already here. AI is really easily able to make things out of design systems. Like, the left is the actual McDonald's app that I took a screenshot of, and the right is one that's generated from an AI tool called Galileo. And it doesn't look exactly the same, but, you know, it's like pretty standard and it doesn't look bad. That's what it is. But I think what's interesting is like, look at what's capturing our attention lately. We are all falling in love with software that just feels good again. And one of my favorite examples to use here is from a company called Not Boring Software, where they took this like really simple idea of a habit tracker and they actually just made it gorgeous and so fun to use. There's Stripe's Black Friday Cyber Monday counter from this past holiday season where they made this physical counter for all the sales they were getting over the weekend. And it literally could have been this boring— oh, it's not animating. Cool. It could have been these boring number set of numbers on a screen, but they actually made something really beautiful out of it. I think it's also permeating the software that we use at work. So for example, there's a tool called Linear, which, you know, there are a million task trackers out there and not anybody would say, you know, they really love any of them, but they made one that's really well crafted and people really like using it. And Notion also purchased Cron, the startup earlier this year, so they could launch Notion Calendar together. Again, endless calendar apps out there, but they're really striving to make one that people love. And every day on Twitter, I'm also seeing fun demos of software that's more joyful, more interesting, and more novel to use. And most of the time, designers are able to build it given how easy it is to build with AI tools. And fun fact is actually both of these designers that made this stuff, they are both from Toronto. So there's— it's really great to see that there's great work coming out of here. Yes. Woo. And I think what's finally happening is that people, especially people who've spent their entire lives on the internet and are increasingly in digital spaces, We are finally appreciating and understanding the value of craft and quality in digital products. I think it's the same way we know the difference between sitting on a plastic lawn chair versus sitting in a cushy Eames chair. It's the difference between wearing a polyester sweater that pills or a cashmere sweater that's soft and lasts you your entire lifetime. Or eating a frozen pasta dinner versus one that's like freshly made with all the right ingredients. And I'm not here to like disrespect frozen dinners, polyester sweaters, or plastic lawn chairs. We are not above that. There is a time and place for all things, but I think what I'm saying is that there is value in well-crafted things, and we know the difference. People seek them, and they will pay for them. So, what I'm saying, I think, is people are realizing the same thing for software as they are physical things. Craft is a differentiator now. And it's time for us as an industry, from being so strategy-focused, to tip the scales again and to rebalance them. To make our jobs as much strategy as they are craft. Because craft is a differentiator. Things are different from a few years ago. And this was a time when our jobs were shaped from that era. But what we're increasingly asked to do and produce in the environment that we're doing them in is increasingly different. So that means we need to work differently too. So craft is actually going to feel counterintuitive. And producing these great craft outcomes is going to be different from what we learned and what we know. It's gonna be uncomfortable. So here's what we are gonna do. We are gonna take a bunch of the rules that we learned about the design process and we're gonna call them the old rules and we're gonna break them one by one and come up with some new rules. We are not gonna have enough time for me to tell you exactly about how to instate all these things in, in your companies because it's gonna be hard. But what I do hope I leave you with is that a feeling that it is time for us as designers and especially design leaders to to embrace change. This is a call to action for everybody to adjust and thrive in this new era. So here we go. First old rule. There's the adage, actually, I heard this earlier this morning, which is fall in love with problems, not solutions. So what that tends to look like right now is, you know, you start with a problem, you understand the user, you define it, you write the problem statements, and only then do you come up with brainstorming solutions. And I think sometimes we'd intuitively have a solution pop up outside of this. Process and we'd be like, no, we can't skip steps. If it's not solving this problem, we cannot do it. But what I've seen is that sometimes the most compelling solutions actually don't come this way. The most novel stuff, the most interesting stuff, it comes from an instinct or an exploration that someone does. And I think a good example of this is actually with AI, which I bet more and more of you are designing for AI. We have this new technology. It is a solution and it is pretty drastically different than anything we've ever seen before. We know what it's sort of good at, but at the same time, we've— it's new. So we have all these problems that our product has been trying to solve in the past before. And we basically have to look at these problems again and work backwards. We have to ask ourselves, like, what problems could this technology or the solution solve? And I hear people say sometimes, like, AI is a technology in search of a problem. You know, like it's a dirty thing or something. And yeah, I mean, it sort of is. a technology in search of a problem. It is. But you also can't deny that it does solve some problems in a much better way than we had in the past. So one example of this is with FigJam, we built some features that we launched in 2023 where basically after a brainstorm, you have all this messy stuff on canvas and you select it and you click summarize and we print you out this really beautiful summary on the right. When we saw the latest AI models in 2023 being really powerful, We thought about how they might change our products. And the first thing we did was brainstorm, like, what is AI good at? You know, it's good at summarizing a lot of text. It's good at generating ideas. It's good at helping with writing. But the big one we saw was like, it's really good at summarizing a lot of text. And so from there, we actually worked backwards and we thought, what problems do our users have that this could solve? And here, the big one here was, you know, it's too much work to synthesize brainstorms in FigJam. And from there, we developed our summarization feature. We did not follow the rules of going problem first, but we still landed on a really compelling solution, I think, that solved the Shark problem. And another one that predates me from Anthropic, and I hope this video will play, but maybe it will not. Okay, that's fine. No worries. Another example is of the artifacts launch that we did, where instead of a chat reply, artifacts are basically these things that Claude can make for you, like a document or graphs or a website or even an app right beside your chat. And this one did not come through a defined problem-to-solution process. Honestly, one of the most— one of the passionate engineers on the team was just like, hey, like, I was tired of copying code over from Claude into my code editor, so I just wanted to put it right beside Claude. So he just built this simple split-screen prototype. This is it. And one of the designers on the team named Michael, he loved this so much that he actually iterated on it, built it, and like created his own product prototype. And all the reactions from the team, including the CEO, were just like really positive. But this didn't come from a problem statement. And in fact, it probably wouldn't have come out of a problem statement. Like, we didn't realize this was a problem until we actually saw the solution. And overall, it was a really successful launch because Claude was actually the first AI tool to actually have this interaction. And it fundamentally changed the way people thought about AI and what it was capable of. We really just did not know this was a problem until we saw the solution. So the old rule here was to fall in love with problems, not solutions. But I think the new rule is to flirt with novel solutions. I'm not saying every design process needs to come solution first, like that's probably not going to work. But sometimes the best solutions, especially ones with new technology, they can come solution first. I think if there's a feeling there that gives you butterflies, you should listen to that feeling. So the second old rule is to start lo-fi and then go hi-fi. You know the process, you know, you start with something like this, it's super sketchy, it's maybe pencil and paper. And then you make it less sketchy, you add a few more details. And then you maybe bring it to digital, there's a little bit more detail. And then finally there's that layer of color and then it's a real thing, right? Like it totally makes sense. But I think this approach has been treating the visual details in Hive Deli work like it's a coat of paint, like this layer that you put on top. But maybe the right analogy here actually is decorating a cake. You know, like sure it's the last thing you see, it's the finishing touches, But it's a careful orchestration. You know, like as you're figuring out what flavor the cake is, you're also deciding what's going to go on top. And you're deciding these things, 2 things in parallel, because one really depends on the other. And we also got to this weird point where we really felt like as an industry we needed to split the difference between UI and UX. Like truly, if you ever want to be enlightened, just go onto LinkedIn and search UI versus UX. You will get ketchup bottles, sidewalks, left brain versus right brain. All this stuff. But what I think I'm trying to get at is who cares? Like, who cares what our users cannot tell the difference between UI versus UX? They just feel what they feel and it either works or doesn't. So the reframe here that I will give you is that in terms of creating well-crafted products, the interface is the experience. You need to develop both and think about it early on and not as an afterthought. Every craft-centric team I've been on starts with high fidelity and not just wireframes. These are some of the first second-round mocks from teams that I've been on and led. And here the idea is not 100% fleshed out, but we are trying to make them feel really real so we can assess if they make sense or not. And I think this can be very hard. Like a lot of designers can feel like it's a lot of work to just have really nice visuals from the get-go. But the reality is this is a trained skill. And I think it's important for us to train our teams to do this, but also look for the skill more. So an example I'll give you is the toolbar at the bottom of FigJam. It's one of its defining features. It's skeuomorphic, and I think it's really different from other whiteboard tools out there. Like, you'll take a screenshot and you'll know that's FigJam. And it came by when actually one of the designers was like, what if it was skeuomorphic? And the starting point was literally this high-fidelity prototype. It's not playing, but you can pretend. And we saw this internally and we were like, wow, that's so joyful. And like, It's so different, so let's do it. And maybe he could have started lo-fi, like he could have started here and it would maybe help us debate like the placement of certain things, but seeing something like this, there's actually like nothing really to react to. Not the same way seeing this does. The visual design here, it is the concept, and without doing this right away, we wouldn't have bought into it. But just because it was high fidelity doesn't mean that it was the final visuals. We ended up doing multiple, multiple iterations to refine the visual design, like These all were part of that, where the visuals are actually drastically different in each, but the core concept is actually still there in all of these. You know, the skeuomorphic tools, the feeling of tactility, the joy, it's all there. And here's where we landed again. We could not have done this without exploring the visual design really early in the process. So the old rule here was to start lo-fi, then hi-fi, UX, then UI. But I actually think the new rule is that it's advantageous to start thinking about the UI even early on in the design process. And to build that muscle on your teams where they're able to come up with great visuals really quickly. So the third rule I have in this old world is to measure twice, cut once. And I think this is an engineering saying. Like, I heard this a lot in engineering school where it means being super sure around building something before actually building it. So today the process looks like this for most teams. You know, you have a few directions, you actually decide to do research. That way you can decide which direction to go ahead with. Maybe you do research multiple times because you want to be extra sure. And then only after being super, super sure do you actually like put pen to paper and build it. But what I've seen actually be really helpful for high-quality outcomes is, you know, you have a few directions at the very beginning. You actually choose one of those to build or maybe multiple, the ones that you're feeling the most convicted about. And then from there, using something that's real and live, you learn. You learn either from people externally or internally or just even amongst yourselves to feel it out. And then you go back and you reassess directions or refine them. You learn again, you do that again, and maybe you do it again and again. And only then do you actually ship it. But, but you do this because you can only get so much with actual mockups. You need to sort of start to feel something real. So what creates well-crafted products is building something real to iterate and refine, even if it means building it multiple times and throwing it away. It means it's important to feel it out. So one example where we did this was— oh, it's okay, it's working. Yay. One example where we did this was we developed cursor chat, which is this really fun feature in FigJam where you can type messages in your cursor and they'll follow you around and follow you around on the canvas. So similar to a bunch of the other projects I showed you, it started with a few really high fidelity prototypes where I made these and they look super high fidelity, but there were so many interactions still left to figure out. And again, hi-fi prototypes made us excited about the concept, but they only took us so far. So at this point, like literally just based on that, I handed off this 4-screen spec of what I thought the design should be. And there's still a lot of uncertainty here to figure out. This is what I call like a 70% complete solution where you have to build it, feel it out to figure out the rest of the 30%. And from there, the 2 engineers that I worked with, we built hacky versions of CursorChat in our actual product that we were using internally. And we would literally just pop into people's meetings at work and be like, hey, use this feature, give us some feedback. And based on that, we would build new versions of the feature basically almost every day. And here's where we got again. We could not have gotten here with just, you know, prototypes built in Figma and research. We needed to build, throw away what we built a bunch of times, feel it out. And at the end of the day, it was not throwaway. It was actually moving us forward and helping us iterate to the best outcome. So the old rule here is to measure twice, cut once. But the new rule, I think, is to bias towards building, even if it means building something multiple times. I think getting to feel that real thing will get you to a higher crafted outcome than trying to be super, super sure before you build. That's how you get something that feels good. Okay, next old rule is to back everything up with data, you know, data-driven, data-informed. And I'm not just talking about metrics, like the quantitative stuff, but also user research. So today I think intuition feels like a dirty word. Like if you make a decision based on intuition, You're irrational. The decision isn't valid. Like, that's sort of dumb. And I told you actually craft is counterintuitive, but maybe what's counterintuitive now is that in order to make something well-crafted, you have to lean into your intuition. There truly is not a single good way to measure quality or craft. If not, we would have solved it by now. But intuition is built by taste and experiences, and it's something that we do and we pick up after using and building products for many years. We hone it. And so intuition is not irrational. It's built on data and experience that we have as designers, and we should be constantly building that intuition with more data and more experience. So we launched FigJam in 2021, and it was actually a really positive launch. You know, people were really excited to try it out. It was Figma's second product. We got lots of positive feedback, but we also got lots of feedback like this where they were asking us for features like a timer or team templates or more sticky colors. But what we were not getting feedback about was, you know, like, can you make the product higher quality? Can you make this one interaction slightly better? This interaction is just a little sticky and weird. We didn't hear that. But we were a group of experienced product builders and we knew the product wasn't there yet, even though we launched. And I think if there was some magical way to measure quality like this graph, it might look like this where there is some threshold that you have that's like, When you think people will know it's high quality, and we just had this sense, this intuition that we were just not there yet. But we had to keep inching away at it. So quality is not a thing you're gonna get direct feedback about, and it's not necessarily something you're gonna write. You're gonna be able to write a user story about. You have to feel it. So a lot of the work that we did after the launch was small tweaks that aren't flashy, but quality tweaks. You know, we tweaked object snapping to make things snap better. We tweaked the border visuals so they would be less noisy. We tweaked the color palettes because they were feeling too dark at one point. We adjusted the font sizes to make them look better next to each other. We added image borders so the white images would stand out better on a white background. We tweaked shape sizing so it would be smoother. But— and there's just like so much more stuff that we did that I could fill literally an entire presentation of slides with. But again, these were not things that our users were telling us directly. They were things that we intuitively knew did not feel good enough. And you could not measure it, like experiment and say, you know, this one thing raises metric by 5% or whatever. But over time, the culmination of these small things were created this like emergence of quality that you could actually start to see people using the tool more smoothly. So the old rule here was to back everything up with data. But the new rule, I think, is to use that intuition to hone quality. And it's up to us to build that intuition. Okay, so my last old rule is to stay out of the work. I have interviewed a lot of design leaders through hiring on my own team, and I frequently hear this from them and from really seasoned leaders. I leave craft to my team. Or I hear people say, you know, I'm not a micromanager. I don't get in the details because I'm a good manager. And then I hear this too, like, you know, I empower my team by staying high level, that somehow, you know, getting into the details is actually disempowering. But then at the same time, I'm talking to other design leaders who are at craft-centric companies looking to hire leaders. And more and more are saying the exact opposite. They want leaders to be not just people leaders and create great environments. They want to know that people are hands-on, that they can drive great craft outcomes, that they can get in the details and talk to their teams and push them to better craft outcomes. And I don't think any of these mean that you are a micromanager or being disempowering. So one thing that I've done with my team is I will pair and direct work with them. So for example, when we were coming up with the Figma slides product icon and colors, There were a lot of opinions, a lot of stakeholders, and the designer had a lot of options and was having a tough time sort of refining and figuring out which one to choose. So I actually sat down with him and we actually just like looked at the, at the options and, and pushed some pixels together to make the final icon. And then I helped defend that decision afterward. Another thing I do is I give really detailed design feedback. I give feedback that's not just about the problem or the strategy, but about things like border radius and hierarchy, because these things matter. And just because I'm not designing stuff all the time, it doesn't mean I don't have opinions or taste on this. And it doesn't mean that I can't make designers work better. I also do something that we call riffing, where it's basically just taking a version of the design and making something else your own and come up with another option. I'll hop into files with designers and I just make sure that I— they don't feel like I'm redoing their work. I'd still leave the decision up to them, and I do this frequently enough where they know to expect it and they don't need to choose my option. I also do a bunch of concepting too to help drive a direction and get the teams to be more ambitious. When I'm managing, I'm actually rarely designing, but sometimes the best option is for me to be in the weeds and to design something and throw it in, and I won't hold back. I'm doing all this from a place of trust, of still leaving, you know, the decision-making up to the designer and to make them feel like I'm helping them as a teammate to a better outcome versus needing to assert my opinion over theirs. So the old rule here was to stay out of the work. But I think great craft means getting hands-on. It means if your team is already really great at craft or already really senior, that you believe that you can elevate them and make them even better at it. I think that's the most empowering thing you can give your team. And to do that, you need to be comfortable talking about and poking at the details. So that was our last rule to break. So just to recap, instead of falling in love with the problem only, it's okay to flirt with novel solutions. And instead of starting lo-fi and then only gradually getting to hi-fi, I think it's important to evolve the visuals early on. Break that norm of high five being only at the end. And instead of measuring twice, cutting once, and being super sure before you build anything, I think it's important to bias towards building something you're pretty sure about and use that building as a way of trying things out and refining them. And instead of backing every project up and every decision with data, when it comes to quality, we need to start using intuition and leaning into that because that's the only way we can sense it. And finally, as leaders, we were told to stay out of the work and stay high level. But to drive a team that's great at craft, we need to get hands-on. So there are the old rules, and here are the new rules. I'll pause for a second. I know I'm about to see everyone's pulling out their phones. Okay, so I told you at the beginning of this talk that everything we know about design is wrong. But I think maybe, you know, reflecting on the rules, maybe not everything we know is wrong, just some things. But there's some things that might actually be fundamental about the way you work. But at the base of it, I do think a lot of the skills we know and have, they're still there. We're just flexing them in very different ways. So that might still feel really uncomfortable to you, but things are different because craft is a differentiator. And building high craft products is gonna feel counterintuitive. But I do think we need to change. The industry is fundamentally changing underneath our feet. And there have obviously been a ton of layoffs in recent years, but also especially in leadership positions. There's been this big shift towards flattening or just— or managers being asked to be ICs or be more hands-on. And maybe you've actually already been affected by this. So the type of leadership we need is different. What our tools are capable of is more and more powerful. And the tools that people love and crave, they're different, both in their personal lives And at work. But I want to leave you on a hopeful note. I believe in us. I believe in us to make the transition into the next era. We're creative people inherently. We've adapted before from strategy— from craft to strategy to get a seat at the table. And I think this discomfort that we're all feeling, it's good. That's when we grow and change the most. I believe in us, and I can't wait to see what you all make. Thank you.
More from jenny
The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)
