You've learned how to use each Claude surface on its own. Many projects need more than one. The AI skill to train isn't using one tool well, but deciding which tools to use and how to do it best. That's the meta-skill: workflow design. By the end of this lesson, you'll design and stress-test a complete multi-tool workflow for a real project. Let's get started!

A workflow is the sequence of tools, steps, and handoffs that produces a multi-component deliverable. For anything more complex than a single task — a launch, an event, a transition, a campaign — the work isn't one thing. It's a collection of artifacts that have to be planned, sequenced, and connected. Workflow design is the skill of figuring out which tools to use for which steps, what order to do them in, and how the output of one step becomes the input of the next.

When a multi-tool project fails, the failure almost never happens inside one of the tools. It happens between them — at the handoffs. The framework you built in chat doesn't translate cleanly to the slides. The slides don't share visual identity with the page. The page collects emails that the follow-up sequence can't access. Each step is fine in isolation, but the whole thing doesn't hold together. That's why workflow design is such an important skill.

Designing a workflow has four moves, in order:

Let's walk through these four moves in a real project. Let's say you're a senior product manager at a digital reading platform. 8 weeks ago, you submitted a talk proposal to Surface, a conference on product, design, and the craft of making things work. Today, the acceptance came back. You're giving a 30-minute talk titled "The Invisible Layer: Designing Products People Don't Notice but Couldn't Live Without." The talk is in 8 weeks. About 200 people will be in the room, plus the recording will go online afterward. This is the kind of opportunity that doesn't come often.

If you were briefing yourself on this project — or briefing Claude to help you plan it — the first draft may look something like this: "I'm giving a talk at Surface in 8 weeks. I want to make sure I do this right and get the most out of it." This brief outlines the project, timeline, and goal. You'd think you could start designing the workflow.

The clarification step occurs in a regular chat with Thinking enabled. You bring the ambiguous brief and tell Claude what you want from the conversation. It's not the workflow yet, but the clarification work has to happen first. A prompt that gets you useful clarification names three things:

After the clarification conversation with Claude, the project takes its real shape:

With the project clarified, the deliverables become specific:

Five components, all required. Now the question is: which tool for which deliverable, and in what order?

Each deliverable has a tool that fits best. Forcing the wrong tool onto a deliverable is how workflows get clunky: a slide deck built in Claude Code, a recurring email sequence built as a single chat output, etc.

The tool match for each deliverable matters as much as the sequence between them:

Let's practice!

Tool selection is half the work. The other half is sequencing — what comes first, what depends on what, and what can run in parallel without blocking the rest.

Even with the project clarified, there's more than one workflow that could deliver these five components. Two designs for the same project can both look reasonable on paper, but one will hold together under execution and the other won't.

Here are two workflow designs for your talk project: Workflow A

Both workflows produce the same five deliverables, but one of them is stronger.

Your workflow has two halves. The first half — the framework and the audience research — is reasoning-heavy. You can't build the deck until you know what the framework says. You can't write the page until you know who's coming. The reasoning work finalizes the plan. The second half — the deck, the page, the article, the email sequence — is production-heavy. It's where the work becomes visible. You'll focus on production-heavy work in the next lesson.

The framework is the talk's spine. It's the thinking that the slides will eventually carry. You bring this to chat with Thinking on (so Claude takes the time to reason through it) and Research enabled (so it can pull in references on invisible design where useful). The prompt specifies what the framework needs to do, what the talk is about, and what the audience brings in.

The framework's done! You have a central argument, three case studies that ground it, and a sequence that builds. The next piece of the reasoning is different. The audience research isn't one thinking task — it's a synthesis across multiple sources (the conference program, public posts and articles, your own network's signals), and it needs to run while you do something else. Exactly the kind of job for Claude Cowork.

Cowork takes a task brief — outcome, sources, scope, schedule — and works through it on its own while you move to other things. For your audience research, the brief tells Cowork to read the conference's published materials, scan the broader public conversation on invisible design, and produce a synthesized brief on who's coming and what they're bringing. The output is a Word document that can be scanned in under 10 minutes.

Before execution, you flag the predicted risks, especially within the handoffs you expect to need attention. A useful risk note has four parts:

For your workflow, three handoffs need this attention:

You'll work them out in detail in the next lesson.

You've designed the workflow. The next time you give a talk — or the next time a colleague asks how to plan one — you don't want to start from scratch. The workflow needs to live as a document, so you will most likely want to produce a workflow SOP.

A workflow SOP (Standard Operating Procedure) is the documented version of how you handle a specific kind of project. It's a reusable template, not a one-time plan. For your talk, the SOP becomes the thing you (or anyone) opens the next time a similar project comes up: another conference, an internal presentation, or framework-with-companion-artifacts kind of work.

A useful SOP names:

Not every project needs a designed workflow. Single-tool tasks or recurring work that follows a pattern don't. Where workflow design earns its place:

When several are true, workflow design is the most leveraged thing you can do before starting.

You've designed the workflow for the Surface talk. The plan is in hand: five deliverables, the tool match for each, the sequence and handoffs, the predicted risks, and the SOP that captures it all. Now you execute! In the next lesson, you move the work through the three production layers. You'll see what handoffs look like in practice, where they break down, and where to build a small automation around what still requires manual effort. Let's keep going!