Designing with Claude: From prompt to production

1. SPSpeaker0:00

   [upbeat music] How is everybody? A little bit more than that. Come on, guys. How is everybody?

2. SPSpeaker0:18

   [cheering]

3. SPSpeaker0:18

   Thank you. Thank you. So I'm Dan Carey. I am a product manager. I lead a product within Anthropic Labs. Today, we're gonna talk a little bit about Claude Design. Can I get a quick show of hands, who here has already tried Claude Design? Okay, great. For those of you who haven't had a chance yet, Claude Design, it's a new product from Anthropic Labs, and it lets you collaborate with Claude to create polished visual artifacts. These can be designs, prototypes, slide, one-pagers, more, right? You can do a lot of different things with this product. And as of, I think it's yesterday, the product's been live in research preview for one month, so we're pretty happy about that. Today, I'm going to tell you a little bit about how a very small team, it was three people for most of the development, built Claude Design in about ten weeks from idea to launching the product. And the reason I'm going to share these things with you is 'cause the most common question I get asked is: Why did you decide to start working on this? How did you see that this was an opportunity for building a new AI-enabled product? How'd you build it? How'd you launch it? So everything I'm going to cover here, there is no real secret sauce. These are all things that work well for us. Take what you like. You can do a lot of these things tomorrow. To start, I wanna tell you about what Anthropic Labs is. It's kinda funny. It's a lab inside a frontier lab. Um, we don't have any labs within Anthropic Labs, but it is labs quite a ways down. The way that we usually talk about it is as a bet factory, and by that, I mean we have very small teams exploring the frontier of what the models can do and making bets about whether or not something will work. We run experiments to find out what works. We double down on the things that are working. We fold the things that are not working. And at any given time, we might have a dozen small teams exploring different concepts. So it's lots of exploration, small number of really high-conviction releases of things that we think can be moonshots or change how people work with the models. There's a few products that came from here that you may know. Claude Code came out of Labs, Design came out of Labs, MCP came out of Labs, Skills came out of Labs. Uh, we had the Claude and Chrome extension. We had our work on hands-free audio come out of Labs. So this is a process that's worked pretty well for us, um, and we just keep turning the crank on this. If you look at how each of our bets operate on a day-to-day basis, you're going to see a lot of parallels with lean startup methodologies. Nothing there is rocket science. We did not invent any of these things. I'd say the biggest difference is the speed at which we run our loops. We spend time with users and also Anthropic researchers every single day. My favorite thing to talk to users about is, "Please complain at me." And my favorite thing to talk to researchers about is, "What have you been surprised by lately?" Because both things are often opportunities for new bets, new products, new things to explore that could pay off for us. We also aim to ship to users every day or two, right? We're trying to ship something new every single day in response to what we hear from people. Um, we are trying to keep a very, very high cadence of innovation on the team, and we are trying to get things out based off of what people tell us. Likewise, when people tell us something's not working or they have feedback or they have a suggestion early on in a project, we try to ship them the response to that the next day. Um, oftentimes we're able to do the same day, sometimes it's the next day. Not everything hits that bar, but our usual goal is to get things out very quickly to people when they have feedback. Finally, we do not try to predict the future. A lot of labs groups out there do try to predict the future. They say, "In ten years' time, we're gonna have this amazing technology, and it's gonna do these amazing things." We don't do that. Uh, instead, we try to ship. We watch people use the stuff. We learn what they do. We ship, we watch, we learn. We ship, we watch, we learn. We just run that loop over and over. And so for Claude Design, we ran that loop somewhere between fifty and a hundred times over the course of those ten weeks. So why did we start working on Claude Design? Well, we started working on Claude Design because Claude Code made engineers really, really fast, and the rest of us had to keep up. So product development timelines that used to be six months, and then they'd be a month, and then a week, and now a day. So sometimes things that you were spending a week on before are now something that you're getting done in a couple hours and getting out in front of users. That is rapid. Can I see a very quick show of fingers from people, I'm very curious, the last feature you shipped, how many weeks did it take from idea to getting it in front of users? It's okay if you need two hands, and don't be shy here. One, one, ten, one, two, one, four, one. A lot of different answers, but things have gotten a lot faster. Think about what your answer would've been a year ago, right? All these timelines have compressed a lot. And so once Claude Code took off, the bottleneck moved. The bottleneck moved from building the feature to figuring out the right things to be building for your users in a lot of cases. So the option was either, uh, you know, skip those early steps, just try and decide on the fly and potentially build the wrong thing really fast, or try to find ways for the rest of us to speed up. So our designers, our PMs were having trouble keeping up. Uh, we needed our own acceleratory tool. And somebody on our team, Nate, he was a designer on Claude Code previously-He had seen firsthand what happens when some of these teams speed up to such a huge extent. And that got him thinking about the problem and a potential solution. And so, he ended up hacking together a prototype over the course of a weekend while he was working on a different bet. And it was very simple. It was the Agent A SDK, it was a very thin IDE wrapper, and it used an existing skill that he had already been using in Claude Code. And this is how a lot of our labs bets start. It's one person, one weekend, one screen recording. Someone gets something, hacks something together, and just shares what they did. So for us, uh, Nate posts this in Slack. We run a lot of things in Slack, and everybody helpfully chimed in with both this is what's promising about this, and also here's all the stuff that doesn't work, totally broken, please go fix. Uh, and that was his roadmap for the first couple weeks on this. It was just, what's the promising stuff to lean into? What are the major blockers we want to address? I do think it's worth calling out the things that we did not do. So we did not write a PRD in advance. We had zero vision docs. We had zero OKR meetings. We did not have an H one annual staffing plan. We did not have a two-page year for what we were gonna do over the next two years. We did not write the press release in advance for what we were doing. Those things are great if you know exactly what you're building. We did not know exactly what we were building. All we knew is that we had a spark. Um, so who here works off of PRDs or has written one or worked off of one in the last month? Most of the room. Now, of those people that raised your hand, who would rather be working off of a prototype that worked and showed you the feature fully? Exact same hands, which is pretty good. [laughs] So we like to use prototypes because documents are imprecise. It's so easy for two people to look at the same doc and have two different products in mind about what the experience should be. And usually, those two ideas are not the same idea that the author had when they were writing the thing in the first place, right? So docs are imprecise. Prototypes, they're more concrete. They're more visceral. They let you get hands-on with the thing and really feel the experience yourself. And over the course of this project, we were able to get our prototyping cycle down to a couple of minutes, right? So if somebody had an idea, they were able to prototype it and get it out in a couple of minutes. For us, the easiest way of doing this is talk to it with somebody else on your team, record it, transcribe it. There's tons of great tools for that. And mainly talk about what the problem is, what does the solution generally do, why do you care about solving this problem? And then we would take that transcript, and we would just give it to Claude Design once we had something working, and we would say, "Give me a few options for this." This has effectively replaced PRDs for me as a product manager that's been writing them for almost two decades now. Um, now I just do prototypes. This is my flow. It works pretty well. In Labs, we do this ritual every once in a while. We get together, and we call them pitch-offs. And the thing I like doing about these is we all get together, we brainstorm. You're basically trying to nerd snipe other people to come work on your thing with you that you think the team should do. And when we first started doing these, people talk, and you just talk and present your thing, and it's not that compelling. The first time we did this with Claude Design is what convinced me that we had a promising product on our hands. Because in these pitch-offs, most of the ideas people come up with during the pitch-off, someone says something and you're inspired by what they say, right? Somebody has an idea that you fork off of, and you come up with something new on your own. And by the second half of it, a hundred percent of the pitches were prototypes or slides made with Claude Design, and they were being made on the fly in the meeting. And that's what really convinced us, you know, this is a proof point, we should double down on this bet. We should take this to market. The other thing that's a little bit different about the way that teams work in Labs is the size of the teams. So almost every Labs bet, it starts as a single person. It's just one person with their good buddy Claude, uh, exploring a really hard problem and exploring a pretty hard idea. And at this point, you are not trying to build the best product in the world. You are just looking for that little moment of magic. You are looking for that little hint of heat. You are looking for, "Hey, this is a promising idea because there is a little sparkly glimmer here that we can build into something compelling." And most Labs bets, I'll admit, do not make it past this point. Most things we end up folding before they get here. Um, and that's totally okay. This e- early exploration is usually hours or a few days for most things. Once we do have a promising spark, we usually scale the team up massively, you know, three hundred percent, all the way to three people. Um, so these are not big teams. And the reason why we do that is that we want it to be a very tight group exploring together with very little collaboration overhead. Uh, if something is so compelling that we're pretty convinced that we're going to be taking it to a product, after it's had three people for a while, we might scale it all the way up to five people ahead of launch. So who here works on a team that is smaller than twenty people? Okay, almost everybody, but not everybody. What about smaller than ten? Five? Smaller than three? Is there anyone here that's totally solo? Oh, yeah, a couple people. Three-ish? Three-ish, two and a half? Four, okay. So for most of Claude's Design's development, it was only three people with Claude, and luckily, Claude's a pretty good team member. So what makes that possible? Um, I'm sure this is also true of a lot of the solo builders in this room. Uh, everyone on the team does everything, right? The engineers talk to users, PMs write code, designers do data analysis. Um, all of these things are enabled in part with Claude. Um, and the lines between the roles on this team, they have essentially dissolvedAt this point. You do have your specialization, you do have the unique perspective and diversity that you bring to a team. But at any moment, any one of these people on this team can talk to ten users, you can realize what the underlying problem is, you can design a solution to it, you can ship it to users, you can listen for feedback, you can keep iterating solo if you need to. And quite often that's the case. That's how most features happen. Most things on the team are totally solo. And having this small team where everyone can do everything, that's the main thing that minimizes coordination overhead for us. Again, most things can be done solo, but let's say you have to get the whole team together. Uh, oftentimes that's as easy as talking to the person on your left and the person on your right, and you're done, right? It's not a big alignment meeting. It's not something you have to schedule. It's not something that you have to wait for. And so this helps us minimize coordination overhead. We've already minimized planning and process just by relying on prototypes, and just doing these two things alone would let us go pretty quickly, right? They would let us go pretty fast. They would take down these big, long cycles at the beginning of major milestones. Um, but we go a good bit faster, and we go a good bit faster by then really aggressively optimizing every single other step in our development process, in our loop. So our loop is our loop. This may not be the right loop for you. That's not the message here. Um, if you're working on hardware, this is probably the wrong loop. But our loop is pretty basic. We talk to users, we design features, we ship code, we read feedback, and then we do it again. And we-- again, we're just trying to do this over and over and over and over. And the point's not the specific loop, it's not the specific interventions that we did here. It's rather the thought process that goes into these is why are you doing this work that Claude could do for you a lot of times? Or why haven't you built your own tooling? 'Cause every little bit of optimization that you do on your loop is going to pay you back if you're running it fifty to a hundred times in a project. So for a really simple example, I mentioned that we talk to users every day. We want that to be the easiest thing in the world. We are people, we do things that are easy. Uh, we tend to do things that are hard less often. And so we want the easiest thing in the world for us to be to talk to users. And so we did the really basic stuff from the beginning. We create shared Slack channels with anyone using the product. We do a ton of internal dogfooding. We talk to our dogfooders all the time with new features. But then we sped this up by bringing Claude into all of those conversations. So Claude looks at all of our customer conversations. It looks for commonalities across conversations, 'cause you and I may be talking to different users today who may have the same suggestion. We want Claude to tell us that if we don't talk. Uh, we do it for early analysis, we do it for early investigation. We have Claude do the first look at all of this stuff for us. We're the ones having the conversation. We don't, uh, put Claude between us and the users in that case, but we do have it do all of the analysis that we were already doing on every other conversation as an immediate follow-up. So talking to users, most important thing, obviously we wanna optimize it. Our next thing on here was designing features. And luckily, we have a great product for that now. Um, when we got started, we did not have the tool that we wanted for designing features. Our team, we would use Claude Code, we would build prototypes with it, and then when it came time to share that prototype, I would either record a video or we would put up a branch and say, "Pull down this branch and try it." Um, or you would just, you know, commit it into a sandbox and let other people pull it down and try it. So we wanted to, uh, use Claude Design to design Claude Design, and so very quickly, Claude Design got great at designing Claude Design, which, uh, is fantastic. I have to say, if you could do any developer tool, if you're using your own developer tool to improve your developer tool, it's the best situation in the world. It makes things so much easier. There's a lot of other features that you see in Claude Design today, from the way it explores code bases, the way it links with GitHub. Uh, even multiplayer was something that we built based off of how we were working in Claude Design to design Claude Design. For multiplayer, we were getting to these scenarios where I might prototype something and then share it with somebody else on the team. They would take a look at it, and then they would tell me what they thought we should change about it, and I would hands-on-keyboard type it in, and then we would look at what it was. We wanted to take that step out, and so we just made it possible for multiple people to be iterating on the same design at the same time. We had originally built that for ourselves to go faster, and then as soon as we brought the product over to users, uh, the very first request was, "Can I use this with the rest of the people on my team in real time?" So we made it a first-class part of the product. The next thing that we've done in here is we wanted to optimize how we ship code. So if you've used Claude Design, you've probably used the handoff to Claude Code. It's fantastic. It's such a good way of getting your designs into production. And that's another feature that we built really to speed up our own workflow. When we started out, we would design our features, and then we would export all the files. Then we would import them into Claude Code, and then we would retype all of the context that we had done over multiple turns of conversation with Claude Design so that Claude Code would have all that context. And that was slow. We didn't like it being slow, right? So we wanted to improve it. And so we originally built this for ourselves, and then as soon as we started handing off the product to other people, the first request was, "Great. Now how do I get this into production?" So first was multiplayer, and then right after was, "Okay, now that I have the thing, I wanna actually ship it." And so this was another spot where we just had too much friction. We're working for ourselves. We're optimizing for ourselves to get it out there. The last step in our iteration cycle is to read feedback, right? At this point, we get too much feedback for one person to read through all of it. I think that would be a full-time job. Um-But we still wanna make sure that we don't miss anything. And even if we had that one person whose full-time job was to read that feedback, we would probably miss things. And we would miss things because the number of small issues that pop up, you don't wanna miss them. It's too much for any one person to keep in their head. So to deal with that scale, we ended up building our own feedback clustering tool. It took an afternoon. Um, it wasn't something that we were going to wait on. We needed to have this. And so right away, we ended up building this, we rolled this out, and now we have Claude taking a look at all feedback that comes in. It tries to match it up with system monitors, with system traces. It tries to look for common trends across things. It does initial analysis if things look like a bug. We have tried to make all of those initial steps that we would do looking at that feedback automatic to speed ourselves up. So we also found ourselves, we would take everything it said, uh, and then we would have to come up with a suggestion after reading through all that. So now we have Claude give us a suggestion on how to fix it, and then we found ourselves copy and pasting. And so we just made that a button to bring it directly over into our development tool link. So not everything we built worked, right? Just because you're really fast doesn't mean you're always really right. Um, and we got tons of things wrong as we were building the product. So I wanna tell you about one specific time where we got this wrong. Uh, and that was we started out early on, and we built these really advanced controls. Um, these gave you really fine control over every single pixel. You could do anything with these. These were for power users. And in our early testers, we had a few power users who were very vocal, gave great feedback, and they loved this feature, right? They loved this set of tools. And we thought, "Great, we have something good on our hands. All the feedback that we're hearing looks great." But then as we dug into the usage, we found that everybody else hated them. Um, like, didn't just dislike them, people hated them. They were confusing, they were actively harmful to the product. Um, and so we ripped them out. For us, this took a grand total of one week. Um, so yes, we got off track, but from idea to course correcting and ripping out the feature and going on to the next thing took us about a week of time. Now, if we had been doing, you know, a quarterly development cycle, and we had planned this to do this over a quarter, we would've been off track for an entire quarter. Um, that would've been really bad for the product given that the entire product shipped in less than a quarter. And so for us, it's not necessarily can you always go fast, it's can you always iterate in a small enough cycle that you're able to very quickly find out when you're wrong? This comes back to the run experiments bullet from earlier. So this taught us a couple things. Um, one, this taught us that we should be a tool that lifts the level of craft for everybody, not just the ceiling on power users. It also taught us that we wanna be as open as possible because there will be users that we never meet the full needs of, right? There's going to be some power user, user out there who wants to do something very specific that we're not going to support. And that's what convinced us that we want this to be a very open tool. That's why if you export from it, you get HTML, CSS, JavaScript. That's why we're, uh, trying to do more and more integrations that you can take things directly into other tools. We haven't talked about this publicly before, but I think this week or next week we're gonna be pushing out the ability for any design tool to integrate with Claude Code... Sorry, Claude Design, um, just via their existing MCPs. So we want this to be a tool where you are able to explore, it lists the level of capability for everyone, and then the people that do have very specialized needs, if they have a tool of choice, they can just take their designs right into them. They're yours. So this slide's fun. On the left is that first prototype. Uh, it's a terminal and a browser, and that's about it. Uh, it's not the shiniest thing in the world. This is the level of those early explorations, where all you're looking for is that little bit of promise, right? This is not obviously the final product that launched. On the right is the final product that launched. And there's a lot that separates them. And I'll admit, this one on the left, it does have a little bit of promise in it, but ninety-nine percent of the value came from those ten weeks of iterating and shipping and talking to users every single day. The value came from the experimentation, figuring out what the right thing was to build rather than knowing in advance this is exactly what we are going to be doing. So to put the amount of iteration this team does in perspective, Claude Design, it shipped on a Friday, and by the following Monday, we had shipped sixty-two improvements to the product. That's a good number given that size of that team that we talked about earlier. And we made the product more token efficient. We improved its ability to handle images. We made it better at exploring code bases. Uh, we made most exports instant. It's a pretty long list, and it was all based off of user feedback that we got on launch day. Now, this was not a Herculean effort. This was not something that required all-nighters from everybody. Uh, this was something that was very natural because the team had built up the processes and the muscles and the practice of doing this every single day for ten weeks prior, right? This became a very quick, very normal way of working for us. I, I mentioned earlier that Claude Design has now been live for one month, and so also you may have seen this, but last night we just doubled token limits, uh, for the product. So one of the pieces of feedback that we heard was that people liked it, they wanted to use it more, so we're making that easier. So that's across all subscription plans. Before we close, I wanna share one of the more counterintuitive things we've learned working in labs, and that is that you do not wanna work on the thing that already works. You often wanna prototype the thing that almost works. And the reason why you do that is because the models are improving so rapidly. The level of intelligence keeps going upAnd the next model may just fix the issues that you cannot solve via engineering. We had this with Claude Design. There were a bunch of issues in that early prototype that we did not solve. We did not fix them with clever engineering. We did not fix them with amazing insights. We fixed them with Opus Four point seven coming out. Um, and that's gonna be true of a lot of things that everyone in this room, that we all work on together, right? The model releases are a tide that lifts all boats. They do a lot for you. So remember, early on, you're just looking for that hint of magic. You're not looking for something that works in full, that works completely, that handles every edge case. You're looking for something that could become that in the future. And so that's why when you find it, you wanna start exploring, start building, start bringing it in front of users and figuring out the shape of the product that works. 'Cause the shape's the most important thing, and it's the thing that we all get wrong when we first start. We all have to iterate on it. So, there's three concrete things that you can try tomorrow from this talk if you want, if there's nothing else that you took away from it. The first is go ahead, next time you're gonna write a PRD, skip it, right? Don't write it. Instead, just talk with Claude, talk with somebody on your team and take the transcript in. Don't talk about specifically what the feature is, what buttons there are. Instead, just spend time talking about why you're trying to solve this problem. What are the characteristics of a good solution? And give that to Claude Design, give that to Claude. Ask it to give you three variations on a prototype that might solve that. See if that works for you. The second, pick something that you've been waiting for. It could be feedback clustering like we did, it could be a new analysis tool, and just build it one afternoon. Um, everyone waits on tools when at this point, internal tooling, building your own stuff is rapid. It's very fast. So go ahead, scratch your own itch. You will be happy that you did. It will pay itself off very quickly. The third, and this one looks simple, but I think this is actually the hardest. Take one real feature request. I don't mean like a small bug fix or a padding change. Take one real feature request from a user and turn it around in twenty-four hours. Get the idea in front of them and follow up with them for feedback. And the reason why I bring that up is not this urge to go faster, it's because the first time you do this, if you're not doing this already, you are going to find that there are a bunch of roadblocks in your existing process, in the existing way that you build software, if you've been on a longer timeline. And that could be everything from the way that you do deploys, the way that you ask somebody on your team to review your code. That could be a whole host of things. Um, so going through this once really helps. And I wouldn't try to do all three of these at once. I would layer these on. Um, each one is going to teach you something a little bit different that helps you move a little bit faster. This is the last show of hands, I promise. Uh, who's gonna try number one? A lot. Two? Three? Okay. Thank you so much. That's the talk. Thank you for your time. I'd love to talk to folks who have used the product or even those that haven't. I'm gonna be by the demo booth for most of the day for Claude Design. It's down at the end of the hallway. Um, so please come find me, tap me on my shoulder. Come complain to me or tell me what surprised you. I'd love that. So, thank you so much. [audience applauding] [upbeat music]

Episode duration: 28:00