CCAO-F 4.3 — Designing and iterating a solution

The design and iteration loop

State the jobwho uses it, for what, judged how
Draft a versionan artifact you can see and share
Test on a real caserun last month’s actual input through it
Change one thingname the fault, not the feeling
Keep or roll backversions make this reversible

Each pass fixes one named fault; stop when the real cases pass

The test step is what separates iteration from redecorating. Until a real case has gone through the draft, you are only reacting to how it reads.

Start by defining “good”, not by describing the thing

The single biggest lever on a first draft is stating how the result will be judged. Anthropic’s prompting guidance offers a useful test: show your prompt to a colleague with minimal context on the task and ask them to follow it — if they would be confused, Claude will be too. It also advises explaining why something matters rather than only what to produce, because Claude generalises from the explanation. For solution design, that means opening with the user, the situation, the constraint and the standard.

Two ways to open a design conversation

Describes the artefacttext

Create an interview scorecard for
hiring customer support agents.

Describes the job it must dotext

Build an interview scorecard for hiring
support agents at a software company.

Used by: hiring managers, many of whom
interview twice a year, filling it in on
a laptop during a 45-minute interview.

It must let two managers who interviewed
the same candidate compare scores and
explain a difference.

Four to six criteria, each with a 1-4
scale where every point is described in
behaviour, not adjectives. One evidence
box per criterion. Fits one page.

Ask me anything you need before drafting.

The right-hand brief names the user, the moment of use, the constraint and the test. Everything in the first draft can then be judged against something.

The last line is doing real work. Current Claude models follow instructions closely and tend to do exactly what was asked rather than volunteer extras, so inviting questions is how you get the gaps in your own brief surfaced before a draft is built on top of them. A good answer to “ask me anything” often reveals that you never decided whether the scorecard is used for screening calls as well as final interviews.

Build it where you can see it: artifacts

Anything you intend to share or keep should be built as an artifact rather than as a wall of chat text. Artifacts are self-contained pieces of work — documents, tables, diagrams, small interactive tools — that open in a dedicated window beside the conversation, where you can read, edit and revisit them. Claude’s help centre describes them as the things you would share with someone else, and notes that substantial content, typically more than about fifteen lines, becomes an artifact while short answers and explanations stay inline in the chat.

Three properties matter for iteration. There is a version selector, so you can move between drafts and go back when a change made things worse. For Markdown documents you can highlight a passage and edit it with Claude directly, rather than describing in chat where the problem is. And a finished artifact can be shared by link or exported, so the work leaves the conversation. Artifacts are available on all plans, and they require code execution and file creation to be enabled in settings — on Team and Enterprise that is an organisation setting an admin controls.

Where the work lives

Solution built in chat text

Each revision is a new block; the current version is whichever you scrolled to
Sharing means copying and pasting, losing structure
No way back to the version that worked
Colleagues cannot see it without the whole conversation

Solution built as an artifact

One object that updates in place as you refine it
Version selector to compare and roll back
Highlight a passage and revise just that part
Shareable by link or exportable when it is ready

The chat is the conversation about the work; the artifact is the work. Confusing the two is why good drafts get lost.

Iterating: change one named thing at a time

Vague dissatisfaction produces vague revisions. “Make it better”, “this isn’t quite right”, “more professional” all invite Claude to change everything, including the parts that were already correct. A productive revision names three things: what is wrong, where, and what should be true instead. It also says what to leave alone, which is the instruction people forget and the reason a fourth draft is often worse than the second.

Weak revision	Why it backfires	Stronger revision
“Make it better.”	No target, so everything moves, including what worked	“Keep sections 1–3 exactly. In section 4, replace the adjectives in the scale with observable behaviours.”
“Too long.”	Claude cuts whatever it judges least important, often your must-have	“Cut to one page by removing the examples, not the criteria.”
“Try again.”	Discards the draft and re-rolls the dice	“The 1-4 scale is the problem: points 2 and 3 are indistinguishable. Rewrite those two only.”
“Make it more professional.”	Style word with no shared definition	“Write for a hiring manager who has never used a scorecard: no HR jargon, no acronyms, second person.”

Worked example · An interview scorecard, in four fittings

Naomi in HR is standardising interviews for support agents. Four managers interview candidates, and their notes are currently free text, so nobody can compare two candidates fairly.

Fitting one. She gives the brief above and asks Claude what it needs to know. It asks whether the scorecard covers screening calls, and whether managers can add criteria. Both answers change the design.
Fitting two. The draft comes back as an artifact: six criteria, 1-4 scales, an evidence box each. She reads it and finds the fault immediately — points 2 and 3 of each scale are near-identical adjectives.
She names one fault. “Rewrite only the scale descriptors so each point is an observable behaviour; leave the criteria and layout as they are.” Version three fixes it without disturbing anything else.
Fitting three: the real test. She fills it in from her own notes on two candidates she interviewed last month. One criterion — “resilience” — turns out to be unscoreable from anything that happens in the interview.
She removes rather than adds. Five criteria, not six. This is the change nobody makes when they are only reading the draft.
Fitting four: someone else uses it. A manager fills it in during a live interview and finds the evidence boxes too small to type in on a laptop. One more version.
She makes it reusable. The final scorecard, the instructions for filling it in, and the two worked examples go into the hiring Project so every manager starts from the same version.

Takeaway: Four small passes, each fixing one named fault, and two of the most important changes came from use rather than from reading. The last step is what turns a good document into a solution the team actually runs on.

From a one-off to something repeatable

A solution that only exists in one person’s chat history is a draft, however good it is. There are three places to put work so it survives, and the exam expects you to know which is which. Project instructions and project knowledge hold standing context for a body of work — the templates, the definitions, the rules that apply to every chat in that Project. Skills package a repeatable procedure that Claude can load when it is relevant. And an artifact, shared or exported, is the deliverable itself.

Anthropic’s help centre draws the distinction plainly: Projects provide background knowledge that is always present within that Project’s chats, while Skills activate dynamically across Claude when a task calls for them. A skill is a folder whose central file carries a name and a description — the description is what Claude uses to decide whether the skill is relevant, so it has to say what the skill does and when to use it. Skills can be written in Markdown with no code at all, require code execution to be enabled, and on Team and Enterprise plans can be provisioned to the whole organisation so everyone follows the same procedure.

Where a finished solution belongs

The solutionscorecard, template, procedure

Artifactthe deliverable itself, versioned and shareable
Project knowledgethe template and examples every chat starts from
Project instructionsstanding rules for this body of work
Skilla repeatable procedure Claude loads when relevant

The same scorecard can appear in all three: the document is an artifact, the standing rules live in the Project, the procedure for running and scoring an interview can become a skill.

Skills follow the same iterate-and-test discipline as anything else. Anthropic’s guidance on creating them advises keeping each skill to a single workflow, writing a specific description because Claude relies on it to decide when to invoke the skill, starting with plain Markdown before adding anything more elaborate, and then testing with several prompts and checking whether the skill was actually loaded. If it fires at the wrong times or not at all, the description is usually the thing to change first.

Worked example · A proposal skeleton that stopped being rewritten every time

A four-person sales team writes client proposals from scratch each time. Structure, tone and the security section vary by author, and the security section is the one legal always sends back.

They design once. One proposal is rebuilt as an artifact with a fixed skeleton: situation, scope, approach, team, commercials, security, assumptions.
They test on real deals. Three recent proposals are re-fitted into the skeleton. Two fit; the third, a public-sector bid, needs a section the skeleton has no room for.
They handle the exception explicitly with a marked optional section rather than a second skeleton, because two competing templates is how standardisation dies.
They capture the standing rules — approved security wording, the assumptions that must always appear, the commercial terms that need approval — as Project instructions and knowledge in a shared proposals Project.
They package the procedure as a skill so that “draft a proposal for this opportunity” follows the same steps and structure for whoever asks.
They date it and name an owner, because the security wording will change, and keeping configurations current is a job somebody has to hold. That is 5.4.

Takeaway: The value was not the first good proposal. It was that the fourth author produced the same shape as the first, and legal stopped rewriting the security section.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Asking for a finished solution in one long request	Brief the job, get a rough draft, and refine it in named passes.
Revising with “make it better” or “more professional”	Name the fault, the location, and what should be true instead — and what to leave alone.
Starting a new chat when a draft is nearly right	Iterate in place; the version selector lets you roll back if a change makes it worse.
Polishing a solution that has never seen a real input	Run a genuine case through it before the third revision.
Leaving a working solution in one person’s chat history	Put the deliverable, the standing rules and the procedure where the team can reach them.

You should now be able to

Open a design task with the user, the moment of use, the constraint and the test, and invite clarifying questions.
Build shareable work as an artifact and use versions to iterate reversibly.
Write a revision instruction that names the fault, its location and what must not change.
Test a draft against a real case before polishing it.
Decide whether a finished solution belongs in an artifact, in project instructions and knowledge, or in a skill.
Explain why iterating on a draft usually beats regenerating it.

Designing and iterating a solution