Prompting and Task Execution · Lesson 4 of 5

1.4 — Adapting Prompts to Audience and Task Type

Tell Claude who the reader is and what kind of task this is — analysis, research, drafting, or brainstorming — so it can choose the right depth, vocabulary, and structure.

The same underlying content often needs to look completely different depending on who's reading it, and the same underlying request needs a different approach depending on what kind of task it actually is. A grant report written for a technical evaluator and a summary of the same results for a general newsletter audience shouldn't share the same vocabulary, even though the underlying facts are identical. And "analyze this data" calls for a different prompting approach than "brainstorm options" or "draft a first version," even when both start from the same raw material.

From Jargon to Plain Language

Suppose a draft grant report uses phrases like "confidence interval" and "effect size" throughout, and you need a version for a general donor newsletter. Simply asking Claude to "make it simpler" often produces a version that's shorter but still technically dense. The better instruction restates the statistical findings in plain language describing what the results mean practically — e.g., "the program reliably improved outcomes, and this wasn't just due to chance" instead of citing the confidence interval directly. Telling Claude the audience's role, background, and purpose for reading ("a general donor with no statistics background, who wants to know if the program worked") gives Claude the actual target to write toward.

Matching Prompting Approach to Task Type

Four common task types call for genuinely different prompting approaches, not just different wording of the same instruction:

Analysis tasks (interpreting data, comparing options) benefit from explicit criteria up front — what dimensions matter, what a good answer weighs.
Research tasks benefit from instructions to cross-check claims and cite sources (see lesson 2.2), since the output is only as trustworthy as its grounding.
Drafting tasks benefit most from examples and a clear audience/role (this lesson, and 1.1/1.2) — the goal is a specific finished artifact, not a menu of options.
Brainstorming tasks benefit from the opposite of tight constraints early on: asking for volume and range first, with evaluation/narrowing as a separate, later step, rather than asking Claude to judge quality while it's still generating options.

Key Concept

Stating the reader's role, background, and purpose helps Claude choose vocabulary, detail, and framing for a specific audience. Separately, matching your prompting technique to the task type — tight criteria for analysis, sourcing discipline for research, examples for drafting, loose generation before narrowing for brainstorming — gets better results than one generic prompting style used for everything.

Common Exam Distractor

An instruction to just shorten or simplify a passage, without describing the actual audience, tends to produce a technically-dense-but-shorter version rather than a genuinely audience-appropriate one. Similarly, applying tight evaluative criteria to a brainstorming request tends to narrow output prematurely instead of generating the range you actually asked for.

Exam traps

Assuming 'make it shorter' and 'make it for a general audience' are the same instruction

Shortening a passage can preserve jargon while cutting detail. Genuinely adapting for a general audience means restating findings in plain, practical language, which requires knowing who the reader is.
Applying the same prompting approach to a brainstorm request as to an analysis request

Asking Claude to evaluate and narrow while it's still supposed to be generating options undercuts the volume and range a brainstorm needs — narrowing should be a separate, later step.

Practice question

A nonprofit needs a grant report rewritten for a general donor newsletter. The technical draft uses terms like 'confidence interval' and 'effect size' throughout. What is the best way to adapt it?

A Ask Claude to shorten the report to half its original length
Shortening alone doesn't address the jargon problem — a shorter version can still be full of technical terms a general reader won't understand.
B Tell Claude the reader is a general donor with no statistics background who wants to know whether the program worked, and ask it to restate the findings in plain, practical language Correct
Naming the audience's background and purpose gives Claude the concrete target needed to translate statistical findings into plain-language meaning, not just trim word count.
C Instruct Claude to remove all numbers from the report entirely
Removing numbers loses meaningful information; the goal is translating technical framing into plain language, not deleting data.
D Ask Claude to keep the statistical terms but define each one in a glossary at the end
A glossary still requires the reader to do translation work themselves; restating findings in plain language directly in the text serves a general newsletter audience better.

Build exercise: Prompt Differently for a Brainstorm vs. an Analysis

Beginner · 20 minutes

You'll practice:

Compare a vague simplification instruction against an audience-framed instruction
Practice matching prompting approach to task type
Observe the effect of premature evaluation on a brainstorm task

In claude.ai, paste in a short technical paragraph containing jargon and ask Claude to 'make it simpler.' Then in a new message, describe the audience explicitly (role, background, purpose) and ask for a plain-language restatement of what the findings mean practically.

This establishes the audience-framing technique and lets you compare a vague simplification request against a targeted one.

You should see: The second version drops jargon entirely and explains practical meaning, while the first version is shorter but likely still contains a technical term or two.
Hints
1. ```
Pick a paragraph with at least two distinct jargon terms so you can track whether they survive each rewrite.
```
2. ```
Be specific in the second attempt: name a role and a purpose, not just 'general audience.'
```
3. ```
Read both results as if you were the target reader and note which one you'd actually understand.
```
Ask Claude to brainstorm 10 possible names for a new product feature, with no other constraints. Then, in a separate message, ask it to brainstorm 10 names while also evaluating and ranking each one as it goes.

This demonstrates the task-type distractor: applying evaluation criteria too early narrows a brainstorm's range.

You should see: The unconstrained brainstorm produces a wider, more varied list; the evaluate-as-you-go version tends to converge on safer, more similar-sounding options.
Hints
1. ```
Ask for exactly 10 in both cases so the comparison is fair.
```
2. ```
Look specifically at variety — how many genuinely different directions does each list cover?
```
3. ```
This is the same distinction the exam tests: generation and evaluation are different modes, best kept as separate steps.
```

Sources

Reused/adapted from Associate lesson 1-4-audience-aware-writing (earlier draft)
Anthropic docs — Prompt Engineering Overview