Domain 4: Workflow Integration and Solution Design
16% of examAnalyze requirements and use cases before applying Claude
Key Points
- Use Claude as a thinking partner first: restate the fuzzy ask, list stakeholders/constraints, surface edge cases, draft acceptance criteria -- before prompting for the deliverable.
- Mirrors AI Fluency's Delegation (what to hand off) and Description (how to frame it).
- Good-fit traits: language/knowledge-heavy work, output reviewable/verifiable by a human, value in speed/consistency/first drafts (not guaranteed correctness).
- Poor fits: tasks needing guaranteed factual precision without review, or capabilities outside Claude's scope.
- Not every process step should be automated -- clarification identifies which steps are worth augmenting.
Decision Rules
When: Before applying Claude to any task
→Analyze fit and how output will be verified first -- don't jump straight to picking a model or building a system.
When: A task needs guaranteed factual precision with no review step
→Recognize it as a poor fit for Claude as currently scoped.
When: A request is fuzzy
→Use Claude to restate it, list stakeholders/constraints, and draft acceptance criteria before starting the actual work.
✗ Anti-Patterns to Reject
- Jumping to 'use Claude' (or 'use the most powerful model,' 'build a multi-agent system') before analyzing task fit and a verification plan.
- Assuming every step of a process should be automated.
Use Claude for research, planning, and process optimization
Key Points
- Research: gather, compare, and summarize information -- always paired with verification of factual claims.
- Planning: turn a goal into an ordered plan/outline/timeline/checklist and stress-test assumptions ('poke holes in this plan').
- Process optimization: map the existing workflow first, then identify bottlenecks/repetitive steps, then propose where Claude or automation streamlines it.
- The shared goal of research and planning is compressing time-to-draft, not replacing human judgment.
- You can't streamline a workflow you haven't described -- mapping is a prerequisite, not an optional preamble.
Decision Rules
When: Asking Claude to research a topic
→Treat the output as a draft of what might be true and pair it with verification, never as final truth.
When: Considering how Claude could speed up a workflow
→Map the existing workflow and its bottlenecks before proposing what to streamline.
When: Turning a goal into a plan
→Ask Claude to stress-test the plan (poke holes) rather than accepting the first outline.
✗ Anti-Patterns to Reject
- Treating Claude's research output as final truth rather than a starting draft to verify.
- Jumping to 'how can Claude speed this up' before mapping the workflow.
Support solution design through iteration and the simplest-approach principle
Key Points
- Prefer the simplest approach that solves the problem -- a single well-structured prompt or short chain, not an elaborate multi-step system, by default.
- Added complexity adds failure points and maintenance burden without guaranteed benefit; escalate complexity only when the simple version demonstrably falls short.
- Iterative design loop: propose an approach -> review against needs -> refine -> re-check.
- Use Claude as a design collaborator ('compare these options and list tradeoffs,' 'poke holes in this plan') while the human keeps decision authority.
- Accepting the first design instead of iterating forfeits the main value of the collaboration.
Decision Rules
When: Designing a solution around Claude for a non-developer business task
→Default to the simplest structure (single prompt or short chain) and escalate complexity only if it demonstrably falls short.
When: A first draft design is on the table
→Run propose -> review -> refine -> re-check rather than shipping it as-is.
When: Asking Claude to compare options or critique a plan
→Use its output as input to a decision, but keep decision authority yourself.
✗ Anti-Patterns to Reject
- Over-engineering a solution (an elaborate multi-step system) when a simple prompt or Project would do.
- Accepting the first design instead of iterating and comparing alternatives.
Integrate Claude into existing workflows
Key Points
- Two integration modes: augmentation (Claude drafts a step, a human edits/approves, workflow otherwise unchanged) and redesign (the workflow itself is reshaped, e.g., a standardizing Project).
- Good integration removes drudgery/speeds first drafts while keeping human review where it matters, and stays observable/reviewable.
- Incremental augmentation is usually safer and easier to validate than a wholesale rebuild -- each step is checked against the prior baseline.
- Standardize repeated team work (shared briefs, style guides) in a Project rather than manual re-pasting, a bigger model, or removing review.
- Claude Cowork runs multi-step work on real files/projects -- the practical mechanism for reshaping day-to-day workflows.
Decision Rules
When: A team re-pastes the same brief/style guide for every client update
→Standardize it in a shared Project, not by continuing manually, upgrading the model, or removing human review.
When: Deciding how much of a workflow to change at once
→Prefer incremental augmentation of one step over a wholesale redesign.
When: Considering removing human checkpoints to speed things up
→Recognize that as where quality/governance risk creeps in, and keep review where it matters.
✗ Anti-Patterns to Reject
- "Redesign everything at once" instead of incremental, validated augmentation.
- Removing all human checkpoints in the name of efficiency.
Communicate Claude's value and limitations to stakeholders
Key Points
- Value: saves time, improves consistency, enables new capacity.
- Limitations: hallucination risk, need for verification, context limits, data-sensitivity constraints, human review for high-stakes output.
- Share both value and limitations honestly, in the same conversation -- never present Claude as infallible, never present only the risks.
- Balanced communication prevents over-trust (shipping unverified output) and under-use (stalling adoption where Claude clearly helps).
- This is part of responsible adoption and connects directly to governance (Domain 6).
Decision Rules
When: Presenting Claude's fit to stakeholders or a client
→Share both value and limitations, including the need for verification -- not one alone.
When: Tempted to oversell Claude as always accurate to build confidence
→Resist -- that sets up over-trust and downstream errors.
When: Only limitations are being emphasized and adoption is stalling
→Balance with the genuine value Claude provides for well-fitting use cases.
✗ Anti-Patterns to Reject
- Overselling Claude as infallible to build confidence.
- Presenting only limitations and stalling adoption where Claude clearly helps.