Speaker A
How is everybody? A little bit more than that. Come on, guys. How is everybody?
Dan Carey from Anthropic Labs shares how Claude Design was built rapidly to accelerate design workflows with AI collaboration.
Key Takeaways
- Rapid iteration and shipping based on user feedback is key to successful AI product development.
- Small, focused teams can build impactful AI tools quickly without extensive upfront documentation.
- Prototyping is more effective than detailed documents for aligning team vision and accelerating development.
- AI tools like Claude Design help non-engineers keep pace with faster engineering cycles by accelerating design workflows.
- Continuous user engagement and feedback loops enable discovery of valuable product opportunities.
Summary
- Dan Carey, product manager at Anthropic Labs, introduces Claude Design, a new AI-enabled product for creating polished visual artifacts collaboratively with Claude.
- Claude Design was developed by a small team of three people over about 10 weeks, moving from idea to launch in a research preview phase.
- Anthropic Labs operates as a 'bet factory' with small teams running fast experiments to explore AI model capabilities and ship high-conviction products.
- The team follows a lean startup approach with rapid iteration cycles, shipping updates daily or every couple of days based on user feedback.
- They emphasize prototyping over documentation to reduce ambiguity and accelerate product development.
- The motivation for Claude Design came from the need to speed up design workflows as engineering cycles became much faster with tools like Cloud Code.
- Initial prototypes were hacked together quickly by team members and shared internally for feedback and roadmap setting.
- The team avoids long-term predictions and instead focuses on shipping, observing user behavior, and iterating quickly.
- Claude Design supports collaborative real-time editing and exports to HTML, CSS, and JavaScript to integrate with other tools.
- User feedback drives continuous improvements, including features for power users and instant exports.
Chapters
- 00:00Introduction and Overview of Claude Design
- 01:49Anthropic Labs as a Bet Factory and Experimentation Process
- 03:27Rapid Iteration and User Feedback Loop
- 05:01Motivation for Claude Design and Development Timeline
- 06:54Prototyping vs Documentation in Product Development
- 08:32Team Roles and Collaborative Workflow
- 12:22User Feedback and Feature Development
- 14:10Export Features and Integration with Other Tools
- 23:16Philosophy on Shipping and Learning from Users
Full Transcript — Download SRT & Markdown
Speaker A
Thank you. Thank you. So I'm Dan Carey. I am a product manager. I lead a product within Anthropic Labs. Today, we're going to talk a little bit about Claude Design. Can I get a quick show of hands? Who here has already tried Claude
Speaker A
Design? OK, 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, slides,
Speaker A
one-pagers, more. 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.
Speaker A
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 10 weeks from idea to launching the product. And the
Speaker A
reason I'm going to share these things with you is because 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
Speaker A
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 want
Speaker A
to tell you about what Anthropic Labs is. It's kind of funny. It's a lab inside a frontier lab. 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
Speaker A
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
Speaker A
down on the things that are working. We fold the things that are not working.
Speaker A
And at any given time, we might have a dozen small teams exploring different concepts.
Speaker A
So it's lots of exploration, a 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. Cloud Code came out of
Speaker A
Labs, Design came out of Labs, MCP came out of Labs, Skills came out of Labs. We had the Cloud 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,
Speaker A
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
Speaker A
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.
Speaker A
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
Speaker A
every day or two. We're trying to ship something new every single day in response to what we hear from people. We are trying to keep a very, very high cadence of innovation on the team, and we are trying to get things out based
Speaker A
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. Oftentimes, we're able to do
Speaker A
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.
Speaker A
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 10 years' time, we're going to have this amazing technology and it's going to do these amazing things. We don't
Speaker A
do that. 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.
Speaker A
We just run that loop over and over. And so for Cloud Design, we ran that loop somewhere between 50 and 100 times over the course of those ten weeks.
Speaker A
So, why did we start working on Cloud Design? Well, we started working on Cloud Design because Cloud Code made engineers really, really fast, and the rest of us had to keep up. So, product development timelines, they used to be six months, and then
Speaker A
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.
Speaker A
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 OK if you need two hands. And don't be shy
Speaker A
here. One, one, 10, one, two, one, four, one. A lot of different answers, but things have gotten a lot faster. Think about what your answer would have been a year ago. All these timelines have compressed a lot. And so once Cloud Code took off, the bottleneck moved. The bottleneck moved from
Speaker A
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 skip those early steps, just try and decide on the fly, and potentially build the wrong
Speaker A
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. We needed our own accelerator tool. And somebody on our team, Nate, he was a designer on Cloud Code
Speaker A
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
Speaker A
weekend while he was working on a different bet. And it was very simple. It was the Agenda SDK. It was a very thin IDE wrapper, and it used an existing skill that he had already been using in Cloud Code. And this is how
Speaker A
a lot of our Labs Bets start. It's one person, one weekend, one screen recording.
Speaker A
Someone gets something, hacks something together, and just shares what they did. So for us, 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
Speaker A
the stuff that doesn't work, totally broken, please go fix. 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
Speaker A
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 KR meetings. We did not have an H1 annual staffing plan. We did not have
Speaker A
a two-page year for what we were going to do over the next two years.
Speaker A
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. So who
Speaker A
here works off of PRDs, or has written one or worked off of one in the last month? Most of the room. Of those people that raised your hand, who would rather be working off of a prototype that worked and showed you the feature
Speaker A
fully? Exact same hands, which is pretty good. 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
Speaker A
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.
Speaker A
T
Speaker A
prototype 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
Speaker A
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
Speaker A
options for this. This has effectively replaced PRDs for me as a product manager that's been writing them for almost two decades now. Now I just do prototypes, this is my flow, it works pretty well. In labs, we do this ritual every once in
Speaker A
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
Speaker A
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
Speaker A
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. Somebody has an idea that you fork off of and you come up with something new on
Speaker A
your own. And by the second half of it, 100% of the pitches were prototypes or slides made with quad 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.
Speaker A
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
Speaker A
person. It's just one person with their good buddy Claude 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
Speaker A
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,
Speaker A
do not make it past this point. Most things we end up folding before they get here. And that's totally okay. This early exploration is usually hours or a few days for most things. Once we do have a promising spark, we usually scale the
Speaker A
team up massively, you know, 300%, all the way to three people. 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. If something
Speaker A
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
Speaker A
team that is smaller than 20 people? Okay, almost everybody, but not everybody. What about smaller than 10? Five? Smaller than three?
Speaker A
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,
Speaker A
what makes that possible? I'm sure this is also true of a lot of these solo builders in this room. Everyone on the team does everything, right?
Speaker A
The engineers talk to users, PMs write code, designers do data analysis. All of these things are enabled in part with Claude. And the lines between the roles on this team, they have essentially dissolved at this point. You do have your specialization, you do
Speaker A
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 10 users, you can realize what the underlying problem is, you can design a solution to it, you
Speaker A
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.
Speaker A
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
Speaker A
team together. Oftentimes, that's as easy as talking to the person on your left and the person on your right, and you're done. 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.
Speaker A
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
Speaker A
down these big, long cycles at the beginning of major milestones. 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.
Speaker A
So, our loop is our loop. This may not be the right loop for you.
Speaker A
That's not the message here. 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 again, we're just
Speaker A
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
Speaker A
could do for you a lot of times? Or why haven't you built your own tooling? Because every little bit of optimization that you do on your loop is going to pay you back if you're running it 50 to 100 times in a project.
Speaker A
So for a really simple example, I mentioned that we talk to users every day.
Speaker A
We want that to be the easiest thing in the world. We are people. We do things that are easy. We tend to do things that are hard less often.
Speaker A
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
Speaker A
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, because you and I
Speaker A
may be talking to different users today who may have the same suggestion we want.
Speaker A
Claude to tell us that if we don't talk. 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 put Claude
Speaker A
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 want to optimize it. Our
Speaker A
next thing on here was designing features. And luckily, we have a great product for that now. When we got started, we did not have the tool that we wanted for designing features. Our team, we would use quad code, we would build prototypes with
Speaker A
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, or you would just, you know, commit it into a sandbox and
Speaker A
let other people pull it down and try it. So we wanted to use Cloud Design to design Cloud Design, and so very quickly, Cloud Design got great at designing Cloud Design, which is fantastic. I have to say, if you could do any developer
Speaker A
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 Cloud Design today, from the way it explores code
Speaker A
bases, the way it links with GitHub, 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
Speaker A
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
Speaker A
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
Speaker A
product over to users, the very first request was, can I use this with the rest of the people on my team in real time? So we made a first class part of the product. The next thing that we've done in here is we
Speaker A
wanted to optimize how we ship code. So if you've used Cloud Design, you have probably used the handoff to Cloud 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
Speaker A
up our own workflow. When we started out, we would design our features, and then we would export all the files, and then we would import them into Cloud Code, and then we would retype all of the context that we had done over multiple
Speaker A
turns of conversation with Cloud Design so that Cloud Code would have all that context.
Speaker A
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,
Speaker A
how do I get this into production? So first was multiplayer, and then right after was, okay, now that I have the thing, I want to actually ship it. And so this was another spot where we just had too much friction. We're working for
Speaker A
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
Speaker A
a full-time job. But we still want to make sure that we don't miss anything.
Speaker A
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 want to miss them. It's too much for
Speaker A
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. It wasn't something that we were going to wait on. We needed to have this. And so right
Speaker A
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,
Speaker A
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,
Speaker A
and then we would have to come up with a suggestion after reading through all of that. So now we have Claude give us a suggestion on how to fix it. and then we found ourselves copying and pasting. And so we just made that
Speaker A
a button to bring it directly over to our development tooling. So not everything we built worked. Just because you're really fast doesn't mean you're always really right. And we got tons of things wrong as we were building the product. So I want
Speaker A
to tell you about one specific time where we got this wrong. And that was we started out early on and we built these really advanced controls.
Speaker A
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.
Speaker A
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. like, didn't just dislike them,
Speaker A
people hated them. They were confusing, they were actively harmful to the product. And so we ripped them out. For us, this took a grand total of one week. So, yes, we got off track, but from idea to course correcting and ripping out the
Speaker A
feature and going on to the next thing, took us about a week of time.
Speaker A
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 have been off track for an entire quarter. that would have been really bad for the product given that the
Speaker A
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
Speaker A
the run experiments bullet from earlier. So this taught us a couple things. 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
Speaker A
we want to be as open as possible because there will be users that we never meet the full needs of. There's going to be some power out user out there who wants to do something very specific that we're not going to support. And
Speaker A
that's what convinced us that we wanted 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 trying to do more and more integrations that you can take things directly into other
Speaker A
tools. We haven't talked about this publicly before, but I think this week or next week, we're going to be pushing out the ability for any design tool to integrate with Cloud Code. Sorry, Cloud Design. Just via their existing MCPs. So we
Speaker A
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
Speaker A
them. They're yours. So this slide's fun. On the left is that first prototype. It's a terminal in a browser, and that's about it.
Speaker A
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
Speaker A
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 99% of the value came from those ten weeks of iterating and shipping and talking to users every single day. The value came
Speaker A
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, Cloud Design shipped on a Friday,
Speaker A
and by the following Monday, we had shipped 62 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
Speaker A
it better at exploring code bases. 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
Speaker A
all-nighters from everybody. 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 10 weeks prior. This became a very quick, very normal way of working for
Speaker A
us. I mentioned earlier that quad design has now been live for one month. And so also you may have seen this, but last night we just doubled token limits for the product. So one of the pieces of feedback that we heard was that
Speaker A
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 want to share one of the more counterintuitive things we've learned working in labs. And that is that you do not
Speaker A
want to work on the thing that already works. You often want to 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 up.
Speaker A
And the next model may just fix the issues that you cannot solve via engineering.
Speaker A
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 4.7 coming out.
Speaker A
And that's going to be true of a lot of things that everyone in this room, that we all work on together. The model releases are a tide that lifts all boats. They do a lot for you. So remember, early on, you're just looking
Speaker A
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 want to start
Speaker A
exploring, start building, start bringing in front of users and figuring out the shape of the product that works. Because 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
Speaker A
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 going to write a PRD, skip it. Right? Don't write it. Instead, just talk with Claude, talk with somebody
Speaker A
on your team and take the transcript and 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
Speaker A
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
Speaker A
be a new analysis tool. And just build it one afternoon. Everyone waits on tools when, at this point, internal tooling, building your own stuff, is rapid. It's very fast. So go ahead and scratch your own itch. You will be happy that
Speaker A
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
Speaker A
request from a user and turn it around in 24 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
Speaker A
you do this, if you're not doing this already, you're going to find that there are a bunch of roadblocks in your existing process and the existing way that you build software if you've been on a longer timeline. That could be everything from the
Speaker A
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. So going through this once really helps. And I wouldn't try to do all three of these at once.
Speaker A
I would layer these on. 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. Who's going to try number one? A lot.
Speaker A
Two? Three? OK. 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 going to be by the demo booth for most of the day for Collade Design. It's down at
Speaker A
the end of the hallway. So please come find me. Tap me on my shoulder.
Speaker A
Come complain to me or tell me what surprised you. I'd love that. So thank you so much.
Topics:Claude DesignAnthropic LabsAI collaborationproduct developmentrapid iterationlean startupprototypingdesign toolsAI-enabled productsuser feedback
