Organized & Compiled: Deep Chao TechFlow
Guest: Jenny Wen, Cowork Design Lead
Host: Peter Yang
Podcast Source: Peter Yang
Original Title: Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen
Release Date: March 29, 2026
Key Points Summary
Jenny is the design lead for Cowork. She gave me an in-depth look into Anthropic's internal operations, including how she uses Cowork to design and develop products, and the real story behind the birth of Cowork. Anthropic is releasing new features almost every day, and seeing how they work is truly astonishing to me.
Highlights Summary
About Daily Work Style
- Most of what I spend my time doing is getting the product out there. But I think it might look different than it did a year or two ago; a big part of it is just jamming (improvising collaboratively) in a very informal way with engineers, product people, and the like. Usually, it's everyone looking at a prototype together, then pointing things out and thinking about how it can evolve.
About the "Garbage In, Treasure Out" Usage Philosophy
- I think the thing that amazes me most about Cowork is its ability to organize information. I like to call it "Garbage In, Treasure Out." It can gather information from various sources, quickly find the key points, extract valuable content, and turn it into something tangibly productive.
About the Difference Between Cowork and Claude Code
- Apart from very detailed production code work, I now use Cowork for almost everything. For scenarios that require focusing on specific code details, I still use Claude Code. But for daily communication and collaboration, I now rely entirely on Cowork.
About the Birth Story of Cowork
- That saying "they built it in 10 days" was actually taken out of context from some interview or media report. But the real situation is, we had been brainstorming this direction for Cowork since I joined Anthropic a year ago; we were always thinking about how to build a "thinking partner" that could help all general knowledge workers.
- Although Claude Code was very good at handling code-related tasks, our goal was to cover all knowledge work scenarios. I think the real challenge was: How should we execute this idea? What architecture is most suitable? What is the right user experience (UX)?
About the Evolution of the Design Process
- I still use Figma. But we don't do spec documents as often now, and they are usually not that detailed. We still do prioritization; it still exists as a document, but usually it's just a few bullet points, not some overly designed, beautiful table.
About Planning and Vision
- The technology field we are in changes extremely fast, with new models constantly emerging and the pace of updates getting faster. Therefore, for us, even a one-year vision is somewhat unrealistic, let alone a two-to-five-year vision, because there are too many unknowns.
About the Future of Designers
- If you feel the ground moving under your feet, it's because it is. We have to acknowledge that and learn to adapt, while also re-examining our existing ways of working with an open mind.
- Whenever I feel my profession is being challenged, I think of my engineering colleagues. Their work has already undergone huge transformations, but they not only adapted to these changes but also met the challenges with great courage and humility, ultimately achieving more efficient and better work results. They are my source of inspiration—I tell myself, if these colleagues I highly respect can do it, so can I. They are my role models for adapting to change.
Opening
Peter Yang: Hello everyone, today I am very excited to welcome Jenny, the design lead at Anthropic. Jenny will show us how she uses Claude Cowork and Claude Code to design and release products, while also sharing the internal story of Cowork, and perhaps talking about the next steps for her product.
Jenny, what does a typical day look like for you at work? What tasks take up most of your time?
Jenny:
I don't know if there is a typical typical day, but most of what I spend my time doing is getting the product out there. But I think it might look different than it did a year or two ago; a big part of it is just jamming (improvising collaboratively) in a very informal way with engineers, product people, and the like. Usually, it's everyone looking at a prototype together, then pointing things out and thinking about how it can evolve. Sometimes it's just discussing how a feature performs, sometimes it's me implementing something myself. I think there's still a significant portion of time where I'm designing, prototyping, etc., myself, but the way design work is done now feels much looser.
Peter Yang: Basically, you generate a bunch of prototypes through Claude or something, then just jam with the engineers, give some feedback, and use prompts to have the AI improve it, right?
Jenny:
Actually, they aren't even prototypes often; they are working prototypes already built internally and running in our Claude or Cowork instances. I usually spend time using the feature, pushing the feature, seeing its capabilities, forming opinions, and the next iteration is usually me sitting down with an engineer and saying: Hey, here's what I think. These are the areas I think should change. I think there is still time where I feel iterating, polishing, and refining within design tools is still very, very important. So that part hasn't disappeared. It's just because I'm handling more projects simultaneously, so the more effective way feels very casual, very informal.
Peter Yang: I think that has always been the part I enjoyed most as a product manager or designer, pulling designers and engineers together and watching the product iterate together. So do you do less of that spec document, Figma file, planning document stuff now? Or do you just iterate on prototypes directly in code?
Jenny:
I still use Figma. But we don't do spec documents as often now, and they are usually not that detailed. Yes. We still do prioritization; it still exists as a document. Actually, it's very helpful for handing things over to security or legal teams so they understand what's being released, but usually it's just a few bullet points. Not some overly designed, beautiful beautiful table. I think our Figma files are the same.
Cowork Hands-On Demo
Peter Yang: Can you show us how you use these products, or what you use each product for respectively?
Jenny:
Sure. Let me talk about how I use Cowork. I actually have a little secret: apart from very detailed production code work, I now use Cowork for almost everything. For scenarios that require focusing on specific code details, I still use Claude Code. But for daily communication and collaboration, I now rely entirely on Cowork.
I think the thing that amazes me most about Cowork is its ability to organize information. I like to call it "Garbage In, Treasure Out." It can gather information from various sources, quickly find the key points, extract valuable content, and turn it into something tangibly productive.
For example, right now I have a folder connected that contains some user interview transcripts. Our Cowork team places great emphasis on staying closely connected with users, which is also one of the keys to our success. We do traditional user experience research (UXR), talking directly to users, and also through internal dogfooding, like we have a dedicated Slack channel for collecting feedback. Additionally, we pay attention to discussions on social media and listen to feedback from passionate users. It's because we always maintain close contact with users and can iterate quickly that we can continuously improve and achieve the results we have today.
So what I do now is, I'll tell Claude: Hey, I have this interview folder, but I'll also have Claude check social media, Reddit, and other Cowork customer reviews, and tell me what the biggest insights are. It might take a little time because it really has to process that much data and work on it. But it will do things like sometimes spawn sub-agents to process in parallel, and it will spend time searching the web.
Peter Yang: In your actual work, do you have things like weekly insight reports or something that automatically summarizes everything and sends it to you and the team?
Jenny:
Actually, we can do that directly through Cowork now. I think one of our researchers has one that gets sent out, and we also have a version that pings us in Slack. We also listen directly to internal Slack channels; we rely heavily on internal and our most power users to give us that cutting-edge feedback because internal people are really willing to be honest with you, they often push features to the limit, and they are also the easiest to follow up with.
Peter Yang: I think that's how it should happen, and I feel like in most companies teams are too siloed, but Anthropic doesn't feel like that at all.
Jenny:
I think this is also a big part of Claude Code's success—listening to the frontline users. And it's also something we did a lot at Figma, a lot of internal dogfooding. Because especially when it comes to interaction design and polishing those details, internal people will really poke at those details, while external users often give feedback more like "does it fit their user flow," so it provides a completely different level of feedback.
User Boundaries: Cowork vs Claude Code
Peter Yang: I know that marketing, product managers at Anthropic are now basically using Claude Code to do things, especially since Cowork became available internally. How do you view the different types of usage scenarios? Or how do people use Cowork and Claude Code?
Jenny:
We've noticed that Cowork's overall application is gradually expanding and is starting to be used in some scenarios similar to what the early power users of Claude Code were trying. Remember when we first started developing Cowork, the internal sales team was a major source of information for us. A few of them were heavy users of Claude Code, using it to generate lead lists, write call scripts, etc. When I first saw these use cases, I was very surprised because I hadn't even thought Claude Code could be used for these tasks at the time. And now, these users have almost completely switched to Cowork, and even their colleagues have started using Cowork frequently.
It's because there's a nice UI now, so I think that's all it really needed. And part of it is also that it's very close to the other work they're doing—they were already using the chat feature, and they can continue using Claude Code from this desktop app, so I think it fits their existing workflow better than opening a command line.
Full Process from Insights to Executable Artifacts
Jenny:
Here there are seven different themes, and they are different every week. I can basically just tell it: Help me create this document X, and it's already automatically saved in a folder on my computer. I can also launch two parallel tasks simultaneously. For example, I can say: These insights are great, but based on these, what product features should I actually build? Then I can do another thing in parallel—based on the insight document you just helped me with, turn this content into a presentation I can share with the team at the kickoff this week.
But from here I can even start the design process—it will give me various 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 take them into Figma to really refine them, or take them into Claude Code to make them into real things using our actual design system components, and start from there.
Also what I can do is, set both of these up as scheduled tasks. So I would probably have it help me schedule this task to run automatically every Monday at 10 AM. So every Monday at 10 AM I would start the week with this presentation, with three or four different product ideas, to kick off the week. It compresses the iteration cycle from feedback to tangible things or ideas the team can see very tightly, helping us iterate on the product quickly and make it better fast.
Peter Yang: Everything is about iteration, everything is about iteration. I've gotten lazy now too, I always let the AI do the first version, then I react to it.
Jenny:
Yes. So if you really want me to organize these insights into some kind of feature prioritization from scratch, it would take much longer now than before.
I operate the same way. For example, with these podcast notes you sent me, I have a personal notes folder with 1:1 meeting contents, random thoughts, etc., and I just say: Read my personal notes, help me think of the talking points for this podcast, and help me think about what I want to say here. Of course I won't read it verbatim, but it really helps me open up my thinking, helps me evolve my thoughts, rather than getting stuck.
Skills & Personal Knowledge Base
Peter Yang: What skills do you use? Or do you have personal dedicated skills for making these documents and slides?
Jenny:
We have a few internal skills specifically for making documents and slides because it helps us keep brand consistency. I don't really have a personal skill library; most of the time I borrow existing internal skills and use them for different purposes.
Peter Yang: For example, I have a writing skill that tells the AI not to use those AI slop words.
Jenny:
But actually I find that now, using Cowork's folders—I have all my personal notes, etc., in there—the way it understands me through these folders is already very useful for me. I feel less and less need for memory and skills instead. Of course I still think skills have their applicable scenarios, but for my current use cases, I personally feel the need isn't that great.
Peter Yang: Is it because it automatically updates its memory based on your conversations every day?
Jenny:
Yes, it's basically a memory I maintain myself because I'm always taking notes in it.
Team Collaboration Nodes
Peter Yang: So at what point in the whole process do you bring the team in? Or do you iterate with the AI and then switch back and forth iterating with the team, or how does that work?
Jenny:
I mean, things like actual UXR interviews, that's something I wouldn't do myself—either the product manager, or a researcher on the team, or someone else on the team will do it. And then through this, you just share the artifact, pull them in, and this can become the basis for how the team operates.
Our team, at least, is quite bottom-up and democratic, so how we operate is, we give the insights and goals to everyone, and then everyone goes off and makes prototypes, tries things, ideas come from everywhere. It's not me as the designer coming up with all the solutions, but "Hey, here are the insights. This is the goal we're trying to achieve this month, how do we all get there together?"
I think with this, we still don't hand everything over to Claude to do. We still rely on ourselves to do a lot of the judgment, and our ability to manage and decide what to actually build and do.
Peter Yang: When people talk about taste and judgment online, I think the way these abilities are cultivated is actually by continuously getting a lot of product feedback from both inside and outside. In this process, you gradually develop an intuition, an ability to detect where things are wrong and need fixing. Because you are listening to and processing this feedback every day, over time, you develop a keen judgment for problems.
Jenny:
As for design, one feature of Claude is that it can generate wireframe-like sketches and provide multiple design options. As a designer, I really like this approach. Even if these sketches aren't very high-fidelity, they allow me to visually see different possibilities without having to rely entirely on my own imagination. This approach helps me decide on the next design direction faster.
So, I think having Claude directly generate these initial options can save me the time and effort of manually creating sketches. From these options, I will choose a direction and start iterating on a small scale. Next, I might code this direction into a preliminary prototype, and then continue optimizing and refining the design based on that.
The True Story of Cowork's Birth
Peter Yang: Let's talk about how Cowork was born. There are many stories online about it being built in 10 days, but there must have been a lot of iteration before that, right?
Jenny:
That saying "they built it in 10 days" was actually taken out of context from some interview or media report, and people just kept discussing that point. But the real situation is, we had been brainstorming this direction for Cowork since I joined Anthropic a year ago; we were always thinking about how to build a "thinking partner" that could help all general knowledge workers. Although Claude Code was very good at handling code-related tasks, our goal was to cover all knowledge work scenarios. I think the real challenge was: How should we execute this idea? What architecture is most suitable? What is the right user experience (UX)?
Over the past year, we tried many different prototype designs, some ideas were even more ambitious than the current goal. We also conducted many technical experiments, testing various AI agent frameworks, but some of these attempts were not successful. Eventually, we gradually settled on the current direction. We referenced prototypes developed by the lab team, and also studied prototypes built by our own product team. In the end, timing and execution became key, like lightning striking the target.
When we decided to release this product, the whole process was very fast—from "we should release" to "the product is live," it only took 10 days. This was mainly because we saw its potential during the Claude Code holidays. During the holidays, many people finally had time to try Claude Code, and even some non-technical users started using it, like using it to parse podcast transcripts or perform complex data analysis. We found that Claude Code's agent framework was starting to show early product-market fit even among non-technical users. Actually, we already had a working prototype internally, originally planned for release a bit later, but this feedback made us realize "now is the best time." So, we decided to seize this opportunity, which led to those crazy 10 days.
Peter Yang: If I understand correctly, over the past year you shared many prototypes internally on Slack, collected a lot of feedback, and finally settled on a viable prototype. Then, because you saw market demand for it, you did a quick sprint and launched the product.
Jenny:
That's right, that's roughly it. We originally planned to launch in a few more weeks, but at that time we felt "now is the best time." This also prompted us, under time pressure, to narrow the product's scope to a more realistically feasible level, and we invested all our energy and resources, ultimately succeeding in the launch.
Early Design Iteration: From Workflow Tool to Minimalist Chat
Peter Yang: Can you share some experiences about the early iterations, or show some things that were in development?
Jenny:
Sure. I specifically gathered some early screenshots to show our design thinking and iteration process at the time.
Earlier this year, we had an early prototype, which I collaborated on with another designer. At that time, we tried to make the tool more task-oriented or workflow-oriented. Because we were worried about whether users would understand, using a product like Cowork, whether they could complete certain specific tasks, or achieve some clear outcomes, like creating a dashboard, or integrating data from different sources. So, at that time, we designed the user interface very structured, almost like a workflow tool—like "add these contents, these are inputs, these are outputs." And the chat function was placed in a secondary position.
But it felt like it took many steps to complete. In this era of 2025, why are we still making it so complicated? Why not just let Claude handle it?
This was an early design direction for us, but later we decided to change our approach, make it simpler, like a chat box. We tried to guide users towards more specific goals this way, like analysis or document generation. We also designed a functional prototype—users click and see various options, each with buttons to adjust, like the length of the document, or choose the document type, like a memo or presentation, but this design ultimately made users feel too complex and oppressive.
So through multiple explorations and attempts, we were always trying to find a balance: should we define the usage scenarios more explicitly, or maintain a free-form style like a chat box.
Eventually, the version we released a few weeks ago is what it is now. We had tried an almost "wizard-like" user experience, where users would click and see prompts, like "create a document, three to five pages long," etc.
At that time, we also added many elements to the interface, hoping to make it look different from a normal chat box. But later we found that this design made the interface seem too complex, with too much visual competition. So, we decided to simplify the design and removed most of the unnecessary elements.
The user interface you see now has been greatly simplified. We removed heavy sidebars, made it closer to a traditional chat box, but made some changes on the homepage to make it look more like a "to-do list" shared by me and Claude, rather than a chat tool full of complex suggestions and guidance.
Peter Yang: Maybe in the future it could support multiple agents, and you could drag tasks on it to manage workflows.
Jenny:
Maybe that's a possibility in the future. But I want to emphasize, the UI was completely different about four or five weeks ago; we have been constantly learning, exploring what design works best, what doesn't work so well, while trying to find the best way to present this technology to users.
Differentiation Positioning of Cowork and Claude Code
Peter Yang: While using Claude Code, I often share some feedback on Twitter. It has many slash commands built-in, requiring users to learn them bit by bit. This experience is a bit like a "treasure hunt" at Costco; you never know what new feature you'll discover.
But for newcomers, this approach isn't very friendly. It's more like a game; as you use it more, you gradually become familiar and master it. I feel Cowork might be trying to explore a middle ground between ordinary chat tools and Claude Code. It doesn't hide all the features, while also being able to guide users to use it better in some way.
Jenny:
Yes. Cowork still supports using slash commands, but they are not the primary interaction method. I personally feel that Cowork is at least a tool for professionals. We've observed that many users are already using it in very power-user ways, and a community of power users has emerged. These users are usually willing to spend time learning more complex functions, like creating their own skills, sharing with teams, or using shorthand commands.
However, our goal is to make these functions secondary interaction methods, not mandatory learning. That is, even if users don't know all the commands, they can still use Cowork easily. We want the interaction between users and Claude to be natural and intuitive, not something that must be done by remembering a series of commands.
Planning Process and Vision
Peter Yang: What is Anthropic's planning process like? Do you do annual planning and goal setting? Or do you rely more on prototyping and constant experimentation?
Jenny:
Our planning method is different each time. On my team, we do monthly planning. We have a spreadsheet, at least for the Cowork part, listing up to about 12 tasks, which are our highest priorities (P0). Each task has a directly responsible individual (DRI), and we check weekly: Are we still on the right track? We also do some quarterly or half-year planning, usually where a lead points out: "I think we should move in this direction, these are the things we need to focus on." But these plans aren't strict to the point of having to execute specific projects. It's more about providing an overall direction for the team, so it's relatively flexible.
Peter Yang: Relatively flexible, right? It's interesting, I find the most innovative companies often do less annual planning and instead rely more on constant iteration and learning from users. In your career, have you ever done something like a North Star vision deck? Do you find those useful?
Jenny:
I have done one, I did a North Star vision deck last year. I think vision does have its value; it points the team in a direction and helps keep us clear about the work ahead. However, because the technology field we are in changes so rapidly, with new models constantly emerging and the update pace getting faster, for us, even a one-year vision is somewhat unrealistic, let alone a two-to-five-year vision, because there are too many unknown factors.
However, the real role of a vision is to guide everyone in the same direction, especially in an environment where everyone can freely build various projects. So I now think the time horizon for a vision is at most three to six months, and it can be presented as a document. I feel when a vision is visual, it's more impactful. This is also the huge value of design—being able to integrate various elements and tell a coherent story over a specific period. Of course, a vision can also be a prototype, not just a static deck. It can help us coordinate work between teams, especially when we have five teams working on very similar or potentially conflicting projects. Design can help these ideas align through curation and show us a path towards an ideal user experience, rather than a fragmented experience.
Peter Yang: So, do you have product manager reviews, or reviews for relevant people? Are these reviews formal, or do they also participate in prototyping?
Jenny:
We do have reviews, but not like at some companies I've been at where every feature needs a review. Our reviews are mainly for those larger, higher-priority projects. The purpose of the review is not to spend a lot of time preparing, but to increase project visibility and get feedback. If there are cross-team, company-impacting important projects, we will do these reviews.
Advice for Designers: How to Find Your Place in the AI Era
Peter Yang: So, for those designers who feel their professional environment is changing rapidly, what advice do you have? Should they start learning to submit PRs (Pull Requests)? Or should designers adopt other ways to adapt?
Jenny:
If you feel the ground moving under your feet, it's because it is. We have to acknowledge that and learn to adapt, while also re-examining our existing ways of working with an open mind. I think the impact on designers is particularly significant right now, especially because we are in the second wave of this trend. Some other professional roles have already undergone similar transformations, and now it's our turn. At the same time, our design tools are also constantly evolving.
Whenever I feel my profession is being challenged, I feel a bit uneasy, like "Oh my god, my job is changing so much, people might not value my work as they used to." But at such times, I think of my engineering colleagues. Their work has already undergone huge transformations, but they not only adapted to these changes but also met the challenges with great courage and humility, ultimately achieving more efficient and better work results. They are my source of inspiration—I tell myself, if these colleagues I highly respect can do it, so can I. They are my role models for adapting to change.
Peter Yang: In a way, these changes free designers from a lot of tedious repetitive labor, like not having to spend time adjusting various boxes, right? So you can put more energy into higher-level thinking and creative work.
Jenny:
Exactly, or these changes allow us to complete more work. For example, when I see my engineering colleagues can now complete a full feature in just a few days, whereas it might have taken weeks before, I find it truly astonishing. So, yes, this change also brings more possibilities.
