"Garbage in, treasures out": Anthropic's Chief Designer discusses Cowork's product philosophy and the truth behind launching in 10 days

Compiled & Edited: Deep Tide TechFlow

Guest: Jenny Wen, Head of Cowork Design

Host: Peter Yang

Podcast source: Peter Yang

Original title: Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

Broadcast date: March 29, 2026

Key takeaways

Jenny is the Head of Design at Cowork. She walked me through the inner workings of Anthropic—how she uses Cowork to design and develop products, as well as the real story behind how Cowork came to be. Anthropic is rolling out new features almost every day, and watching how they work has really blown me away.

Highlights—summary of great perspectives

On how daily work is done

Most of what I spend my time doing is shipping the product. But I think it might look a little different from what it looked like one or two years ago. A big part of it is that, in a fairly informal way, it’s really about jamming (improvised collaboration) together with engineers, product people, and the like. Usually, everyone looks at a prototype together, then points things out and thinks through how it could evolve.

On the philosophy of “garbage in, treasure out”

One thing that really impresses me about Cowork is its ability to organize information. I like to call it “garbage in, treasure out.” It can gather information from all sorts of different sources, quickly find the key points within it, distill valuable content, and turn it into outcomes that are genuinely productive.

On the difference between Cowork and Claude Code

Besides very meticulous production code work, I now use Cowork to do almost everything else. If there’s a situation where I need to focus on certain code details, I still use Claude Code. But for everyday communication and collaboration, I now rely entirely on Cowork.

On the real story of Cowork’s origins

The line about “they built it in 10 days” was actually clipped from some interview or media report. But the real story is that, as for the direction of Cowork, we had already started thinking about it since I joined Anthropic a year ago. We’ve been thinking about how to build a “thinking partner” that helps all general knowledge workers.

Even though Claude Code can already handle code-related tasks really well, our goal is to cover all knowledge-work scenarios. And I think the real challenge is: how do we execute this idea? What kind of architecture is the most appropriate? And what kind of user experience (UX) is the right one?

On the evolution of the design process

I still do Figma. But we don’t do spec documents as often anymore, and usually they aren’t that detailed. We still do prioritization—it still exists as a document—but usually it’s just a few bullet points, not those overly designed, beautiful tables.

On planning and vision

The tech space we’re in changes extremely fast—new models keep coming out, and the update cadence keeps accelerating. So, for us, setting a one-year vision isn’t very realistic, let alone a two- to five-year vision, because there are just too many unknowns.

On the future for designers

If you feel like the ground under your feet is moving, it’s because it really is changing. We have to acknowledge that, learn to adapt, and also take an open-minded approach to re-examining how we do our existing work.

Whenever I feel challenged in my career—and during those times in particular—I think about my engineer colleagues. Their work has already gone through huge transformations, but they didn’t just adapt to those changes. They embraced the challenges with extraordinary courage and humility, and ultimately produced more efficient and better work outcomes. They’re my inspiration—I tell myself that if these colleagues I respect so much can do it, then I can too. They’re a model for me to adapt to change.

Opening

Peter Yang: Hi everyone. I’m really excited today to welcome Jenny, Head of Design at Anthropic. Jenny will show us how she uses Claude Cowork and Claude Code to design and launch products. She’ll also share Cowork’s internal story, and we might even discuss what comes next for her product.

Jenny, what does a typical day look like for you? Which tasks take up most of your time?

Jenny:

I don’t know if there’s such a thing as a typical typical day, but most of what I spend my time doing is shipping products. But I think it may look different from what it looked like one or two years ago. A big part of it is actually jamming—in a fairly informal way—with engineers and product people, and so on. Usually, everyone looks at a prototype together, then points out and thinks through how it could evolve. Sometimes it’s just discussing how the feature performs. Sometimes it’s me implementing some things myself. I still think a big portion of my time is me doing design, making prototypes, and the like—but the way design work is done now feels more loose.

Peter Yang: So basically you generate a bunch of prototypes with things like Claude, then you jam with the engineers, give feedback, and use prompts to have the AI improve it—right?

Jenny:

Actually, they often aren’t even prototypes. They’re more like working prototypes that we’ve already built internally and run through Claude or Cowork instances. I usually spend time using the feature, pushing the feature, seeing what it’s capable of, forming opinions about it. Then the next iteration is usually me sitting down with the engineers and saying: “Hey, this is what I’m thinking. These are the parts I think should change.” I still feel like there’s plenty of time for iterating, polishing, and refining within the design tools—very, very important—so that part hasn’t disappeared. It’s just that because I’m working on more projects at the same time, the way that feels most effective is to do it in a very casual, very non-formal manner.

Peter Yang: I think that’s always been the part I enjoy most as a product manager or designer—bringing designers and engineers together, watching the product iterate. So you’re not really doing those planning documents anymore, like spec documents or Figma files—right? Or are you just iterating prototypes directly in the code?

Jenny:

I still do Figma. But we don’t do spec documents as often anymore, and usually they’re not that detailed. Yes—we still do prioritization. It still exists as a document. Honestly, that helps us when we hand things off to the security or legal teams, so they can understand what’s being shipped. But usually it’s just a few bullet points—not those overly designed, pretty tables. I think our Figma files are similar, too.

Cowork hands-on demo

Peter Yang: Can you show us how you use these products, or what you use each of them for?

Jenny:

Sure. Let me talk about how I use Cowork. I actually have a little secret: besides very meticulous production code work, I now use Cowork to do almost everything else. If there’s a scenario where I need to focus on certain code details, I still use Claude Code. But for everyday communication and collaboration, I rely entirely on Cowork.

One thing that really impresses me about Cowork is its ability to organize information. I like to call it “garbage in, treasure out.” It can collect information from all sorts of different sources, then quickly find the key points, extract valuable content, and turn it into outcomes that are genuinely productive.

For example: right now I’m connected to a folder that contains some user interview notes. Our Cowork team is very focused on staying closely connected with users—which is also one of the key reasons for our success. We do traditional user experience research (UXR) and talk directly with users. At the same time, we also gather input through an internal, self-serve approach—for instance, we have a dedicated Slack channel used to collect feedback. In addition, we pay attention to discussions on social media and listen to what enthusiastic users are saying. It’s because we consistently stay close to users and can iterate on the product quickly that we’re able to keep improving and achieve the results we have today.

So what I would do now is tell Claude: “Hey, I have this interview folder.” But I’d also ask Claude to look at social media, Reddit, and other Cowork customer reviews, and tell me what the biggest insights are. It might take a bit of time because it’s really processing all that data and working it over—but it will do things like, sometimes it may dispatch sub-agents to process in parallel, and it will also spend time searching online.

Peter Yang: In your day-to-day work, do you have something like a weekly insights report—where it automatically aggregates everything and sends it to you and the team?

Jenny:

Actually, we can do that directly with Cowork. I think our researchers have one that gets sent out, and we also have one that pings us in Slack. We also directly listen to internal Slack channels. We rely a lot on internal—and on the strongest—users to give us that kind of cutting-edge feedback, because internal people are truly willing to be honest with you. They tend to push features to the limit, and they’re also the easiest group to follow up with.

Peter Yang: I think that’s exactly what should happen—and I feel like most companies have teams that are too siloed, but Anthropic doesn’t seem to be like that at all.

Jenny:

I think that’s also an important part of Claude Code’s success—listening to frontline users. And that’s something we did a lot when we were using Figma, through lots of internal dogfooding. Because especially when it comes to interaction design and fine-tuning, internal people will really poke at the details. External users often give feedback that’s more about whether it fits their user flows—so it provides a completely different level of feedback.

Cowork vs Claude Code: user boundary

Peter Yang: I know that Anthropic’s marketing, product managers, and so on are basically using Claude Code now—especially after it became available internally within Cowork. What do you think about different types of use cases? Or how do people use Cowork and Claude Code?

Jenny:

We’ve noticed Cowork’s overall application scope is gradually expanding, and it’s starting to be used in some scenarios that were the kind of frontier cases earlier Claude Code users had been trying. Remember when we first started developing Cowork? At the time, the internal sales team was our primary source of information. Some of them were power users of Claude Code, using it to generate lead lists, write call scripts, and so on. When I first saw those use cases, I was genuinely surprised, because I hadn’t even considered that Claude Code could be used to accomplish those tasks. But now, those users have almost fully moved over to Cowork, and even their colleagues have started using Cowork frequently.

That’s because it has a nice UI, so I think that’s what it really needed. And part of the reason is that it’s very close to the other work they’re already doing. They were already using chat features, and from this desktop app they can keep using Claude Code. So it feels more aligned with their existing workflow than opening the command line.

On turning insights into executable artifacts—end-to-end

Jenny:

Here there are seven different themes, and each week it’s different. I can basically tell it: “Help me create document X,” and it’s already automatically sitting in a folder on my computer. I can also start two parallel tasks at the same time. For example, I can say: “These insights are great, but based on them, what product features should I actually build?” Then I can do another parallel task: “Based on the insights document you just helped me make, turn this into a slide deck I can share with the team during this week’s kickoff.”

But ultimately, from here I can start designing the workflow—it will give me all kinds of feature options. From there, I can even have Claude help me create some wireframes for these features. It might give me a bunch of different options. I can bring them into Figma to truly refine them, or I can bring them into Claude Code and use our actual design system components to turn them into real things—then from there, we go on.

Additionally, I can also turn both of these into scheduled tasks. So I’d probably have it set up the task to run automatically every Monday at 10 a.m. That way, every Monday at 10 a.m., I start work with this slide deck and with three or four different product ideas to kick off the week. It compresses the iteration cycle—from feedback to creating tangible things or ideas the team can see—so we can iterate on the product quickly and also make it better quickly.

Peter Yang: It’s all about iteration—everything is about iteration. I’ve gotten a bit lazy too: I always let AI do the first version, and then I react.

Jenny:

Yes. So if you really want me to start from scratch and organize these insights into some kind of feature priority, it would take much longer than before.

That’s what I do too. For example, if you send me these podcast notes, I have a personal notes folder that contains 1:1 meeting notes and random thoughts and things like that. Then I’ll just say: “Read my personal notes. Help me come up with the talking points for this podcast, and help me figure out what I want to say here.” Of course, I won’t read it verbatim word-for-word, but it really helps open up my thinking. It helps me evolve my thinking, rather than getting stuck.

Skills and personal knowledge base

Peter Yang: What skills do you use? Or do you have personal, dedicated skills to create these documents and slide decks?

Jenny:

We have a few skills internally that are specifically used to create documents and slide decks, because they help us maintain brand consistency. I don’t really have a personal skill library. Most of the time I just borrow internal skills and apply them to different use cases.

Peter Yang: For example, I have a writing skill—it tells the AI not to use those AI slop phrases.

Jenny:

But actually, I’ve found that using Cowork’s folders—where I store all my personal notes and so on—understands me through those folders, and that’s already been extremely useful for me. I actually feel like I’m needing memory and skills less and less, because it already has a knowledge base about me. Of course, I still think skills have their place, but for my current use cases, I personally feel the need is smaller.

Peter Yang: Is it because it updates your memory automatically based on your conversations every day?

Jenny:

Yes. Basically, it’s a memory that I maintain myself, because I’ve been taking notes in it the whole time.

Team collaboration nodes

Peter Yang: So in the whole process, when do you bring the team in? Or do you iterate with the AI and then switch back and forth to iterate with the team, and so on?

Jenny:

My point is that for things like real UXR interviews, I don’t do those myself. It’s either the product manager, or researchers on the team, or other people on the team who do them. Then, through that, you share the artifact directly with them, and you pull them in—because that actually becomes the basis for how the team operates.

At least in our team, we’re quite bottom-up and democratic. Our way of operating is: we share insights and goals with everyone, and then each person goes and builds prototypes, tries things out—ideas coming from all directions. It’s not that I, as a designer, come up with all the solutions. It’s more like: “Hey, here are the insights. This is the goal we’re all going to work toward this month. How do we get there together?”

And I think with this, we still don’t just hand everything over to Claude to do. We still rely on ourselves to make many of the judgments, and we manage and decide what we’re truly going to build and what we’re going to do.

Peter Yang: When people talk online about taste and judgment, I feel like the way those abilities are cultivated is through consistently gathering a large amount of product feedback from both inside and outside the company. Over time, you develop an intuition for noticing what’s going wrong and what needs fixing. Since you’re listening and processing feedback every day, over the long run you build a sharp sense for diagnosing problems.

Jenny:

As for design, one of Claude’s capabilities is generating sketches like wireframes and providing multiple design options. As a designer, I really like this approach. Even if the fidelity of the sketches isn’t super high, they allow me to visually and intuitively see different possibilities without having to rely entirely on my own imagination. This helps me decide on the next design direction faster.

So I think generating these initial options directly with Claude saves me time and effort in making sketches manually. From those options, I choose one direction and start iterating within a small scope. Next, I might use code to build a preliminary prototype for that direction, and then on top of that continue optimizing and refining the design.

The real story behind Cowork’s creation

Peter Yang: Let’s talk about how Cowork came about. There are lots of stories out there saying it was built in 10 days, but before that, there must have been a lot of iteration already, right?

Jenny:

That line about “they built it in 10 days” was really clipped from some interview or media coverage, and people kept discussing it around that point. But the real situation is that the direction of Cowork had already been something we were thinking about since I joined Anthropic a year ago. We’ve been thinking about how to build a “thinking partner” that can help all general knowledge workers. Even though Claude Code could already handle code-related tasks well, our goal was to cover all knowledge-work scenarios. And I think the real challenge was: how do we execute this idea? What kind of architecture is the right one? And what kind of UX is the right one?

Over the past year, we tried a lot of different prototype concepts. Some of the ideas were even more ambitious than what our current target is. We also ran many technical experiments, testing different AI agent frameworks, but some of those attempts didn’t work out. Only eventually did we gradually settle on the direction we have now. We didn’t just look at prototypes built by the lab teams—we also studied prototypes our own product team built. In the end, timing and execution became the key, like lightning striking the target just right.

When we decided to ship this product, the whole process was very fast—from “we should ship it” to “the product is live”—it took only 10 days. This was mainly because during the Claude Code holiday break, we saw its potential. During the break, many people finally had time to try Claude Code, and even some non-technical users started using it—for example, parsing podcast transcripts, or doing more complex data analysis. We found that Claude Code’s agent framework was showing early product-market fit even among non-technical users. In fact, we already had an internal working prototype, which was originally planned to be released a bit later, but the feedback made us realize: “Now is the best time.” So we decided to seize this opportunity, and that’s how we ended up with that crazy 10-day sprint.

Peter Yang: If I understood correctly, during the past year you shared many prototypes internally in Slack, collected a lot of feedback, and then landed on a viable prototype. Then, because you saw demand from the market for it, you pushed it through quickly with a sprint and shipped the product.

Jenny:

Yes, pretty much. We had planned to launch in a few more weeks, but at that time we felt like “now is the best time.” That also led us, despite having a tight timeline, to narrow the product scope down to something more realistic and achievable, and to throw all our effort and resources into shipping. And ultimately, we succeeded.

Early design iteration: from workflow tooling to a minimal chat

Peter Yang: Can you share some experiences from early iteration, or show what you were working on at the time?

Jenny:

Sure. I specifically pulled together some early screenshot examples, which can show our design thinking and the iteration process.

Earlier this year, we had an early prototype that I built together with another designer. At the time, we tried to make the tool more task-oriented or workflow-oriented. We were really worried about whether users would be able to understand how to use Cowork, and whether they could complete certain specific tasks or achieve clear outcomes—like creating a dashboard, or consolidating data from different sources. So at the time, we designed the user interface to be very structured—almost like a workflow tool. For example: “add these contents—this is the inputs, this is the outputs.” And the chat function was placed in a secondary position.

But it felt like it took too many steps to get things done. In the 2025 era, why should we make it so complicated? Why not just let Claude handle it?

That was one early direction for the design. But later, we decided to change course and make it simpler—like a chat box. We tried to guide users to achieve more specific goals through this approach, such as analysis or document generation. We also designed a functional prototype: after the user clicks, they can see various options, and each option has buttons to adjust things—for example, the length of the document, or choosing the type of document, like a memo or a slide deck. But in the end, that design made users feel it was too complex and overwhelming.

So through multiple explorations and attempts, we kept trying to find a balance: should we define the usage scenarios more explicitly, or should we keep it more open-form like a chat box?

The version we released a few weeks ago is basically what it looks like now. We had tried a user experience that was almost like a “wizard-like” mode, where after clicking, users would see prompts like “create a document, length three to five pages,” and so on.

At the time, we also added a lot of elements into the interface, hoping it would look different from a normal chat box. But we found that this design made the interface overly complex, with too much competition between visual elements. So we decided to simplify the design and remove most of the unnecessary elements.

The user interface you see now has been greatly simplified. We removed heavy sidebars to make it closer to a traditional chat box, but we made some changes on the home page so it looks more like a “to-do list” that I share with Claude, rather than a chat tool filled with complex suggestions and guidance.

Peter Yang: Maybe in the future it can support multiple agents, and you can drag tasks around on it to manage workflows.

Jenny:

Maybe there’s a possibility for that in the future. But I want to emphasize that the UI design was completely different about four or five weeks ago. We’ve been learning and exploring what kind of design is most effective, what kind isn’t, and we’ve been trying to find the best way to present this technology to users.

Positioning the difference between Cowork and Claude Code

Peter Yang: When using Claude Code, I often share some feedback on Twitter. It has lots of slash commands built in, and users have to learn them bit by bit. That experience is a bit like a “treasure hunt” at Costco—you never know what new features you’ll find.

But for beginners, this isn’t particularly friendly. It feels more like a game—over time, as you use it more, you gradually get familiar with it and master it. I feel like Cowork might be trying to explore the middle ground between a normal chat tool and Claude Code. It doesn’t hide all the functionality, and yet it can guide users to use it better in some way.

Jenny:

Yes. Cowork still supports slash commands, but they’re not the primary interaction method. Personally, I think Cowork is at least a tool aimed at professionals. We’ve observed that many users are already using it in very advanced ways, and some power users have emerged in the community. These users are typically willing to spend time learning more complex functionality—like creating skills on their own, sharing with the team, or using shorthand commands.

However, our goal is for these features to be a secondary way of interacting, not forced learning content. In other words, even if users don’t know all the commands, they can still use Cowork easily. We want users’ interaction with Claude to be natural and intuitive, rather than having to complete tasks by memorizing a whole list of commands.

Planning process and vision

Peter Yang: What does Anthropic’s planning process look like? Do you do annual planning and set goals? Or do you rely more on prototype development and continuous experimentation?

Jenny:

Our planning approach varies each time. In the team I’m on, we do monthly planning. We have a spreadsheet that—at least for the Cowork portion—lists up to about 12 tasks, which are our top priorities (P0). Each task has a direct owner (DRI). Every week we check: are we still on the right track? We also do some quarterly or half-year planning, usually led by someone pointing out: “I think we should move in this direction; these are the things we need to focus on.” But these plans aren’t strict in the sense that we must execute specific projects. It’s more about giving the team an overall direction, so it’s relatively flexible.

Peter Yang: Relatively flexible, right? What’s interesting is that I’ve found the most innovative companies tend to do less annual planning and more through continuous iteration and learning from users. Have you done anything similar to a North Star vision deck in your career? Do you think those are useful?

Jenny:

I have, actually. Last year I made a North Star vision deck. I think vision definitely has value—it gives teams direction and helps keep clarity about the work ahead. But because the technical landscape changes extremely fast, new models keep emerging, and the update cadence keeps accelerating, for us it’s not very realistic to set a one-year vision, let alone a two- to five-year vision, because there are too many unknown factors.

However, the real purpose of a vision is to guide everyone in the same direction—especially in an environment where everyone can freely build all sorts of projects. So I currently think the time horizon for a vision should be at most three to six months, and it can be presented as a document. I think when a vision is visualized, it has more impact. That’s also the huge value of design—being able to integrate all kinds of elements and tell a coherent story over a specific period of time. Of course, a vision doesn’t have to be only a static deck. It can also be a prototype. It can help coordinate work across teams, especially when we have five teams working on very similar—or potentially conflicting—projects. Design can help align these ideas through curation, and show us a path toward an ideal user experience, rather than scattering experiences everywhere.

Peter Yang: So do you have product manager reviews, or reviews for the relevant people? Are these reviews formal, or do they also participate in prototyping?

Jenny:

We do have reviews, but not like in some companies where every feature has to go through a review. Our reviews are mainly for bigger, higher-priority projects. The purpose isn’t to spend a lot of time preparing—it’s to increase the visibility of a project and get feedback. If there are cross-team, important projects that affect the company, we do these reviews.

Advice for designers: how to find your place in the AI era

Peter Yang: So for designers who feel that their professional environment is changing quickly, what advice do you have? Should they start learning how to submit code (PR)? Or should designers adapt in other ways?

Jenny:

If you feel like the ground under your feet is moving, it’s because it really is changing. We have to acknowledge that and learn to adapt, and at the same time take an open-minded approach to re-examining how we do our current work. I think these changes are especially impacting designers right now, because we’re in the second wave of this wave. Other professional roles have gone through similar transformations, and now it’s our turn. At the same time, our design tools are also evolving.

Whenever I feel my career is being challenged, I’ll feel a bit uneasy—like, “Oh my God, my work is changing dramatically, and people might not value it the way they used to.” But when that happens, I think about my engineer colleagues. Their work has already undergone huge changes, but they didn’t just adapt—they met the challenges with extraordinary courage and humility, and ultimately delivered more efficient and better work outcomes. They’re my inspiration—I tell myself that if these colleagues I respect so much can do it, then I can too. They’re my example for adapting to change.

Peter Yang: In a way, these changes free designers from a lot of tedious repetitive work—like not having to spend time adjusting all kinds of boxes anymore, right? That way, you can put more focus into higher-level thinking and creative work.

Jenny:

Yes. Or I would say these changes let us get more done. For example, when I see that my engineer colleagues can complete a full feature in just a few days—whereas before it might have taken weeks—I’m genuinely blown away. So yes, these changes also create more possibilities.