PPassTheCertExam

Study guides / CCAO-F / Domain 2

Output Evaluation and Validation · Lesson 7 of 7

2.7 — Editing, Refining, and Comparing Outputs

Treat a first Claude draft as a starting point: critique and refine it against a specific audience, compare generated variants before picking one, and choose the output format that best serves the reader.

A Claude response to a first prompt is a draft, not a finished deliverable — treating it that way changes how you evaluate it. The evaluation skill here has three related parts: refining a first draft against a specific audience's actual needs, generating and comparing multiple variants before committing to one, and choosing the output format — a plain chat reply, an Artifact, or structured data — that best serves the person who's going to use the output.

Refining a Draft Against a Specific Audience

A vague revision instruction ("make it better," "polish this up") tends to produce a vaguely different draft. A useful revision starts from a concrete question: who exactly is reading this, what do they already know, and what do they need to walk away able to do or decide? A first draft written for a general audience, handed to a technical reviewer who needs implementation detail, or to an executive who needs a bottom-line recommendation in the first sentence, usually needs real editing, not a light touch — and knowing which of those two readers you're serving is what tells you what to actually cut, add, or reorder. When you send a revision request, naming the specific gap ("this needs the recommendation up front, then supporting detail after" rather than "make it more concise") gets you a targeted edit instead of a generic one.

Generating and Comparing Variants

For anything that matters enough to get right, asking for one variant and accepting it is a weaker pattern than asking for two or three genuinely distinct variants and comparing them against your actual need before choosing. Ask explicitly for what should differ between them — "give me three versions: a two-sentence executive summary, a detailed version with supporting data, and a version written for an external client who hasn't seen the background" — rather than three near-identical rewordings of the same draft, which won't give you a meaningful choice. Comparing variants side by side against the audience's actual needs, rather than picking whichever one you happened to read first or which sounds most polished, is itself part of the evaluation skill this domain tests.

Choosing the right output format is a related, often overlooked part of curating information for a reader. An inline chat reply suits a short, conversational answer meant to be read once, in context, right where it was asked. An Artifact suits standalone content the reader will reference, reuse, or edit outside the conversation — a document, a long-form report, a diagram. Structured data — a table, or a JSON/CSV-style export — suits information the reader (a person or another tool, like a spreadsheet) needs to sort, filter, or compare across multiple items along shared fields, rather than read as prose. Choosing among these three is a curation decision, exactly like choosing which details to include and which audience to write for — the right content in the wrong format still fails the reader.

Key Concept

Treat a first draft as a starting point: revise against a named, specific audience gap rather than a vague "make it better" instruction; generate genuinely distinct variants and compare them against the actual need before picking one; and choose inline reply, Artifact, or structured data based on how the reader will actually use the output, not by default.

Common Exam Distractor

Watch for a revision instruction like "make it more professional" or "improve this" with no audience or gap named — this tends to produce a differently-worded draft, not one that's actually better suited to its reader. Also watch for defaulting to whichever output format was used last time, rather than choosing based on what this reader specifically needs to do with the output.

Exam traps

Practice question

Claude drafts a project status update as a single flowing paragraph in the chat. It needs to go to two different audiences: the internal engineering team, who need the specific blockers and next steps, and a client, who only needs a brief, non-technical summary of overall progress. What is the best approach?

  • A Ask Claude for two genuinely distinct versions — a detailed version with specific blockers and next steps for engineering, and a short, non-technical progress summary for the client — and compare each against its specific audience's needs before sending Correct

    This applies both parts of the skill together: generating distinct, audience-targeted variants rather than one generic draft, and evaluating each against the specific reader it's meant for before it goes out.

  • B Send the same original draft to both audiences to keep the update consistent

    The two audiences need genuinely different content (technical blockers vs. a brief non-technical summary) — sending identical content serves neither audience well, despite the appeal of consistency.

  • C Ask Claude to make the draft 'more professional' and send the revised version to both audiences

    A vague professionalism edit doesn't address the actual gap, which is that two different audiences need different depth and framing, not just more polished wording.

  • D Shorten the draft to the length that would suit the client, and send that same shortened version to engineering as well

    Shortening for one audience's needs removes exactly the detail (blockers, next steps) the other audience actually requires — one format doesn't serve both readers here.

Build exercise: Draft, Compare, and Format for Two Different Audiences

Beginner · 25 minutes

You'll practice:

  1. In claude.ai, ask Claude to draft a short update on a fictional project (make up a simple scenario with two or three specific blockers and next steps). Get the first draft as a single general-purpose paragraph with no audience specified. Then send a revision request that vaguely says 'make this better,' and separately, in a new message, a revision request that names a specific audience and gap: 'rewrite this for the internal engineering team — they need every blocker and next step named specifically, technical detail is fine.'

    This lets you directly compare a vague revision instruction against an audience-targeted one on the same underlying draft.

    You should see: The vague revision produces a differently-worded but similarly general draft; the audience-targeted revision produces a version with concrete blockers and next steps clearly called out for a technical reader.

    Hints 
    1. Invent specific, concrete blockers (not vague ones) in your fictional scenario so you can check whether the targeted revision actually surfaces them.
    2. Compare both revised drafts against the original side by side.
    3. Note specifically what changed in the audience-targeted version that didn't change in the vague one.

  2. Ask Claude for two genuinely distinct variants of the same update: one detailed and technical for engineering, one brief and non-technical for a client audience, in a single request. Read both against their intended reader before deciding they're actually ready to send.

    This practices generating and comparing real variants against actual audience needs, rather than accepting the first version generated.

    You should see: Two clearly different versions — different length, different vocabulary, different level of technical detail — each plausibly suited to its named audience.

    Hints 
    1. Be explicit in your request about what should differ between the two versions, not just that you want two versions.
    2. Read the client version imagining you have zero technical background — does it actually make sense?
    3. Read the engineering version checking that every blocker and next step from your original scenario is actually present.

  3. Decide which output format best fits each version — should the engineering version be a plain chat reply, an Artifact, or a structured table of blockers and owners? Should the client version be inline or something else? Ask Claude to produce the engineering version as a structured table (blocker, owner, next step, target date) instead of prose, and compare it against the prose version for how easy it is to scan.

    This applies the format-as-curation part of the skill directly — testing whether structured data actually serves this specific reader's need (scanning and tracking items) better than prose does.

    You should see: A table that's noticeably faster to scan for status-tracking purposes than the equivalent prose paragraph, making the case for structured data concretely rather than abstractly.

    Hints 
    1. Ask specifically for columns that match what an engineering team would actually track (owner, status, date), not just a reformatted paragraph.
    2. Time yourself, roughly, scanning the table versus the prose version for 'what's blocked right now' — the difference should be noticeable.
    3. Write one sentence on which format you'd actually choose for each audience and why.

Sources