“Garbage In, Treasure Out”: Anthropic’s Chief Designer on Cowork’s Product Philosophy and the Truth Behind Its 10-Day Launch
TechFlow Selected TechFlow Selected
“Garbage In, Treasure Out”: Anthropic’s Chief Designer on Cowork’s Product Philosophy and the Truth Behind Its 10-Day Launch
Although Claude Code already handles code-related tasks very well, our goal is to cover all knowledge work scenarios.
Navigating Web3 tides with focused insightsCompiled & Translated by TechFlow
Guest: Jenny Wen, Design Lead at Cowork
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 Takeaways
Jenny is the Design Lead at Cowork. She walked me through Anthropic’s internal operations—how she uses Cowork to design and ship products, and the real story behind Cowork’s creation. Anthropic ships new features nearly every day, and witnessing how they operate was truly awe-inspiring.
Highlights Summary
On Daily Workflow
- Most of my time is spent shipping products. But I think that looks quite different than it did one or two years ago—much of it involves informal, ad-hoc “jamming” with engineers, product managers, and others. Typically, we’ll gather around a prototype and collectively point out where and how it could evolve. Sometimes we discuss feature behavior; other times, I’ll implement something myself. A significant portion of my time is still spent designing and prototyping—but the way design work happens now feels much looser.
On the “Garbage In, Treasure Out” Philosophy
- What impresses me most about Cowork is its ability to organize information. I like to call it “garbage in, treasure out.” It can pull from diverse sources, rapidly identify key insights, distill valuable content, and convert it into tangible, productive outputs.
On the Difference Between Cowork and Claude Code
- Aside from highly detailed production code work, I now use Cowork for almost everything. When I need to focus on specific code details, I still turn to Claude Code. But for daily communication and collaboration, I rely entirely on Cowork.
On Cowork’s Origin Story
- The claim that “they built it in 10 days” was pulled from an interview or media report—but the reality is that we began conceptualizing Cowork’s direction as soon as I joined Anthropic a year ago. We’ve been thinking deeply about how to build a “thinking partner” for all general knowledge workers.
- While Claude Code already handles coding tasks well, our ambition is to cover all knowledge work scenarios. The real challenge lies in execution: What architecture is optimal? What UX is right?
On the Evolution of the Design Process
- I still use Figma. But we rarely write spec documents anymore—and when we do, they’re not overly detailed. We still prioritize work, and those priorities live as a document—but usually just a few bullet points, not an over-engineered, polished table.
On Planning and Vision
- The pace of change in our field is staggering—new models emerge constantly, and updates accelerate rapidly. So setting a one-year vision feels unrealistic, let alone two- to five-year plans—there are simply too many unknowns.
On the Future of Designers
- If the ground beneath you feels like it’s shifting, it’s because it really is. We must acknowledge that—and learn to adapt, while also openly re-evaluating how we currently work.
- Whenever I feel professionally challenged, I reflect on my engineering colleagues. Their roles transformed dramatically long before ours—and yet they adapted with remarkable courage and humility, ultimately achieving higher efficiency and better outcomes. They inspire me: if these colleagues I deeply respect can do it, so can I. They’re my model for navigating change.
Opening
Peter Yang: Hi everyone—I’m thrilled to welcome Jenny, Design Lead at Anthropic. Jenny will show us how she uses Claude Cowork and Claude Code to design and ship products, share insider stories about Cowork, and maybe even give us a glimpse into what’s next for her team’s products.
Jenny, what does a typical day look like for you? What tasks consume most of your time?
Jenny:
I’m not sure there *is* a “typical” day—but most of my time goes toward shipping products. Still, that probably looks quite different than it did one or two years ago. Much of it involves informal, ad-hoc “jamming” with engineers, product managers, and others. Usually, we gather around a prototype and point out where and how it could evolve. Sometimes it’s just discussing feature behavior; other times, I implement something myself. A large chunk of my time remains spent designing and prototyping—but the process feels far more fluid now.
Peter Yang: So basically, you generate a bunch of prototypes using tools like Claude, then jam with engineers, give feedback, and prompt AI to refine them—right?
Jenny:
Actually, they’re often not even prototypes—they’re working prototypes already running internally, or inside a Claude or Cowork instance. I typically spend time using the feature, pushing it, testing its capabilities, forming opinions—and the next iteration usually starts with me sitting down with engineers saying: “Hey, here’s what I’m thinking. These are the things I believe need changing.” I still find it incredibly important to iterate, refine, and polish within design tools. That part hasn’t disappeared—it’s just that, juggling more projects, doing it informally and casually feels more efficient.
Peter Yang: I’ve always loved that part—as a PM or designer—bringing designers and engineers together to co-evolve the product. So you don’t do spec docs or Figma files for planning anymore? Or do you just iterate prototypes directly in code?
Jenny:
I still use Figma. But we rarely write spec documents—and when we do, they’re not especially detailed. Yes. We still do prioritization, and it exists as a document—actually, that’s quite helpful when handing things off to security or legal teams, so they know what’s launching. But it’s usually just a few bullet points—not an over-designed, glossy table. Our Figma files follow the same principle.
Hands-on Cowork Demo
Peter Yang: Can you walk us through how you use each of these products—or what you use each one for?
Jenny:
Absolutely. Let me explain how I use Cowork. Here’s a little secret: aside from highly detailed production code work, I now use Cowork for *almost everything*. When I need to focus tightly on code-level details, I still reach for Claude Code. But for everyday communication and collaboration, I rely completely on Cowork.
What amazes me most about Cowork is its ability to organize information. I call it “garbage in, treasure out.” It pulls from diverse sources, quickly identifies key insights, extracts valuable content, and transforms it into actionable, productive outputs.
For example, I currently have a folder connected containing user interview transcripts. Our Cowork team places huge emphasis on staying tightly connected with users—that’s been key to our success. We conduct traditional user experience research (UXR), speaking directly with users. We also dogfood internally—for instance, we have a dedicated Slack channel for collecting feedback. Plus, we monitor social media discussions and listen closely to passionate users. Because we stay so closely tied to users—and iterate so quickly—we continuously improve and achieve results like today’s.
So what I do now is tell Claude: “Hey, I’ve got this interview folder—but also go check social media, Reddit, and other Cowork customer reviews, and tell me the biggest insights.” It might take some time, since it truly processes and synthesizes massive amounts of data. It sometimes spawns sub-agents to handle parallel processing—and even spends time searching online.
Peter Yang: In your actual workflow, do you produce weekly insight reports—automatically aggregating everything and sending them to you and your team?
Jenny:
We can absolutely do that directly via Cowork now. I think our researchers send one out regularly—and we also have a version that pings us in Slack. We listen closely to our internal Slack channel, relying heavily on internal users and our most advanced external users for cutting-edge feedback—because internal folks are genuinely willing to be honest, push features to their limits, and are easiest to follow up with.
Peter Yang: That’s exactly how it should be—and honestly, I feel most companies suffer from severe team silos, but Anthropic feels completely different.
Jenny:
I think that’s also a big part of why Claude Code succeeded—listening to frontline users. And that’s something we did extensively back in our Figma days: heavy internal dogfooding. Especially for interaction design and fine-tuning, internal users really dig into the details—whereas external users tend to give feedback like “Does this fit into my user flow?” So it delivers feedback at a fundamentally different level.
User Boundaries: Cowork vs. Claude Code
Peter Yang: I know Anthropic’s marketing and product teams are now mostly using Claude Code—even after Cowork became available internally. How do you see different usage patterns emerging—or how are people actually using Cowork versus Claude Code?
Jenny:
We’ve observed Cowork’s overall application scope gradually expanding—and beginning to encroach on use cases previously pioneered by Claude Code’s early adopters. Remember when we first started developing Cowork? Our internal sales team was our primary source of input. Several of them were deep Claude Code users—generating lead lists, writing cold-call scripts, etc. When I first saw those use cases, I was genuinely surprised—I hadn’t even imagined Claude Code could do those things. Now, those same users have almost fully migrated to Cowork—and their colleagues are adopting it heavily too.
It’s partly because there’s now a beautiful UI—so I think that’s what it truly needed. And partly because it sits so close to what they’re already doing—they’re already using chat interfaces, and they can continue using Claude Code from this desktop app. So it fits their existing workflows far better than opening a terminal.
End-to-End Flow: From Insight to Executable Artifact
Jenny:
Here are seven different themes—and they change every week. I can basically tell it: “Help me create Document X,” which automatically lands in a folder on my computer. I can even launch two parallel tasks. For instance: “These insights are great—but what actual product features should I build based on them?” And in parallel: “Turn that insight document you just made into a presentation I can share with my team during this week’s kickoff.”
From there, I can start the design process—it gives me various feature options. From there, I can even ask Claude to generate wireframes for those features. It might offer dozens of options—I can bring them into Figma to refine properly, or into Claude Code to build real versions using our actual design system components—and begin iterating from there.
Also, I can schedule both tasks. So I’ll likely set it to run automatically every Monday at 10 a.m. That means every Monday at 10 a.m., I start work with that presentation—and three or four concrete product ideas—to kick off the week. It compresses the feedback-to-tangible-output cycle extremely tightly, helping us iterate faster—and make our products better, faster.
Peter Yang: It’s all about iteration. All about iteration. I’ve gotten lazy too—I always let AI draft the first version, then I react.
Jenny:
Yes. So if you truly asked me to synthesize these insights into a feature priority list from scratch, it would now take significantly longer than before.
I do exactly that. For example, with these podcast notes you sent me—I have a personal notes folder containing 1:1 meeting summaries, random thoughts, etc.—and I just say: “Read my personal notes, help me outline key talking points for this podcast, and suggest what I should say here.” I certainly won’t read it verbatim—but it genuinely opens up my thinking and helps me evolve my ideas instead of getting stuck.
Skills and Personal Knowledge Bases
Peter Yang: Which skills do you use—or do you have personal, custom skills for documents and slides?
Jenny:
We have several internal skills specifically for documents and presentations—because they help maintain brand consistency. I don’t have a personal skill library; most of the time, I borrow existing internal skills and repurpose them for different needs.
Peter Yang: For example, I have a writing skill that tells AI not to use “AI slop” words.
Jenny:
But I’ve found that Cowork’s folder feature—where I store all my personal notes—is already incredibly useful. It learns about me through those folders—and I increasingly find memory and skills less necessary, because it already has a knowledge base about me. Of course, skills still have their place—but for my current use cases, demand feels low.
Peter Yang: Is that because it auto-updates memory based on your daily conversations?
Jenny:
Yes—it’s essentially a memory I curate myself, because I’m constantly adding notes.
Team Collaboration Touchpoints
Peter Yang: So when in this entire process do you bring the team in? Do you alternate between iterating with AI and then with your team—or how does that work?
Jenny:
I mean, things like real UXR interviews—I don’t do those myself. Either a product manager, a researcher on the team, or someone else handles them. Then, you share the artifacts directly, pull people in—and that becomes the basis for how the team operates.
Our team is quite bottom-up and democratic, so our operating model is: we share insights and goals, and everyone builds prototypes and experiments—the ideas come from everywhere. It’s not “the designer comes up with all solutions,” but rather: “Hey, here are the insights. This is our goal for the month—how do we collectively get there?”
I still don’t hand *everything* off to Claude. We still rely heavily on our own judgment—and our ability to manage and decide what to actually build.
Peter Yang: When people talk online about taste and judgment, I think the way you develop those is by continuously gathering large volumes of product feedback—both internally and externally. Over time, you build intuition—sensing what’s broken or needs fixing—because you’re listening to and processing that feedback daily. Eventually, you gain sharp, instinctive judgment.
Jenny:
For design, Claude can generate wireframe-like sketches and offer multiple design options. As a designer, I love this. Even if the sketches aren’t highly refined, they give me immediate visual access to possibilities—without relying solely on imagination. This helps me choose directions faster.
So I think letting Claude generate those initial options saves me time and energy on manual sketching. From those options, I’ll pick a direction and start small-scale iteration. Next, I might code up a basic prototype of that direction, then continue refining and polishing the design.
The Real Story Behind Cowork’s Creation
Peter Yang: Let’s talk about how Cowork came to be. There are lots of stories online about it being built in 10 days—but surely there was plenty of iteration before that?
Jenny:
The “they built it in 10 days” line was clipped from an interview or media report—and people kept circling back to it. But the truth is, we began conceptualizing Cowork’s direction as soon as I joined Anthropic a year ago. We’ve been thinking deeply about how to build a “thinking partner” for all general knowledge workers. While Claude Code handles coding tasks well, our ambition is to cover *all* knowledge work scenarios. The real challenge is: How do we execute this idea? What architecture is optimal? What UX is right?
Over the past year, we’ve explored many different prototypes—some even more ambitious than our current target. We ran numerous technical experiments, testing various AI agent frameworks—but some didn’t pan out. Gradually, we converged on today’s direction. We drew inspiration not only from lab-team prototypes but also from prototypes built by our own product team. Ultimately, timing and execution were decisive—like lightning striking the target.
When we decided to launch, the process moved extremely fast—from “We should ship” to “It’s live”—in just 10 days. This was largely triggered by seeing its potential during the Claude Code holiday period. During that break, people finally had time to try Claude Code—and even non-technical users began adopting it, using it to parse podcast transcripts or perform complex data analysis. We realized Claude Code’s agent framework was showing early product-market fit among non-technical users. Internally, we already had a working prototype—originally planned for a later release—but this feedback convinced us “now is the moment.” So we seized the opportunity—and delivered that wild 10-day sprint.
Peter Yang: If I understand correctly, over the past year you shared many prototypes in internal Slack channels, gathered extensive feedback, and eventually settled on a viable prototype. Then, seeing market demand, you executed a rapid final sprint to ship the product.
Jenny:
Exactly. We’d originally planned to launch in a few more weeks—but at that moment, we felt “now is the moment.” That urgency pushed us to narrow the scope to something more realistically achievable—and throw full energy and resources behind it—successfully delivering the launch.
Early Design Iteration: From Workflow Tool to Minimalist Chat
Peter Yang: Can you share some early iteration experiences—or show us some in-progress designs?
Jenny:
Absolutely. I’ve compiled some early screenshots to illustrate our design thinking and evolution.
Earlier this year, we had an early prototype—designed collaboratively by me and another designer. At that stage, we leaned heavily into task-oriented or workflow-oriented design. We worried whether users would grasp how to accomplish concrete tasks—or achieve clear outcomes—with Cowork—like building a dashboard or integrating data from disparate sources. So we designed the UI very structurally—almost like a workflow tool: “Add these inputs, these are your outputs.” Chat functionality was relegated to secondary status.
But why add so many steps in 2025? Why not just let Claude handle it?
This was one of our early directions—but we later pivoted toward simplicity: a plain chat box. We tried guiding users toward concrete goals—like analysis or document generation. We also built a functional prototype where clicking revealed options—each with adjustable parameters like document length or type (e.g., memo vs. presentation)—but users found it overwhelming and overly complex.
So across many explorations, we kept searching for balance: Should we define use cases more explicitly—or preserve the free-form flexibility of a chat interface?
Ultimately, the version we shipped a few weeks ago looks like this. We experimented with a near “wizard-like” UX—where clicking prompts suggestions like “Create a document, 3–5 pages long,” etc.
We also added many UI elements early on, hoping to distinguish it from a generic chat box. But we found it visually cluttered—too many competing elements. So we simplified drastically, removing most extraneous elements.
What you see now is heavily streamlined. We removed bulky sidebars, making it resemble a traditional chat box—but with tweaks on the home screen to feel more like a shared “to-do list” between me and Claude—not a chat tool overloaded with suggestions and guidance.
Peter Yang: Maybe someday it’ll support multiple agents—and let you drag tasks to manage workflows.
Jenny:
Possibly—but I want to emphasize: the UI looked completely different just four or five weeks ago. We’re constantly learning—discovering what works best, what doesn’t—and striving to present this technology to users in the most effective way.
Differentiated Positioning: Cowork vs. Claude Code
Peter Yang: Using Claude Code, I often tweet feedback. It’s packed with slash commands—you have to learn them incrementally. It feels like a “treasure hunt” at Costco—you never know what new feature you’ll discover.
But for newcomers, that’s not particularly friendly. It’s more like a game—you gradually master it with usage. I sense Cowork is exploring a middle ground between a standard chat tool and Claude Code: not hiding all features, yet gently guiding users toward effective use.
Jenny:
Yes. Slash commands remain supported in Cowork—but they’re not the primary interaction method. Personally, I see Cowork as a tool for professionals. We observe many users already engaging with it at an advanced level—and a vibrant community of power users has emerged. These users are willing to invest time learning deeper functionality—like creating custom skills, sharing them with teams, or using shorthand commands.
However, our goal is for those features to serve as *secondary* interactions—not mandatory learning. Even if users don’t know all the commands, they should still use Cowork effortlessly. We want interactions with Claude to feel natural and intuitive—not dependent on memorizing a command list.
Planning Process and Vision
Peter Yang: How does Anthropic plan? Do you do annual planning and goal-setting—or lean more on prototyping and constant experimentation?
Jenny:
Our planning approach varies each time. In my team, we plan monthly. We use a spreadsheet—at least for the Cowork portion—with roughly 12 top-priority (P0) items. Each has a directly responsible individual (DRI), and we review weekly: Are we still on track? We also do quarterly or semi-annual planning—usually led by one person stating: “I think we should head this way; these are the things we need to focus on.” But these aren’t rigid mandates to execute specific projects—more like directional signposts for the team, keeping things flexible.
Peter Yang: Flexible—right? Interestingly, I find the most innovative companies do far less annual planning—and rely more on continuous iteration and learning from users. Have you ever created a North Star vision deck in your career? Do you find them useful?
Jenny:
I have—last year, I built a North Star vision deck. I believe visions hold value: they orient the team and keep our upcoming work clear. Yet given how fast our field moves—new models emerging constantly, update cycles accelerating—a one-year vision feels unrealistic, let alone two- to five-year ones—there are simply too many unknowns.
Still, the true value of a vision lies in aligning everyone toward a common direction—especially in environments where anyone can freely build projects. So I now see vision horizons as max three to six months—and ideally presented as a living document. I find visions more impactful when they’re visualized. That’s where design adds tremendous value—integrating elements to tell a coherent story over a defined timeframe. Of course, a vision can also be a prototype—not just a static deck. It helps coordinate team efforts—especially when five teams tackle similar or potentially conflicting projects. Design can curate these ideas into alignment—and show us a path to ideal UX—not fragmented experiences.
Peter Yang: Do you hold formal product manager reviews—or reviews for relevant stakeholders? Are those formal, or do they participate in prototyping too?
Jenny:
We do hold reviews—but unlike some past companies I’ve worked at, where every feature required review, ours focus on larger, high-priority initiatives. The goal isn’t to spend excessive prep time—but to increase visibility and gather feedback. We hold these reviews for cross-team, company-wide impactful projects.
Advice for Designers: Finding Your Place in the AI Era
Peter Yang: So for designers feeling their professional landscape shifting rapidly—what advice do you offer? Should they start learning to submit PRs? Or is there another path to adaptation?
Jenny:
If the ground beneath you feels like it’s moving—it’s because it truly is. We must acknowledge that—and learn to adapt, while openly re-evaluating how we currently work. I think this wave hits designers especially hard—because we’re in the *second wave* of this transformation. Other roles underwent similar shifts earlier—and now it’s our turn. Meanwhile, our design tools themselves keep evolving.
Whenever I feel professionally challenged, I feel a flicker of unease—like “Oh no, my role is changing dramatically—people may no longer value my work the way they used to.” But in those moments, I think of my engineering colleagues. Their roles transformed massively long ago—and yet they adapted with extraordinary courage and humility, ultimately achieving greater efficiency and superior results. They inspire me: if these colleagues I deeply respect can do it, so can I. They’re my model for navigating change.
Peter Yang: In some ways, these changes liberate designers from tedious, repetitive labor—like spending hours adjusting boxes—right? So you can redirect energy toward higher-level thinking and creative work.
Jenny:
Exactly—or these changes let us *do more*. For example, when I see my engineering colleagues now shipping full features in days—versus weeks previously—I’m genuinely awestruck. So yes, this shift unlocks tremendous new possibilities.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
