Jenny Wen - Design Lead at Anthropic

I'm John, I'm a designer in New York City. And I'm Chase, also a designer in New York City. And this is Double Diamond, where we talk product, design, and the future with the best and brightest minds shaping the future of software. Introducing our guest for the night, Jenny Nguyen. Jenny's career has centered on building collaboration tools that feel both powerful and deeply human. From her early work on Dropbox Paper to bringing FigJam from concept to launch, and later leading teams across products like Slides and Community as a Director of Design at Figma, today she's a design lead at Anthropic, where she helped shape Claude's chat experience. Now she leads design for ClaudeCowork, building a new interface for enterprise intelligence and in the process, redefining knowledge work and how teams think, create, and operate alongside AI. Double Diamond is sponsored by 28th and Park and Bamboo X. 28th and Park is our production company that makes all of our lovely content. If you have any content related needs in New York City, definitely check out 28th and Park. They've been a fantastic production partner to us. And we also always have to thank Bamboo X for our lovely space, our lovely set. They host fantastic events here and do amazing work in the design community. There are maybe a few dozen people in the world right now whose design decisions are going to define the relationship between people and intelligence at a mass scale. We believe you're one of them, and you're doing this work hands-on as an IC. You are in the details every day, making calls about how Claude communicates, how Claude presents itself, and earns the trust of millions of users over hundreds of millions of interactions. So I want to start there. As someone who's had a front seat to designing one of the most highly used intelligence services in the world, what have you learned about designing an intelligence product at that level? Yeah, I mean, it's a big question. It's a big ask. A lot. I think there's a lot that is really different probably from the way that we designed products in the past where we really just thought about, hey, there's this like really deterministic flow. You know, you either, you look at the screen and you pick option A or you pick option B or option C, and then there's just, there's a lot of states. But you know, if you think about a banking app or any sort of a health app or any, basically any app that you would have designed in the 10 years prior, you can lay out all the states through different flows, through different diagrams with arrows in between. It can be super complex, but all those states are sort of created for you, where I think when you are designing now with these LLMs and with AI, basically, you can't map out all those flows. You basically just have these core primitives and these specific states that you want like the model to get to. But the possibilities in which the user can actually, you know, interact with the model are just basically endless. So that is just like a very different state of working. I actually think it's pretty similar to some of the stuff that we did at Figma in that like every state in Figma, like there are also a million states that you can design for, but they're pretty non-deterministic also. You give people the primitives, you give people, you know, rectangles and auto layout and stuff like that. But ultimately what they create is up to them and that the number of possibilities is pretty limitless and there aren't just like, you know, five different flows that they can hit. So a lot of this is just like kind of designing the variables, but not being able to control necessarily the use cases or the kind of like end states that users can get to. What do you then, what have you learned trying to design those variables since there's not much of a precedent for that? Yeah. I mean, we tend to design with use cases in mind. Like we sort of say, you know, for example, we were designing FigJam, we were like, okay, we want people to create certain kinds of diagrams, like certain org charts or like Venn diagrams, et cetera. We want to make sure those are possible, but we know that what is, what people are actually to create are going to be beyond that. So a lot of it is actually just giving people those tools, making sure they're successful at the use cases you care about, but then also just like seeing what else they make and then taking that and feeding that back to the product and be like, oh yeah, like we thought they were going to make these diagrams, but they actually ended up making, I don't know, like some really fun icebreaker board. Like how do we actually make that use case better too? Because we noticed that a lot of people are using it for that. And I think the same thing goes for like Cloud and Cowork where we have use cases that we care about people being successful at, but at the same time we're discovering new use cases every day and we're taking those and we're evaluating against those as well. So it's like, we're sort of building the product with people as they use it. I'd love to hear more about that. What does the feedback loop looks like as you are designing these experiences? Yeah. So a lot of the feedback loop is literally just like get it in front of people as soon as possible. A lot of that feedback loop happens internally, you know, what will my sort of policy for our team right now is like anything goes when it comes to like dogfooding internally. Like there truly is no standard. We have like the most sort of janky stuff just running internally as long as it sort of doesn't disrupt people's use cases and their workflows because we're using our tools like every day for work. So as long as it's not super disruptive, we put it out to basically all employees and then we just have people use it. And then we sort of shape the actual form of the product and the interaction details as we're learning about how people are using it. And then we put it out and we continue to learn more about those use cases and we evolve the product along with that. In that world, I'm interested in like, when do you decide it's time for a new primitive? When is it, you know, when is it time to like decide, you know, this is going to be an artifact versus this is going to be inline or even what I'm really interested in is like, what sort of is the story of co-work? Why have its own specialized interface just for that product? Why not just do it in the main chat? Yeah. Co-work actually has a decently long history. There is like this external narrative for some reason that we built it in 10 days, which is actually like pretty untrue. It was basically 10 days from the day we decided, hey, we're going to ship this. We basically decided, hey, one day we're going to ship it in 10 days and then we just shipped it in 10 days. But the actual like sort of process and like thinking behind it, like kind of ran on for a long time in that like there were many different prototypes of this product and they ran on like different agent harnesses and like different like tech stacks basically before we sort of landed on the one we did. So I think even like partway through last year, we had basically like built this sort of internal agent harness where Cloud was able to deploy a bunch of the sub agents and start to do, you know, knowledge works like tasks. That actual harness didn't really work out that well in that the sub agents interacting with each other in that harness, it just like got really chaotic where they would interact with each other. And then after a bunch of interactions, they would have this like weird blissful like thing where it seemed like it was like 10 people on mushrooms talking to each other. And it was just like, we were just asking this agent basically to make me this like daily brief and tell me, hey, what meetings do I have to go to today and like prep for me? And then it would work the first day and the second day that it did it, it would be like a little bit weirder. And the fifth day, it would be like talking about world domination or something in like a like it wasn't actually doing anything, but they would it would be like these agents talking to each other and they would it sort of read like if you've ever read like Infinite Jest where there's just a bunch of like really chaotic characters, it's sort of read like that. But anyway, that like there was a prototype of that. But there basically there was this thinking that like, hey, we know agents are becoming more and more powerful. How can they actually help people do their work? And by people, we sort of meant like all knowledge workers because we'd already built products out there for coding and we were really good at that. So we were like, hey, what other sort of industries can we help people have that same like ability that they were getting out of Cloud Code? And then there's like a bunch of other prototypes that both Playability Interaction and different agent harnesses. And then I think near the end of last year, we were seeing this thing where it was like, oh, yeah, people were using Cloud Code for all these like non-code use cases. And that really blew up over the holidays, too. And at that point, we were already building this version of what you know as co-work right now on top of the Cloud Code harness. I think we were just like unsure of the final form and we were iterating on it internally and stuff like that. But given the momentum around like Cloud Code for accountants, for marketers or whatever, we were like, I think this is a moment where we should ship this because it feels like there's already some product market fit and that people are finding this like agent helpful for all these use cases. We just need to ship the UX around it. So that's the thing that happened in 10 days. Yeah. Yeah. But I think with this, there wasn't any sort of like process around, hey, it's time for a new primitive or anything. This sort of creation of this product really existed because this sort of agent harness is so different than like the actual chat that we have. And it's just a different underlying technology. And it's like different from Cloud Code, too, because Cloud Code is so tailored around the code use case. And this use case needed to be good for sort of like general knowledge workers. I think it's really interesting hearing you talk about the like testing with the different agent harnesses and testing different tech stacks. It's very interesting to hear that coming from a design leader. And I think the work your team is doing is really at the forefront of role collapse, which we'll get to later in this discussion. But what you're talking about there sounds like this kind of, it makes me want to ask this question. What is the line you think between what we would call traditionally product design and model behavior? How does how does that work at Anthropic or how does that work in your mind? Yeah, yeah. I mean, in my mind, I think they should be closer, but I don't. Today, they're still pretty separate things. And I think there's also there's a few layers in between between model behavior and actually like product, just product development in general, like like you have the actual model behavior and sort of like training on the research side. But there's also just like the capabilities and sort of what I would call the plumbing on top of that. And a lot of that is driven by engineering because they because they're sort of like the closest to that and able to do that. And then there's like design that sort of comes on the layer above that where we're actually taking those capabilities and that plumbing and actually kind of presenting them to users in a way. And I think these things, I think people who do really well, I think, in this environment are like folks that can sort of span across that and understand that really well, because ultimately a lot of what we're trying to do is like take this technology that is like. Kind of illegible to people and then turn it into things and like use cases that are actually really helpful to folks, so it's like it's a translation, like each sort of layer is a translation of like, you know, the other layers itself. So, yeah, can you expand on what what did you say? Translate across it, I think is the word you use. Maybe, yeah. Across like the different layers, I guess. Yeah. Yeah. Like like what I thought I heard you talking about was like a designer who understands what's what's going on with the models. What is actually like what is the bar at Anthropic for a designer to understand how the models work? Because I'm sure everybody would want it in some sense, like model what you say or really be interested to hear what you say about that. Yeah. I don't know if there's a necessary bar for that in that it feels all of this stuff generally feels. Unknowable, like like it's sort of changing all the time and there's so much going on like at any point in time, there's like a number of models being developed and trained and in different phases of like the overall like creation process. And then there's also just like so many capabilities also being built. And then there's also so many other like product product projects being built. I think I would sort of describe like kind of the components in my mind as I see at work those three things. So there's like there's like different models being created. And I think if you're on the research side, like that's probably the most brutal division of that. And they're they're doing a lot more capable. They're doing a lot more than just creating just the models. And there's a lot of steps in between that. But there's the model layer and then there's a sort of like the capability layer, which is like the sort of engineering plumbing on top of the models. And then there's like the feature and product level type thing. I think, yeah, it's hard. It's really hard to know what's going on all the time across all those layers. But I think. People who can sort of say like, oh, yeah, I understand that the models are heading in this trajectory, and so therefore we should design in this way in that like, you know, three months from now, what we're designing will be obsolete. That's I think that's one skill that's really good to have. A second one is like folks who are very engineering focused and like a lot of them, a lot of these folks are like much more engineering focused than I am. They're they're able to say like, hey, you know, if we think if we are able to implement memory and like this way that unlocks this user capability, those folks, I think, also just have this really special insight. And like when I think about the people on the team, I'm like, I feel like I'm like not even that good at that. But and then I think the last layer of folks are folks who say like, oh, given these features that are these these capabilities, this is how we shape them. So that way people they're actually marketable and then go they can actually be a part of products. I think those are basically the three ways designers can really understand the stack, but also like transform the stack at each step. Those are really important skills. But I think it also really depends on someone being able to like learn, be curious, I think, continuously curious about what's happening with the models, the capabilities, the features, and then being able to, yeah, like sort of transform them into these next layers. Yeah. You mentioned in that list that it's important for designers to understand how models will make their current work obsolete or the trajectory of models will make their current work obsolete. How are those designers or how are you determining what work you have now might be made obsolete by way of a model improvement? I mean, I think there's general trends that we have seen across the models in that. You know, over time, they're just they're capable of performing more and more complex work and more and more long running work, and you're able to just like leave it alone for a longer period of time where it does X, Y and Z without you intervening. I think part of it, too, is just like we we hear from research, we get the snapshots of the models and we hear like, oh, yeah, this one is really good at like it's even better our coding now or whatever, like that, like our latest models and stuff. And so we sort of we sort of start to understand what it is capable of based on those snapshots. And we're also just testing them a bunch. Testing them a bunch And and so we're so we'll do things where we're like, oh, yeah, we actually might not need this. I Don't know like selector or something because in in like we probably shouldn't design for it because you know in a month from now Club will be able to just choose whether it wants like blue or red or something. Yeah. Yeah. Yeah, I'm interested in This is we talked about The models are evolving very rapidly across all the different providers. It's like I feel it's like every different every day There's like a new model or a new tool Part of our job I think as designers is to help educate our users in terms of what the software they're working with is capable Of doing. Yeah, I'm interested in how do you think about? educating the users of co-work With what its capabilities are specifically around the idea of like cloud code is software. It's writing its own software It's in a terminal. So like software engineers are pretty familiar with what it's doing But if you're someone who's a knowledge worker, maybe you're not as familiar with how the models work what they can do Yeah, how do you think about educating those users and like built in the the interface for work itself? Yeah I mean, it's so hard. I don't I don't even know if we've nailed it even uh, I mean We've tried a bunch of stuff which is just like Show people suggestions of what they can do We Think there's like some like we're trying to build we have built like more affordances in the chats and whatnot That sort of suggests to you and point to you Certain like use cases or certain things you should do like, you know, connect your Google Drive, etc Based on your conversation. I don't know if we've like solved it. It's really hard. I think There it's hard because you have Both users that are such power users that they like know exactly what they want to do they're like prompting the shit out of it and they have all these like super long prompts and then And they're sort of just like get all these like suggestions out of the way like I just I know what I want like leave me alone and then you also have people that are on the other spectrum of The AI adoption curve where they're just like, what is this? Like I'm just a type. Hello So I honestly don't think we have nailed that yet. And a lot of what we do is Is like stuff like yeah, we we go out we demo things to people We like will you will like talk to different? Organizations and stuff like that and show them how to use it and stuff like that or we employ people at companies to be champions and have them have them actually show people and evangelize it but uh, Yeah, I don't know I like we we do stuff to suggest stuff and suggest prompts and whatnot But I'm like, I don't really feel like they're that successful to be honest. Mm-hmm. Yeah Yeah it's an interesting challenge because even The company that I work at solving a lot of similar challenges of like how do you build for both users at the same time? We've thought about is it worth doing a really robust onboarding tour? That's you know, it was step by step through all different things gives you like walks you through an example Yeah, or do you clear all that out and just have them figure it out on its own? I think it's still a problem. That's totally up in the air. Yeah. Yeah Yeah What's interesting is like the user base is changing over time to like at some like I was thinking about this the other day Where I was like at some point maybe people won't actually have to educate people Like we're no longer really educating people about how to prompt anymore It's actually the general populations ability to know what to do with it It has increased a bunch sure and I think over time like that will also continue to increase With some of these like more agentic tools and I'm like maybe one day We actually won't have to teach them any of this stuff. Yeah, but I mean the models will always like keep exponentially, you know Getting better. So there probably will be more and more capabilities that we have to teach I'm I'm really interested in that. I think we talk a lot in the space kind of following that like the duality that chase mentioned of you either have your power user or your person who is not a I pilled and Doesn't really know much about How many of this stuff works? It sounds like though you you have some opinion about The general populations and knowledge of how to use these tools and how it's changing I would love to hear more about that and what you're seeing from from inside anthropic as far as the general populations Maybe they're non tech designer a I've told people's yeah understanding of how these tools work. Yeah, uh, I mean, I think there's like a bunch of different changing variables right now, like I actually I Actually don't spend that much time thinking about complete general population. I'm mostly thinking about Knowledge workers and people who are still somewhat a I pilled like in that they are They're working at organizations where they're adopting AI, but even in the last year So I feel like that that population and what they know and who they are has changed I think that's actually what one really interesting thing about working this industry is like the The like the sort of user split but also like what they know and their knowledge is like continuously changing So I think the things that I started to like think about are I Think even like a year ago. I was uncertain about oh, like do we should we reveal words like memory and context? And agents or should we like abstract them in a way where people? They're sort of like fluffy and and ways that people to understand it like instead of calling it like memory And like knowledge should we call it, you know, what Claude knows or something? But now I'm like, okay. Actually, I think people know those words. Like I think we should actually do a thing where we Just say those words or we just like teach people those words because it sounds like these are long-term things that people will Will know about and these are actually just like the best words to describe them right now and I expect that to To change more with time. Like I think I'm slowly Like I'm slowly of this mindset where it's like, oh, yeah, we should actually do that Like absolutely of this mindset where it's like, oh, yeah We should have to just educate people about these as opposed to like fluff them up in a way that like that doesn't make sense Mm-hmm. Yeah, it's super interesting to hear that you think those are gonna stay and I'm curious if I don't know if they're gonna stay Actually, I don't even know if they're gonna stay but like I think they're words that people are in the vernacular right now Yeah, so then following that thread. Do you think there are? Interactions or UI paradigms beyond just labels that you also think have entered the lexicon of the non-designer non AI p.m I mean one thing that enter the F lexicon and a quickly exited was a sparkle like that's gone Which I think was a Yeah, which makes sense because it's like everything's AI right now. Like you can't put the sparkle everywhere What are other things that have entered the lexicon? Sorry, did you say like things that have entered and exited or are gonna stay but entered in are gonna stay They are you think are here have some staying power? Uh, I think that I think we'll probably always be chatting or talking to the models I think that will stay to some extent. I think I think it will say it will stay Because it is it's just like the most flexible way to Interact with something and I think the reason it didn't exist before is because We just didn't have the power to talk to our software So we had to build UI around API is because people couldn't not everyone can access an API But now you can just the API is just you talking and so if anybody can do that and you could basically have UIs that are much more flexible than just the one that you know Somebody has designed around like a golden path, then I think that's paradigm will stay. Mm-hmm yeah, we've had a few other design leaders come here and suggest or yeah, yeah suggest that they Think that chat is like the best we've got right now, but talk like they expect something better to come. Yeah Would you agree with those people? Uh, I think it will be a mix of multiple things I don't know if there's gonna be like wow like this one great paradigm or anything I think what we're already seeing is that the models are getting better at generating UI on the fly Mm-hmm. So I think I expect it to be like In moments where UI is much more helpful and faster and direct there should be UIs But I think if there's any other interaction outside of the UI We now have the power to like conjure that and we never had that right like I think I think Imagine you know a Maybe like some sort of like audio app or where you want to adjust the volume How annoying would it be to be like? Hey Claude increase the volume increase the volume a little bit more or less like that doesn't make any sense But if you were like listening to something Claude and Claude could show you like This dial all of a sudden and then you turn the dial that's awesome, but then You know, you're actually like Oh Claude I want to adjust the bass and that Claude didn't give you a dial to adjust the bass you but okay Claude Let me adjust the bass then And and you can now do that even though the model hasn't like presented you with a UI for it so I think that is sort of that feels like the future interaction where it's like you have you're able to Do the things that need to be done quickly through Probably specialized UI, but you can always like talk to the models Do you think there's anything Lost there with like if every UI is generated you always have a new one on the fly Is there anything lost with like becoming familiar with the UI that you use every day? Probably I Don't know but yeah, I don't know if every UI will just be generated on the fly. Sure, you know yeah, I don't think even in that case like It'll probably still be helpful to have UI patterns that like the that you get presented that you're familiar with. Yeah. Yeah Yeah, like it's like if you had this totally new UI for like adjusting the volume or something It's like oh, you know, I need to press these seven buttons like And then how do you think about like Setting the guardrails of cloud can generate anything if it can make any piece of UI if you can pull from existing patterns How do you make sure that it's still the experience that you're looking for to give to your users? uh, I mean, I think with these it's I Think it's a little too speculative to say yeah but I think the same way you would sort of like Train a model in an eval it against like What is good quality writing? I think we just have to do the same thing with UI. Yeah. Yeah. Hmm. I Want to come back to co-work and this question I'm really interested in asking about it because I feel like it applies to so many other contexts We were just talking about the idea of I don't know what what users expectations are of AI capabilities and how those are changing What co-work does is you as it, you know manages documents and creates assets? Yeah You want the user to feel in control but the whole point is letting Claude do the work autonomously You landed on this plan model and So, you know call to make a plan and then you'll execute it, right? I'm very curious what you have learned trying to onboard people who If they haven't used cloud coding or kind of getting introduced to this way of work what you've learned about this Guided human-in-the-loop yet agentic workflow. Yeah I Think that's a balance. We are always trying to strike is what is the right amount of human intervention? And I think it also it depends on a few things like it depends on like one How good is the model or how good is Claude at doing this task? a Second thing is like how long is Claude gonna be doing this task for? And then Like a third thing probably is also like how important is this to me? And and and do I really care about this being a high-quality? There probably other things to consider but like top three things that come to mind are those and I think I think it's like it's We're like constantly trying to find the sweet spot and I think given what? The models good at right now, you know like it's it also just like to sort of I found that it also depends on the person to like we Like we found that people really want to know like what Claude is doing ahead of time Because they're like, oh if it just like immediately housing a wrong step if it's like, oh, I'm gonna check this slack channel You're like that's the wrong slack channel You want to be able to correct that right away before it goes off and does like, you know These days it's probably like a five to ten minute task or something. You're asking it to do so We Make the plot we sort of show people the plan and get them to approve it ahead of time But at the same time it still will do small tasks like it's without giving you the plan Like if if you're just saying like, oh, yeah, like search Search the web for things about shoes or whatever. The club will just do that without a plan Because that's pretty it's pretty fast and like the the directive is pretty clear So I think it's for us. It's just like kind of tweaking that based on What we see, you know the tasks people are doing and like the overall ambiguity of it But I think it's always perfect like we get a lot of people saying like, oh, yeah I don't want to see this or I'm like not seeing the plan often enough Or Claude's not asking me enough clarifying questions before it actually starts running. So it's hard to do well for everybody So Jen you talk and have some opinions about the design process and maybe how it's been shifting and sort of evolving The name of our podcast is double diamonds not not because we are adamant supporters of it But because we're interested in and also that like how leading designers are following the design process and how it's shifting With that in mind, I'd love to see some of what your actual design process has been on something you've worked on. Yeah. Yeah So I can show you in co-work how we like just a way that I've been sort of like changing the way that I kick things off So one thing about co-work is that it does run like locally on your computer so what you can do is, you know, if if you've done all these like research interviews or Been on all these like zoom calls or Google meets with your users and have those transcripts You can store those in a folder somewhere and co-work It's actually really good at this thing that I call like garbage in treasure out where you can just like throw it like a stack Of papers essentially and then pull useful insights out of that. I Can't show you those specific interviews necessarily But like I think that's a really good way to use it it's just like you you choose like work in a folder you have all the the files somewhere and then you Like ask ask Claude like hey, you know like based on these interviews like what are the insights you're pulling out? But let's actually do another type of way that I collect feedback, which is like, okay like look at Co-work feedback from like Twitter slash X Reddit and other reviews on the Internet and pull out top themes and Then Claude will oh no, it's it thinks it's co-working space I know it actually doesn't the title or just represents that and Claude will sort of like do that in the background and Search for that feedback and then tell me what it is And I think one nice thing too that I can show later on is you can actually get Co-work to do this on a scheduled basis and have it maybe run like every day at 10 a.m on the morning and then for you to just like get to your desk and see those every day so that way you can just like Yeah, you have this like really constant view of what you're using really constant view of what your users are saying and then be able to act on that as opposed to having to do that by yourself. And then you can even have that send out to Slack and say, oh yeah, send this in this specific channel, and then all your coworkers will see it as well. So it's searching. This is going to take a little bit of time. Cowork, I think what's different about it from chat is that it's able to deploy a bunch of sub-agents, do a bunch of stuff in parallel, and just handle much greater volumes of information and turn something into that. So I think when people ask me, oh yeah, what is chat versus cowork? What are they useful for? You often can do the same use cases, but cowork will just be better at handling a lot more data from it. So it's pulling up top themes. There's some good stuff. It makes AI feel like real work. Some folks feel like their usage limits burn too fast. The wrapper is a product in many ways. So there's a bunch of insights here, which is really good to see, but it's pulling up this feedback for me, which is great. And then, cool, I have insights. That's great. But what can I do with it now? So I can ask Claude, okay, cool, based on those insights, what are maybe three very specific product improvements you would make? And Claude will think through that. That should work a little bit faster. Cool, like maybe a persistent user profile, some sort of token budgeting, okay, okay. I'm very curious, right now it's streaming, but in the state in between, like right when you submit and stream and you have that thinking but nothing yet state, what are your goals in that state from a design perspective? Oh, like when it's sort of like doing a bunch of stuff. When it's doing a bunch of stuff, like deep research or an equivalent. Yeah, I'm actually showing you just staying on the screen, which is actually what I would not recommend. That last query ran for probably a few minutes, and in that case, I would actually just switch out of it, or I could even just start a new task. And I think what a lot of people do is they just will spin off five, six of these at a given time, and then come back to them. I think this way of showing you is very focused, and it's actually not the best way to work with Claude. So yeah, I think, and I think as like Claude gets better and better at like longer term running tasks, like I think right now it's this weird, like awkward period of time where it's like not long enough for you to go off and do something totally on your own. But it's still like pretty long and that you don't want to be staring at the screen. So it is a little bit weird right now. Okay, so Claude's recommended a few things for me. Okay, it's telling me, okay, maybe there's some like persistent user profile. I think that's a pretty good, that's a pretty interesting idea. So one thing that I like to work with Claude on sometimes is just like coming up with like a first draft, like of an exploration of something, of a design, or of the design that I've implemented. It's like, I think it's really good at just like helping me to visualize things. Like I often just like to see visuals of things before I turn it into like an actual design. So I'm not like getting it to make the design necessary for me, but I'm just getting it to like kind of get rid of that blank page problem for me when I'm designing. So I'll talk Claude like, okay, I like the first idea, the persistent user profile. Make me a first draft wireframe of it, but ask me some clarifying questions so that we are aligned on the idea. Let's see if it asks me those clarifying questions. I'm curious, right? You say, make me a first draft wireframe. As the designer, you want the wireframe to appear in a way that matches the user's mental model of wireframe, whatever that might mean, but it could appear in many different ways coming back to the theme of non-determinism. Is there anything you do from the design perspective to make those moments hit more, make them match more like what the user puts in? Or is that all just like the model that carries that? A lot of this is the model and the way that it's been trained or has the skills that are loaded in that give it different aesthetics or the wireframe. Yeah. So it's not something that I'm like directly influencing, but is something that we're generally like training the model for. Okay. So like I asked Claude to ask me some clarifying questions. Sometimes it does these like pretty proactively, but I like asking it to ask me proactive questions too, so that we like, I don't have to do a bunch of typing up front. We can just like have shared, shared understanding of what the task is. So okay. It's asking me like, where should the profile live in the UI? Let's say it lives in the settings panel. What level of detail should the profile capture? Let's say moderate. Should the profile be fully user managed? You write your thing. Let's do both auto learning and editing. Who's the primary audience? Let's say it's an internal PM review. Cool. Yeah. I like, I like when Claude asks me these questions and then I can just like click through, which I, which has been like a really helpful feature in Co-Work. Is that a very intentional decision to try and like build trust with the user? Because like you get rid of the chat input, right? It's only these questions you can, you can tab through and then you can enter a manual input if you want. Yeah. Yeah. What, what, what did that like idea of stopping the whole interaction and focusing the user on, where did that come from? Yeah. I mean, we, one got, we, one biased Co-Work towards like actually asking you this question. So that's the thing that like it tends to do. And, and, and like, yeah, it will, it will tend to do this, especially when it comes to these ambiguous tasks. We found that like it actually creates better outputs. And then we designed that interaction around like being able to click, but then have like the input box. Cause it's like, again, like this, I think this is something that I was mentioning where it's like, I think UI is helpful for speed, but then you always, since we're able to just like use natural language, we should always have that option because we're no longer limited by just like what, you know, what the API can handle or not handle. We just now have like all of natural language to be able to deal with the LLMs. So yeah. How do you think about the design of this, this spinner? I would call it at the bottom. You have, what's that? The loader, the loader, the loader, the spark. It looks a lot like what I'm used to seeing in cloud code, but it looks a little different. Right. What did you, how did you figure out what you choose to allow it to present there? Yeah. It is not going to have an open cloud for Chrome. It's, it actually has existed long before cloud code. This, this spark is the same one that we use in chats as well. I think the tough thing for us to sort of show here has been like, you know, what, how much do we actually show in these like tool calls, for example, I don't want to do that. I was going to ask about that. Yeah. So that it shows you a bunch of stuff here. And like we, over time when we first started, like we actually showed all of this code and underlying stuff that, that cloud is doing. But over time we've actually started to obscure it more and hide it. Some people actually really like seeing what's going on because they're sort of like nerdy and they're into it and stuff like that. And they want to really verify that cloud is like doing the right thing. But over time we've started to collapse it because I think people trust cloud more and more. And so I think over time you'll probably like just see less and less of the stuff. And then the spark actually represents like, we're trying to tell you as often as we can, like what cloud is actually doing. So it'll be like, oh, it's writing or it's like thinking or, you know, it's starting up because we want to be as transparent as possible what's happening and to make you sort of like feel that there's progress. I think it's interesting that you are becoming more comfortable with showing less of the tool calls. And I wonder if you think that that is something that is unique to cloud and Anthropic, or do you think going back to our conversation earlier, people, the user base for chat driven, LLM driven experiences are becoming more familiar and trusting with these tools and in general don't necessarily need to see every single step by step anymore? My hunch is that, well, it's two things, like people are becoming more trusting and the models are getting better at it. And so like those two things like have to happen in tandem. And so like, we no longer need to see all the time that it's doing the right things. But as it does, like bigger and bigger tasks, like there are things that you will want to verify, especially if it's like cloud is going off for like 10, 15 minutes, right? You do want to sort of see that it's going to be doing certain things or you want to prove like it's planned or whatnot. So my hunch is like the sort of like granularity of what you see cloud doing that will sort of increase over time. But I think people will always want to like be able to trace and have the option of seeing what cloud is doing. Yeah. Okay. So cloud made me this wireframe. I don't know. I'm going to click on it. Hopefully. Hope it's good. Hope it makes sense. Oh, it's not really in a wireframe style. I think I've had to make things for me in a wireframe style before. But it's a good like sort of first pass. Like it sort of shows me, okay, like I can visualize, maybe this profile actually lives in the settings. And it's kind of showing me different places that the profile could live in. It's usually like these are usually like kind of interactive too. And like, this is not a thing I'm not, I'm not going to just like implement this, but it's helpful because I'll sometimes just like take screenshots of this, you know, and then I'll like bring it into like my Figma file or something. But cool. Like now I have this picture of like what it could be. I can ask cloud for like, oh, like let's do another exploration or like, let's do something that's a little bit more blue sky or something and continue to prompt it. And so that's one thing that I'll use cloud for. It's just like getting like a first idea on the page. So I can start from there. And then like, I probably won't show you this as a demo either, but because it takes a while, but like what I can also do is, you know, it's pulled all these insights from me before it has like both these ideas, but also like all these like pieces of feedback and themes, I can ask cloud to just like make me a slide deck and be like, cool, I'm going to bring this back to the team. And then we have all these insights and we can flip through them and see what the insights are. So I think it's really useful for like pulling a lot of like information from a lot of different sources, kind of like extrapolating important things from that, and then just making a bunch of different artifacts for you to actually like process and understand that information. And I think that has been really helpful as a designer on the team. This is super cool to see. Yeah. Very, very cool. Yeah. So from here, I'm interested in like, you've spoken about like how sometimes vibe coding can lead you down one particular direction or like it can lead you down one specific rabbit hole. But I think still being able to see a sort of diversity of options and explore that is really valuable for you. What is that part of your process look like? Where do you draw inspiration from? Is it, are you looking to like physical product design? Are you looking to other products? Are you working like within Cloud itself? Like what does that exploration process look like for you? What does that exploration process look like? Like, I mean, I think some, like the dumb thing I'll do is just ask Cloud for a bunch of different options to start with. Right. They're not always the most amazing. Like Cloud's not the most like creative yet or like creative design or anything. But that's just like one way to get started because I personally just like to like explore the space. And then I think from there, like I'm still like taking other stuff and they bring it to Figma and like exploring a bunch of different options there because it especially helps to off. Like I really like designing at like a decently high fidelity because I do think that like visual design differentiation, even when you're sort of exploring things early on really helps cement and for you to actually kind of like test if the concept is viable. So I'm still doing that stuff. Yeah. Yeah. Makes sense. Yeah. Yeah. I'm really curious what the value you've seen since you've rolled out Cowork, what the value is in particularly being able to give Cowork visibility to local files in a local folder. What does that afford you that, you know, just a chat that makes tool calls over over the cloud, over the Internet doesn't? Yeah. So one thing I really like doing is I like pointing it at like at like lots like things where there's just a lot of existing data. So, for example, like I write all my notes in IA Writer and I will write like, you know, just random thoughts in there, like one on one notes. I will write like interview feedback, et cetera. And it's just like this like ongoing sort of like both personal and work like knowledge base. And those get stored as like markdown files in my in my computer. And then I just access that through Cowork and I just like pull from it where I think it's different from, you know, with chat like me having to upload certain files and have it sort of like and having to maintain that and then having it just have these small windows of context within each chat. It's like this thing I don't have to maintain, but I can sort of like pull from the wealth of knowledge on it. Yeah. And then I'll do stuff like I will I will ask Claude to like, hey, like given my notes from like, you know, this this this last week's like one on one's like, how should I think about how the team is staffed or something and like start to like have that conversation? It's just like not a thing I have to maintain. Yeah. And what are you think the biggest use cases for Cowork? Yeah, I think there's like so many. There are a bunch where like this is this is the whole thing where we create the primitives and the use cases are like sort of open and endless. There's so many like some of them are the ones that people are doing right now is like tax season, like they're actually having they're dumping all their like WTUs and and things like that into a folder. And then they're having Claude like fill out the tax their taxes for them. Well, yeah. Yeah. Or like do analysis and stuff like that. Yeah. Because it'll it'll sort of tie together, like reading the files, plus like filling out the forms through like browser use, basically. And there's a bunch of stuff where people are like, oh, yeah, I'm also getting to fill out my benefits and my expenses and stuff like that through that same way. Like the the EM on my team recently had a baby and he's just like, oh, yeah, I'm getting it to fill out insurance forms for me. Incredible. So there's stuff like that. There's stuff that is like, you know, people having transcripts of like of like podcasts or of like videos and stuff like that and just and like reading over that and creating analyses. There is a lot of good ones, like spreadsheets, too, and stuff like that. Like, oh, like take this existing spreadsheet and transform it in a certain way. Yeah. It's just like anything where it's like there's a lot of information and you sort of like need to transform it or extract from it. Like co-work is really good at. Love it. Love it. Yeah. I love it. That tax. I love it. That tax example really has me thinking. I mean, you should verify, you should verify your taxes and your financial. I'm not saying like, you know, but it's like, that's a thing that people have been like trying to use it for. And it seems like it's been taking away a lot of tedium. So, yeah. Awesome. Jenny, appreciate you showing us that sort of some of your design process and giving us insight into like co-works capabilities. We'd love to dig into now sort of how you're seeing the roles of design PM engineering kind of converging or manifesting specifically at Anthropic where like PMs can vibe code and ship to production. Designers can vibe code, can like fully build out entire features. Engineers can start designing. How do you see the sort of segmentation of responsibility for projects? Yeah, it's definitely blurry, but I still feel like we're doing pretty different things. Things that I'm seeing on my specific team, and I think this team was like pretty particular in the way that we operate. The big, I think the big thing that is causing change in a lot of the other functions is that like engineers are just super fast, right? Like the models are just really good at coding right now. And especially like, I think the big watershed moment was like Opus 4.6 and was it December or January? I don't know, 4.5. Well, there was like one movement right before Christmas. I think it was 4.5 actually. Yeah, it was 4.5. And like, it just felt like that was a really magical moment for both coding, but also for like cloud code capabilities. And it just felt like, you know, engineers just got so fast. And so now it is like at any given time, I know an engineer is running like, you know, a million clods and they're just getting them to do a bunch of things really quickly. So that then changes, I think, the role of both PM and design. I think one interesting thing is on a lot of the projects that I work on, I'm actually just like working with one engineer as opposed to like five to 10. And I mean this by like, but I mean this as like sub features. Like there's still a bunch of engineers on the co-work team, et cetera, but like for a given, like for example, we launched schedule tasks last week. That was like me and one engineer. And because they're like so capable of, you know, shipping a thing end to end without others. And so what that actually means is we didn't really have a PM for the project. Like it was just me and this engineer jamming on it. And what that looks like also was the engineer just like one day just implemented a first pass on it. I think at that point I had created also just sort of like pretty rough designs. Like they were sort of wire framing. I made them in Figma and I showed them to the engineer. And then he like came back like a day later. I was like, they're done. And here they are. And I think he actually just like had made some like taken some liberty to, to change things. And I was like, cool. And then what we did then is we put it out on our internal builds. We had people use it. And then we were like, okay, when do we think we're going to ship this? Cool. Like, yeah, let's ship it. Like maybe, you know, we have to fix a bunch of this stuff, but like maybe like a week from now. And then given that, that I then like went in and I polished a bunch of it and like Che made a bunch of UX changes and stuff based on the feedback we were hearing. And yeah, it was pretty like low key in terms of coordination. It was just me and this engineer. Like this engineer also like lives in New York but I actually just, we mostly worked on it async together, like through PRs. And we didn't need anybody to like manage the scope of things because it's just the us two. And it just sort of happened. We still have a PM on the team, but I think what I noticed there is like, it sort of freed him up to do like higher leverage things. And he's working on things like helping us get into different like enterprises and teams. And he's doing a ton of things, but he's like not necessarily working up like the execution level anymore. Whereas I think in the past, a project like this, you would have like four or five engineers and at that point you have to like coordinate them and you have to like write a PRD and like tell people what are P0s, P1s, et cetera. And so it just made this loop where it was just like, it was just the two of us working together. I put, I did like one set of designs and then everything else was basically just in code. So I think that's a good example of like, okay, you know, there's more projects where engineering actually kind of leads and then design consults in a way and then we polish things up and then PM actually doesn't like need to be a part of that. And that's okay. Yeah. So that's one way, one big thing that I'm seeing. Yeah. Did the idea for that, for that feature, did that come from a PM initially or did it come from an engineer playing around with things? I don't know. I think it felt like, I don't actually know where the idea came up. I think it probably just came up from the team and it had maybe been something we had talked about before but had never built yet. But I'm not sure, I'm not even sure like what the provenance of the idea is. Like, I don't even think it matters. So I think, but there are a lot more things now where the idea comes from an engineer on the team. Right. Yeah. I'm curious if this way of working you describe, is it, we'll start with ad-anthropic and then maybe expand to the industry. Yeah. Like ad-anthropic, is it a nice to have this way of work or is it fast becoming or already an expected way functions collaborate? I don't know if every team on a topic works this way. But I think it's like more and more becoming the way because it just, anybody can implement anything at any given time. Like it's so fast to create a proof of concept where I think before you had to like have the idea and like people would often have ideas and then they would write a document about it or they would take the time and like prototype it and stuff like that. But now like the time to prototype is like so fast. Like it literally could be like one prompt if you really wanted it to be. I think there probably is something special about it being an ad-anthropic, given that like it is a, like one of the frontier like model labs, right? And like what we are ultimately doing is like taking a technology and transforming it into something for users. So a lot of it is just like needs to be bottoms up as opposed to top-down dictated. So there might be a part of that that's like very special towards ad-anthropic, but I feel like the ability to sort of turn out ideas from everywhere, like that feels like a capability everyone has right now. Yeah. Digging slightly specifically into the role of the designer, you spoke sort of at length about the value of craft and then also being able to ship code or polish code in production. And I'm interested, I've asked a few other design leaders this, I feel like those two skillsets are sometimes at odds and maybe this is just at least the way that I learned this, wherein shipping code, polishing code, maybe it's through an IDE, maybe you're using a coding agent that can rely on building an understanding of technical implementation, like whether it's learning React or just getting familiar with code. And then oftentimes craft can employ graphic design skillsets, where it's visual design, you're practicing illustration, you're practicing typography. It seems like these two skills are both very necessary simultaneously. Do you think one is more important than the other if a designer were to spend their time and dedicate to, or should they sort of be like equally upskilling in both these areas at the same time? I think getting to ship to production is not that hard anymore. Like I think everyone should just know how to do it. Like if you could talk, if you can chat with an LM, you can ship to production now. So I don't actually think it's a skill to learn. Everybody can do it. I think there's some scary parts, some like workflow parts, where it's like, oh my God, I have to like homebrew, I gotta, you know, brew and sell or whatever. You know, there's also stuff that's scary, it's like, oh my God, what if I RMRF my desktop? But like, I think those are all very learnable. And like, you know, and also if all else fails, just ask the model, you know? Like it's now becoming less and less intimidating to do it. So I actually don't think there's much to learn there. Mostly just a barrier. And I think the tools will eventually also just make that easier and easier and like abstract things further and further away and just be more and more capable that there's just, I think there's less to learn there. Yeah. Yeah. So I don't think they're competing. Sure. Yeah. What do you think would be the most valuable skillset that a designer could basically build up today would be? Yeah. I think it's just like the ability to execute and make something good. Whatever that, whatever comes into that package. And I think that is like, that package is like changing. It really is just like time to build right now. And I think there is, you know, like we worked through a few, like, you know, the past like 10, 15 years, like, you know, there were companies that shipped really quickly there, but there are also a lot that didn't. And I think we just like didn't value shipping as much and the ability to just like get something out there quickly that's good and iterate on that. That actually is like a core skill that we didn't value enough. Like we just talked about visual design, interaction design, prototyping as like skills, but I think shipping is a skill. And I think right now in the way that we work, people either have it or they don't. Like it is a core skill that you need to have. Totally. Yeah. Totally. Looking to the future beyond where we are right now, I think cloud code was certainly an inflection point in my career and every other designer I talked to, assuming they are cloud pill and cloud code pill, it is an inflection point. Step function change. There was a before and there's an after. I'm curious if you have any predictions about what the next step function change or product introduction might be for people who build products, what shape it might take, what it might look like, whatever you feel inclined to say. I think that the code part of the workflow is really good right now, but I think the other parts are not yet. Like the design part of the workflow, like I think when I think about, you know, working with a bunch of engineers at work and how fast they are, I feel really slow still. You know, like it's like I no longer can work at the same time with like seven engineers and like do a great job because I feel like the design part of the workflow is not optimized in the way that the coding part is. Like we don't have that cloud code for designers. Designers have cloud code, but we don't have that cloud code for designers. PMs also don't have that cloud code for them. Like maybe that cloud code for them is actually gonna become co-work, but design does not have that yet. So what is that for designers and when will that come? I think that will be a really big watershed moment. Yeah. Excited to keep our eyes open for the future. Yeah. Cool. Okay, then I wanna end on sort of this last note here. There's a tweet of yours that I saw that I love that's basically to the effect of a lot of things are happening very fast right now. There's new model releases. It feels like there's a new tool every day that drops. There's a lot of pressure to learn these tools, to up-skill and to ship things more than ever. That's sort of the expectation now. When do you choose when to go slow if everything's happening so fast? How do you prioritize that? Yeah, yeah. It's funny because I feel like this is just like me standing on the subway platform being like, when do you choose when to go slow? Send tweets. I was like, oh my God, I'm so profound. I'm gonna like tweet this thing. But now it's coming back to me. Yeah, I don't think we have figured this out. And I think that's actually related to what we just talked about in that, now that it's so fast to go from idea to prototype or some implementation, there are things where I still want to slow down, but I feel slow as hell doing it. And I'm like, it feels uncomfortable to be slow. So for example, like, okay, each engineer can come up with like, or each engineer or designer or whatever, we can like actually create like 10 different features if we wanted to. That's easy. We can put them in code. That's also easy. But now you have like 10 different features that might overlap or conflict with each other or like the mental model's not super clean. And I think right now what that requires you to do is like as a designer, you have to like sit down and be like, okay, like there's like these 10 different features that are somewhat alike. How do we explain that to users? Like what's the mental model? And like, how do we make sure all the interactions make sense and stuff like that? And that still takes time. And I don't know if we've one, found the time to do it or two, even appreciate the time that it takes. But I think that's the stuff that will make products coherent and high quality and make sense. And I don't know, like I'm like struggling to find time to do that, but I know it's important work. And I, yeah, I don't know if we know when to slow down and do that work. Yeah. Maybe a slow is smooth, smooth is fast situation. Yeah. I'm curious how you figure out what to yourself focus on learning. There's a deluge of new stuff happening, new information, new tools. How do you figure out or what makes you go, I wanna learn what that's about or try something new? Through all the noise, what's the signal? What you chase? I mean, I think I'm lucky in that I work at the Frontier Lab. So that I just, basically the way I learn what to do is I just see something, somebody else do something on the team. And then I'm like, okay, that's smart. I should learn how to do that too. Like I'm like learning all like, you know, like last week I learned how to use like work trees and Claude code. Cause I just saw somebody else on the team. Like, or I heard people talk about it. I'm like, okay, cool. I should learn how to do that. I don't know if I would know otherwise. Cause yeah, there is so much stuff to pay attention to. But luckily I think being at work at Anthropicum, it's sort of like narrows it down to like, oh yeah, I'm probably gonna use Claude. I'm probably gonna use one of the Claude products. And then I'm just gonna see who, like what the people building these products, what they're doing with it and learn from them. But even then I still feel like I'm like catching up all the time. I'm learning about features I didn't know how existed. Like, it's like, I don't think I've said, I've spent the time to like set up my Claude MD properly, like and give it all these instructions that I know would be helpful, but I just haven't. There's so much stuff where I'm just like, I'll learn it eventually, maybe. Yeah. I think the ultimate thing that it comes down to is curiosity. Being open and being willing to learn and trying new things is sort of a core part of being a designer to build something on the cutting edge. And I think to your point about like the design system not necessarily being the same that it's always been, it's time to rebuild it, right? To try and explore and see what the future can hold. Yeah. It's an exciting time. Super exciting. Jenny, thank you so much for joining us. This is incredible. Yeah, of course. It's lovely to be here. Thank you.