For most of my career, I never wrote down how I made decisions.
Not the decisions themselves, but the logic behind them. Why this layout and not that one. Which stakeholders were best suited to try something new. Why an interaction works this way for admins, but that way for editors. How I was able to successfully push back on that PM's request. All that stuff lived entirely in my head.
About halfway into my first time as a Design Director, I realized how much of what made me effective was completely inaccessible. To anyone, including me. I couldn't search my own judgment. I couldn't hand it to someone else. I couldn't even reliably retrieve it for myself when I needed it six months later.
The process of teaching others and building a curriculum forced me to start putting that logic into words. And that changed how I work more than any tool ever has. It's provided a kind of clarity I never had before, both for myself and for others.
But over the last seven years, doing this has created a different problem. While my logic was out of my head, it was locked inside courses. Transferring this logic to others required me to be in the room, or required someone to commit hours, days, weeks to working through the material. That kind of deep engagement is the best way to learn, but it's also a commitment almost no one can make right now. People don't have the time, energy, or the motivation to learn that way. I've spent years trying to figure out how to transfer this thinking without requiring either my presence or that level of dedication.
The last few months, I've been using Claude in a way that designers, PMs, Engineers, Leaders, etc. aren't really talking about yet. Not for coding prototypes. Not for prompting artifacts. But for building what I'd call thinking infrastructure: systems that structure logic and judgment so I or others can access it when needed.
The interesting part isn't the systems. It's what happens when you try to build them.
How I found this
When I set out to teach others, I wanted to take what I knew intuitively (through learned experience) and turn it into something teachable. The process of writing out methodologies, structuring lessons, articulating why one approach works in one context and not another was where my logic started becoming explicit. But for all the good that's come out of it, these lessons were still bound to the way they are delivered. Either stuck inside a course someone had to sit through, or within a coaching session that required me to be there.
I've always thought the best way to teach others was to approach it like a D&D game. Not the dice and manuals, but through role-playing and situational adventuring. When you play, a good dungeon master doesn't just give you the rules, they help you read the situation so you can figure out which rules apply in the moment, within the specific context, and with specific dynamics. That's what I do when I coach or teach. The question has always been how to make that available without me sitting across the table.
Last year, I tried building CDO School into D&D-style app. It worked, it was fun, but it never felt right. The translation from methodology to software always lost something essential. For all the magnificent things we're able to do with software, there's rigidity when it comes to performing specific tasks. But effective teaching is all about flexibility, meeting the student where they are rather than assuming they're at a specific starting point.
When Claude introduced Claude Skills, I finally saw a new path forward. Specifically, I saw Skills as the way to take all my content and programming, and codify it so an agent could surface the right piece at the right moment. Rather than generating new content, I wanted to structure my existing judgment for retrieval.
I began building out custom skills, made good progress, but found myself frustrated with a single program: I had to use Terminal to build Skills. When Claude Skills first launched, building them meant working in Terminal. Basically the same way to use Claude Code.
Now, I can use Terminal fine. I just don't like it. Every Terminal session was a fight between the idea I was trying to build and my frustration with having to use Terminal. I'd make progress, hit my tolerance limit, close the window, and come back to it days later. The work moved at the speed of my patience, not my thinking.
Then Claude released Cowork, and that constraint disappeared completely. Cowork introduced the same capabilities as Claude Code, but now I was working in an interface that didn't fight me. That's when things started moving.
I manually created text files from course content and video transcripts, module by module. I asked Cowork to help me organize them into a structured folder system. I built a router that decides which content to surface based on what someone asks. I built a scenario detector that pattern-matches real situations designers face —
"my PM keeps cutting me out of decisions," "I have a board presentation next month", "The CEO just changed the scope at the last min — to pre-built guidance based on my vast experience with these situations.
I built a contradictions guide for when my own curriculum gives seemingly conflicting advice depending on context. I built instructions to evaluate the urgency of a request before giving a response. I built a damn mind map for my thinking in a way that others could use without me having to explain all the thinking up front.
Cowork is not flawless by any means. It totally overwrote files I didn't want it to because I didn't specifically say not to do that. It's still Claude, so will hallucinate just like any other model when I don't say what I mean. But, with just an hour or so, I learned to treat the whole thing like a product. I separated tasks for building from testing. Separated tasks for designing new reference files from refining existing reference files.
What has surprised me most though isn't the finished tool I've made for myself. It was the process of building it. Every time I tried to codify my own methodology, it forced me to articulate something I'd previously just known intuitively. The act of making the implicit explicit, of putting my judgment into words clear enough for a agent to use, was itself a form of development I hadn't expected.
If nothing else, Claude Cowork fulfills a desperate need in me that every designer has at one time or another: to be so clear they are understood and listened to.
So, with that said, here are some things designers can build with Claude Cowork, along with some notes on the obstacles I still find myself running into.
1. Build a design logic reference library
This is the foundation. Everything else gets better once this exists.
Most designers have years of accumulated knowledge scattered across tools, bookmarks, old project files, and their own memory. Case studies from previous work. Design rationale from past decisions. UI patterns they've internalized. Accessibility requirements they look up every time. Platform-specific guidelines. The differences between how they approach landing pages versus enterprise software.
A design reference library in Cowork brings all of that into one queryable place. Imagine your own personal Mobbin, not as a visual library, but a knowledge base you can actually ask questions of. Upload your past project documentation, your case studies, your rationale docs. Add the design logic: the UI patterns you rely on, your accessibility guidelines, your platform requirements. Cowork can help you make it searchable and structured. The key here is to prioritize words over pixels.
Start small and once it exists, you can ask it things like: "When was the last time I solved a similar navigation problem and what was the rationale?" Or: "What accessibility requirements apply to this type of interaction?" Or: "How did I handle this layout pattern on the previous project and what would I change?"
Cowork isn't generating the answers for you. It's helping you create a structure for your own past thinking so you can retrieve it when you need it. The value comes from what you put in.
Cowork limitations: the library is only as good as your source material. If your design rationale lives as vibes rather than words, you'll need to articulate it first. The more explicit you can be about why you made past decisions, the more useful this becomes. Think of it as an investment. Every rationale you write down now is retrievable judgment later. Also, Cowork doesn't have version control. Cowork will overwrite files unless you tell it not to. Be explicit about which files are reference material that should never be modified.
2. Build a repository of communication and planning templates
Designers spend an enormous amount of time on the documents that surround design work: project briefs, research plans, stakeholder updates, handoff documentation, meeting agendas. These documents are rarely taught in design school and most designers reinvent them from scratch every time.
Build a Skill that holds your templates for how you write a design brief, structure a research plan, format a critique agenda, write a stakeholder update. In fact, share the actual briefs, plans, agendas, etc. that you've used before and build a skill around it that knows when to suggest which one. Working on a new project? Here's the brief template. Preparing for a research phase? Here's the plan format. Need to update stakeholders? Here's the format that's worked before, adapted for this audience.
This is particularly useful for designers who are early in a senior role and haven't yet built their own library of "how I communicate about my work."
Cowork limitations: templates create consistency, but they can also create rigidity. Claude can help build at skill that will surface the template, but knowing when to deviate from it is still your judgment call. And company-specific templates evolve, so if your team changes how they communicate a plan, you need to update the source material.
3. Build a personal development tracker
The most uncomfortable truth about professional development is that while most of us don't have a clear picture of where we are, where we want to be, or what the specific gap looks like, we don't have a lot of practical guidance from bosses on how to do this well.
Companies have leveling frameworks. Your org chart defines skills by role. Your performance reviews contain specific feedback. But that information sits in separate systems, gets reviewed once or twice a year, and rarely translates into a plan you actually use.
You can use Cowork to build a Skill that brings this together. Upload your company's leveling framework. Add the skills referenced in your org chart. Include feedback from your most recent performance reviews. Add your own assessment of where you're strong and where you're not.
Now you have a thinking partner for career development. "Based on the leveling framework, what skills am I missing for the next level?" "My last review said I need to be more strategic. What does that actually mean in terms of specific skills I should develop?" "I want to focus on one area this quarter. Given my review feedback and my leveling requirements, where would I get the most return?"
Cowork limitations: If your self-assessment isn't honest, the output won't be useful. It also can't capture the unwritten rules around promotions. Like budget constraints or the things your manager values but your leveling framework doesn't mention. Just like the others, you'll have to expand on these as you go for the skill to get better.
4. Build a lightweight brand and voice guide
In Say What You Mean, I wrote about why designers need to get explicit about their logic. The core idea behind this is AI doesn't have eyes. They're prediction models, not observers. If you hand them a picture, you're giving them a puzzle. If you hand them words, you're giving them your answer key.
The same principle applies to brand logic. Most design teams have brand guidelines somewhere in PDFs, a Figma file, or Notion page, but the reasoning behind the guidelines is often implicit. Why these colors? When does the voice shift? What's a hard constraint versus a flexible one?
When working with Agents, it's best to encode and share this logic right where the Agent needs it. Not a dump of the brand PDF, but a text reference file that speaks in clear terms about what the brand is, what it isn't, and why. Once it exists, you can also query it. "Does this component align with our brand voice?" "What's the accessibility requirement for this interaction type?" "We're designing a new landing page. How does this shift our approach compared to product?"
Cowork limitations: Brand and voice are interpretive. They always have been. You can define the explicit rules, but the judgment call about whether something feels right is still yours. For shared resources, you absolutely should give Cowork clear rules about who can modify the source files before you share them. Without governance, someone can overwrite previous decisions without anyone noticing.
5. Build a critique prep tool
This is the one I wish I'd had ten years ago. Critiques are where design judgment becomes visible. They're also where most designers are least prepared. Not unprepared in the sense of not having work to show, but in the sense of not having structured their thinking for the specific audience in the room or context of the critique.
A critique with your design peers requires different framing than a review with your PM, which requires different framing than a presentation to your VP. The same design decision might be framed as a user experience improvement for your peers, a risk reduction for your PM, and a revenue opportunity for your VP. The work doesn't change. The framing does.
Build a Skill that helps you structure your thinking before you walk in. Feed it what you know about the people who'll be in the room. What's the PM measured on? What does the VP care about most? Is this a check-in or a decision point? Are there politics you need to be aware of?
Then let it help you answer: What's the strongest version of my rationale for this audience? What objections are they likely to raise? What questions should I be ready for?
This isn't scripting the conversation. It's forcing yourself to articulate the reasoning behind your decisions before you're under pressure to do it in real time.
Cowork limitations: It doesn't know the hallway conversations that happened before the meeting or the mood your VP is in. It structures your thinking, but doesn't replace your awareness. This particular tool is likely best for personal use, when you want your work critiqued. Use it to prepare, then be present in the actual conversation.
The real point
None of these are instructions. They're examples meant to help you think about what's possible when you stop using Claude as a production tool and start using it as thinking infrastructure.
The thing I've learned building my own system is that the hard part isn't the technology. It's the articulation. Every one of these tools requires you to put your judgment, your logic, your reasoning into words. Not vibes. Words. The more explicit you can be, the better the system works.
Cowork gives Claude access to your local files, so you can build and test your own tools without having to learn Terminal speak. I feel unlocked in so many ways. And while the tools I'm generating with Cowork are useful, the real value is what is happening to my own thinking when I try to build it.
This is the first in a series of three articles. Next: Claude Cowork for Design Leaders. Five things to build when you're responsible for a team's strategy, development, and organizational influence.
