Organized & Compiled: Deep Tide 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

Broadcast Date: March 29, 2026

Summary of Key Points

Jenny is the Design Lead at Cowork. She took me deep into the internal workings of Anthropic, including how she uses Cowork to design and develop products, as well as the real story behind Cowork's inception. Anthropic is almost launching new features every day; seeing their way of working left me very impressed.

Highlights of Insights

About Daily Work Style

• Most of what I spend my time on is pushing products out. However, I think it looks different now compared to a year or two ago. A significant part of it is actually jamming (improvised collaboration) with engineers and product folks in a less formal manner. Usually, we all look at a prototype together and point out and think about how it could evolve.

About the Philosophy of "Garbage In, Treasure Out"

• I find Cowork's ability in information organization incredible. I like to call it "Garbage In, Treasure Out." It can collect information from various sources, quickly pinpoint key points, distill valuable content, and transform it into practical productivity results.

About the Difference Between Cowork and Claude Code

• Besides very detailed production code work, I now accomplish almost everything using Cowork. If there are scenarios that require focusing on specific code details, I still use Claude Code. But for daily communication and collaboration, I rely entirely on Cowork now.

About the Birth Story of Cowork

• The saying "They did it in 10 days" actually came from a snippet taken from an interview or media report. But the reality is that we started conceiving the direction of Cowork when I joined Anthropic a year ago; we have been thinking about how to create a "thinking partner" that can assist all general knowledge workers.
• Although Claude Code has been able to handle code-related tasks well, our goal is to cover all knowledge work scenarios. I think the real challenge is: how do we execute this idea? What kind of architecture is suitable? What kind of user experience (UX) is correct?

About the Evolution of the Design Process

• I still do Figma. However, we don't often create specification documents now, and usually, they're not as detailed. We still prioritize, and it exists as a document, but usually just as a few bullet points rather than overly designed beautiful tables.

About Planning and Vision

• The technology field we are in is changing extremely fast; new models keep emerging, and the update speed is increasing. Therefore, it's not realistic for us to set a one-year vision, let alone a two to five-year vision, due to too many unknown factors.

About the Future of Designers

• If you feel the ground beneath your feet is moving, it's because it is indeed changing. We must acknowledge this and learn to adapt while also re-evaluating our existing ways of working with an open mindset.
• Whenever I feel challenged in my profession, I think of my engineering colleagues. Their work has already undergone significant changes, but they not only adapted to these changes; they embraced the challenges with great courage and humility, ultimately achieving more efficient and outstanding results. They are my source of inspiration—I tell myself if these respected colleagues can do it, so can I. They are my role models for adapting to change.

Opening Remarks

Peter Yang: Hello everyone, today I am extremely 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 sharing the internal stories of Cowork, and perhaps discussing the next steps for her product.

Jenny, what does a typical day look like in your work? What tasks occupy most of your time?

Jenny:

I don’t know if there is a typical typical day, but most of what I spend my time on is pushing products out. However, I think this may look different from a year or two ago, and a large part of it is actually jam (improvised collaboration) with engineers, product personnel, etc., in a less formal way. Usually, everyone looks at a prototype together and points out and thinks about how it can evolve. Sometimes it's just discussing functionality performance; sometimes I am implementing something myself. I still feel a significant part of my time is spent designing and prototyping, but now the way design work feels very loose.

Peter Yang: Essentially, you generate a bunch of prototypes using Claude and then jam with engineers, giving some feedback and using prompts to let the AI improve it, right?

Jenny:

Actually, they often aren’t even prototypes but working prototypes that are already built and running in our internal and Claude or Cowork instances. I usually spend time using this feature, pushing this feature, seeing its capabilities, forming opinions, and the next iteration usually is me sitting down and telling the engineers: Hey, this is how I am thinking. These are the areas I think should change. I still feel there’s time for me to iterate, refine, and polish in the design tool, which remains very important. So that part hasn’t disappeared. It's just that because I am managing more projects simultaneously, it feels more efficient to do this very casually and informally.

Peter Yang: I think that's always been the part I enjoyed the most as a product manager or designer—getting designers and engineers together and watching the product iterate together. So, you don’t do those specification documents, Figma files planning documents much anymore? Or do you just iterate prototypes in the code?

Jenny:

I still do Figma. But we don’t often create specification documents now, and they're usually not that detailed. Yes. We still prioritize, and it exists as a document. It’s actually very helpful for our security or legal teams to know what the release contains, but usually, it's just a few bullet points, not those overly designed beautiful tables. I think our Figma files are the same.

Cowork Practical Demonstration

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

Jenny:

Of course. Let me talk about how I use Cowork. Actually, I have a little secret; besides very detailed production code work, I now accomplish almost everything using Cowork. If there are 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 find Cowork's ability in organizing information quite astounding. I like to call it "Garbage In, Treasure Out." It can gather information from various different sources, quickly find key points, distill valuable content, and transform it into practical productivity outcomes.

For example, right now I have a folder connected that stores some user interview records. Our Cowork team places great emphasis on close contact with users, which is also one of the keys to our success. We engage in traditional user experience research (UXR), talking directly with users, and we also have internal ways like a dedicated Slack channel for collecting feedback. In addition, we also pay attention to discussions on social media and listen to the opinions of those enthusiastic users. It is because we maintain close contact with users and can quickly iterate products that we have been able to improve and achieve today's results.

So what I need to do now is tell Claude: Hey, I have this interview folder, but I will also let Claude go to social media, Reddit, and other Cowork customer reviews to see what the biggest insights are. It may take a little time because it really needs to process so much data and produce it. But it will do things like occasionally spawning sub-agents to process in parallel, and it will spend time searching the web.

Peter Yang: In your actual work, do you have those weekly insight reports or something? Do they automatically summarize everything and send it to you and the team?

Jenny:

Actually, we can now do this directly through Cowork. I believe our researchers have one that gets sent out, and we also have a version that pings us in Slack. We also listen directly to the internal Slack channel; we rely heavily on internal and the strongest users to provide us with that cutting-edge feedback because internal folks are really willing to be honest with you; they often push the features the farthest and follow up the easiest.

Peter Yang: I think that's how it should be, and I feel that most teams in companies are too siloed, but Anthropic doesn’t feel that way at all.

Jenny:

I think that's also a vital part of Claude Code's success—listening to frontline users. And this is also a lot of what we do in Figma, a lot of internal dogfooding. Because especially when it comes to interaction design and polishing these aspects, internal folks will really poke at those details, while external users often provide feedback more on whether it fits within their user workflows, so it can provide a completely different level of feedback.

Usage Boundaries Between Cowork and Claude Code

Peter Yang: I know that Anthropic's marketing and product managers are basically using Claude Code to work now, especially since Cowork became available internally. How do you see different types of use cases? Or how does everyone use Cowork and Claude Code?

Jenny:

We’ve noticed that the overall application scope of Cowork is gradually expanding and beginning to be used in scenarios similar to those attempted by early users of Claude Code. Remember when we first started developing Cowork, the internal sales team was our primary source of information. A few of them were deep 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 didn’t even think of Claude Code being used to complete these tasks. And now, those users have almost fully transitioned to Cowork, and even their colleagues have started using Cowork frequently.

Because there is now a good-looking UI, I think that is what it truly needed. And part of the reason is that it's very close to the other work they are doing—they were already using chat features, and they can continue to use Claude Code from this desktop application, so I think it's more in line with their existing workflows than opening a command line.

The Full Process from Insights to Executable Artifacts

Jenny:

Here are seven different themes, and each week is different; I can basically tell it: Help me create this document X, and it already exists automatically in a folder on my computer. I can also start two parallel tasks simultaneously. For example, I can say: These insights are great, but based on these, what product features should I actually build? And then I can also do another thing in parallel—based on the insights document you just helped me create, turn this content into a presentation I can share with the team during this week's kickoff.

But ultimately, I can start the design process from here—it gives me various feature options. From there I can even let Claude help me create some wireframes for these features. It might give me a bunch of different options that I can take to Figma to refine or take to Claude Code to turn into something real with our actual design system components and then start from there.

Another thing I can do is set both of these tasks to recurring tasks. So I’d probably have it help me schedule this task to automatically execute every Monday morning at 10 AM. This way, I'll start working every Monday at 10 AM with this presentation and three or four different product ideas to kick off the week. It greatly compresses the iterative cycle from feedback to tangible things or ideas for the team, helping us iterate products quickly and make them better faster.

Peter Yang: It’s all about iteration; it’s all about iteration. I've become lazy too; I always let the AI do the first version, then I reflect on it.

Jenny:

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

I do the same thing. For example, this podcast note you sent me, I have a personal notes folder that contains 1:1 meeting contents, random thoughts, etc., and then I directly say: Read my personal notes, help me think about the key points I want to make from this podcast, and help me think about what I want to say here. I certainly won’t read it verbatim, but it really helps me open my mind and evolves my thinking instead of getting stuck.

Skills and Personal Knowledge Base

Peter Yang: What skills do you use? Or do you have personal specific skills for making these documents and presentations?

Jenny:

We have several skills internally specifically for making documents and presentations because they help us maintain brand consistency. I actually don’t have a personal skills library; most of the time, I just borrow already 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 vocabularies.

Jenny:

But I actually find that now using Cowork's folders—I keep all my personal notes and such in there—it learns about me through these folders, and for me, that has been very useful. I feel less and less need for memory and skills because it already has a knowledge base about me. Of course, I still think skills have their applicable scenarios, but for my current use cases, I personally feel the demand is not that high.

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

Jenny:

Yes, it’s basically a memory I maintain myself because I am consistently taking notes in there.

Team Collaboration Nodes

Peter Yang: So when do you bring the team in during the whole process? Or do you iterate with AI and then alternate iterating with the team, or how do you do it?

Jenny:

I mean, for things like real UXR interviews, I don’t actually do those myself—it’s either the product managers or researchers on the team, or other members of the team will do them. Then through this, you directly share artifacts, bring them in, and this can actually become the basis for team operations.

Our team is at least quite bottom-up and democratic, so the way we operate is we provide insights and goals to everyone, and then each person goes off to make prototypes, try things, with ideas coming from all directions. It’s not just me as the designer coming up with all the solutions, but rather, "Hey, here are the insights. These are the goals we should strive to achieve this month; how do we all achieve this together?"

With this, we still wouldn’t just hand everything over to Claude to do. We still rely on ourselves to make many judgments, and our ability to manage and decide what to genuinely build and do.

Peter Yang: When people talk about taste and judgment online, I feel that this skill is cultivated through continuously gathering a lot of product feedback from both internal and external sources. In the process, you gradually form an intuition about spotting problems and areas that need fixing. Because you're listening and processing this feedback daily, over time, you develop a sharp judgment about issues.

Jenny:

As for design, one of Claude’s features is it can generate sketches similar to wireframes and provide multiple design options. As a designer, I really like this approach. Even if these sketches aren’t very refined, they allow me to see different possibilities intuitively without needing to rely solely on my imagination. This method can help me make decisions about the next design direction more quickly.

So I think letting Claude generate these initial options directly can save me time and effort in manually creating sketches. From these options, I will choose a direction and start a small iteration. Next, I may code this direction into a preliminary prototype and then continue to optimize and refine the design based on that.

The Real Story Behind the Birth of Cowork

Peter Yang: Let’s talk about how Cowork was born. There are many stories out there about it being made in 10 days, but actually, there were many iterations before that, right?

Jenny:

The phrase "They did it in 10 days" actually came from a snippet taken from an interview or media report, and people have been discussing it around that point. But the reality is that we’ve been conceiving the direction of Cowork since I joined Anthropic a year ago; we have been pondering how to create a "thinking partner" that can assist all general knowledge workers. Although Claude Code has been able to handle code-related tasks well, our goal is to cover all knowledge work scenarios. I think the real challenge is: How do we execute this idea? What kind of architecture is most suitable? What kind of user experience (UX) is the right one?

In the past year, we have tried many different prototype designs, some of which were even more ambitious than today’s goals. We also conducted many technical experiments and tested various AI agent frameworks, but some of those attempts did not succeed. Ultimately, we gradually identified the current direction. We not only referred to prototypes developed by experimental teams but also studied prototypes built by our product team. In the end, timing and execution became critical, like lightning striking the target perfectly.

When we decided to launch this product, the entire process was very swift—from saying "We should launch" to "The product is live" took only 10 days. This was mainly because we saw the potential during the Claude Code holiday period. During that holiday, many people finally had time to try Claude Code, even non-technical users began to use it, such as parsing podcast transcripts or conducting complex data analysis. We found that the agent framework of Claude Code also started exhibiting early product-market fit among non-technical users. At the time, we already had a working prototype internally, initially planned to launch it a bit later, but this feedback made us realize that "now is the perfect time." So, we decided to seize the opportunity, leading to that crazy 10 days.

Peter Yang: If I understand correctly, over the past year, you shared many prototypes in your internal Slack, gathered a lot of feedback, and eventually zeroed in on a viable prototype. Then, seeing the market demand for it, you quickly executed a sprint and pushed the product out.

Jenny:

That’s right; that’s roughly what happened. We initially planned to launch a few weeks later, but we felt that "now is the best time." This also prompted us to narrow the product's scope to a more realistically feasible level under time constraints and put in all our energy and resources, ultimately successfully completing the launch.

Early Design Iterations: From Workflow Tool to Minimal Chat

Peter Yang: Can you share some experiences about early iterations or showcase some content that is in development?

Jenny:

Of course. I specifically organized some early screenshots to show our design thinking and iteration process at that time.

Earlier this year, we had an early prototype that was completed in collaboration with another designer. At that time, we tried to make this tool more task-oriented or workflow-oriented. We were very concerned about whether users could understand if they could complete specific tasks or achieve clear outcomes (like creating a dashboard or integrating data from different sources) using a product like Cowork. So we designed the user interface to be very structured, almost like a workflow tool—like "Add this content, this is the input, this is the output." The chat functionality was placed secondarily.

But it felt like many steps were required to complete things; in 2025, why should we keep it so complicated? Wouldn’t it be better to let Claude handle these?

This was an early design direction, but later we decided to change our thinking to make it simpler, like a chat box. We tried to guide users to achieve more specific goals, such as analysis or document generation, through this approach. We even designed a functional prototype—when users clicked, they could see various options, and each option had buttons to adjust, like document length or choosing document types like memos or presentations, but this design ultimately made users feel overly complex and pressured.

So through multiple explorations and attempts, we've been striving to find a balance: Should we define usage scenarios more explicitly or maintain a free-form style like a chat box?

Ultimately, the version we released a few weeks ago is what it looks like now. We once tried a user experience that was almost "wizard-like," where users would see prompts like "Create a document with a length of three to five pages" when they clicked.

At that time, we added many elements to the interface hoping to make it look different from an ordinary chat box. But later, we found that this design made the interface look too complex and that there was too much competition between visual elements. 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 the heavy sidebars and 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 between me and Claude instead of just a chat tool filled with complex suggestions and guidance.

Peter Yang: Maybe in the future it can support multiple agents, dragging tasks to manage workflows.

Jenny:

Maybe that’s a possibility for the future. But I want to emphasize that the UI design was completely different about four to five weeks ago; we have been constantly learning and exploring what designs are most effective, what designs do not work well, while striving to find the best way to present this technology to users.

Positioning Differences Between Cowork and Claude Code

Peter Yang: While using Claude Code, I often share some feedback on Twitter. It has many built-in slash commands that require users to learn a bit over time. This experience is a bit like a "treasure hunt" when shopping at Costco; you never know what new features you’ll discover.

But for newcomers, this approach is not very user-friendly. It feels more like a game; as you use it over time, you gradually become familiar with and master it. I feel Cowork is trying to explore the middle ground between a regular chat tool and Claude Code. It doesn't hide all functions 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. Personally, I feel that Cowork is at least a tool for professionals. We’ve observed that many users are using it in a very advanced way, and some advanced users have already emerged in the community. These users are generally willing to spend time learning more complex functionalities, like creating skills themselves, sharing with the team, or using shorthand commands.

However, our goal is for these functions to be a secondary mode of interaction rather than mandatory learning content. That is to say, even if users do not understand all the commands, they can still easily use Cowork. We hope the interactions between users and Claude are natural and intuitive, rather than requiring memorizing a series of commands to operate.

Planning Processes 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 methods vary each time. In my team, we do monthly planning. We have a spreadsheet that lists a maximum of about 12 tasks, at least in the Cowork section, which are our top priorities (P0). Each task has a Directly Responsible Individual (DRI), and we check weekly: Are we still on the right track? We also engage in some quarterly or semi-annual planning, typically led by someone who states, "I think we should head this way; these are the matters we need to focus on." But these plans are not so strict that specific projects must be executed. It’s more about providing the team with an overall direction, hence it is relatively flexible.

Peter Yang: Relatively flexible, right? Interestingly, I find that the most innovative companies often do less annual planning, relying more on continuous iteration and learning from users. Have you done anything like a North Star vision deck in your career? Do you find these useful?

Jenny:

I have indeed created one; last year I made a North Star vision deck. I believe visions do have value; they give direction to the team and help us maintain clarity in upcoming work. However, given that we are operating in a rapidly changing technological field with new models constantly emerging and updates speeding up, it’s not realistic for us to set a one-year vision, let alone a two to five-year vision, due to too many unknown factors.

However, the true 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 timeframe for a vision should be no more than three to six months and can be presented in documentation form. I feel that when a vision is visualized, it becomes more impactful. This is also a tremendous value of design—integrating various elements to tell a coherent story over a specified 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 handling very similar or potentially conflicting projects. Design can help curate these ideas to reach a consensus and show us a path towards an ideal user experience rather than fragmented experiences.

Peter Yang: So do you have product manager reviews or reviews for the relevant personnel? Are these reviews formal, or do they also get involved in prototype design?

Jenny:

We do have reviews, but unlike at some companies where every feature requires a review, ours mainly focus on larger, higher-priority projects. The purpose of the review is not to consume a lot of time preparing but to enhance the visibility of the projects and obtain feedback. If there are cross-team, company-impacting significant projects, we would conduct these reviews.

Advice for Designers: How to Find Your Place in the AI Era

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

Jenny:

If you feel the ground beneath your feet is shifting, it’s because it truly is changing. We have to acknowledge this and learn to adapt while also re-evaluating our current ways of working with an open mind. I think the current changes are significantly impacting designers, especially since we are in the second wave of this tide. Other professional roles have already undergone similar transitions, and now it’s our turn. Meanwhile, our design tools are also evolving.

Whenever I feel my career is being challenged, I sometimes feel uneasy, like “Oh my, my work is undergoing significant changes, and people may no longer value my work as before.” But during such times, I think of my engineering colleagues. Their work has already experienced tremendous changes, but they not only adapted to these changes but also faced challenges with great courage and humility, ultimately achieving more efficient and exceptional results. They are my sources of inspiration—I tell myself if these respected colleagues can do it, then I surely can. They are my role models for adapting to change.

Peter Yang: To some extent, these changes free designers from many tedious repetitive tasks, such as not having to spend time adjusting various boxes, right? This way, you can focus more on higher-level thinking and creative work.

Jenny:

Exactly, or these changes allow us to accomplish more. For instance, when I see that my engineering colleagues can now complete an entire feature in just a few days, which used to take weeks, I am genuinely amazed. So yes, these changes have also brought about more possibilities.