Home › Study guides › CCAO-F › Domain 4 › Lesson 4.3
CCAO-F · Domain 4 · 16% of the exam · Lesson 4.3 · 20 min read
Designing, prototyping and iterating with Claude
How to use Claude to compare design options, critique your favourite, prototype with artifacts, iterate with real users, and know when IT must take over.
Written against objective 4.3 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.
4.3.1 Why the first plan is not the design
Leonie Hale is the training coordinator at Orrinford Health, a network of four hospitals and a dozen clinics. She onboards the administrative staff, from registration clerks to HR assistants, not the clinical teams. Today's onboarding is a welcome morning of slides and a 60-page handbook. It isn't working: in the last staff survey, a third of new hires still had no system login at the end of week two.
She opens Claude and types: "Design a better onboarding programme for our new administrative staff." A minute later she has a polished two-week plan: a Monday group induction, a buddy for every new hire, daily e-learning and a check-in on day 30. It's clear, well organised and confident.
It is also built on guesses. Orrinford hires start on any weekday, registration desks run around the clock so some people start on an evening shift, and last year two site managers refused to release staff as buddies. Claude did what it was asked; one request gets one design, with nothing beside it to show what it gives up.
So the skill is using Claude across a whole design cycle, not for one answer. Claude lays out several options with their trade-offs, argues against your favourite and builds a quick prototype for real people to try. You run the rounds of testing and changing, called iteration, make the decisions, and know when the work must pass to the people who build real systems.
One answer versus a design cycle
One answer, accepted
A design cycle
4.3.2 Ask for several designs and what each gives up
How do you know a design is good when it's the only one you've seen? You don't. Every design trades something away, and you only notice the trade when another option makes a different one. It's like viewing three flats before renting one: the second and third show you what you actually care about. So ask Claude for several genuinely different options, each with its trade-offs.
Judge them against criteria taken from the requirements you've already gathered; Leonie's are the second paragraph of her prompt. Now look at the last two paragraphs. They ask for designs that really differ, for when each one fails, and for no winner yet.
I'm redesigning the first week of onboarding for new administrative staff at a hospital network: registration, medical records, scheduling, finance and HR assistants. Clinical staff are out of scope.
What must be true by the end of week one: every new hire has their system logins, has finished the mandatory privacy and fire-safety training, and knows whom to ask for help at their site.
Constraints: people start on any weekday across sixteen sites, some on evening shifts. The training team is two people. There is no budget for new software this year.
Give me three genuinely different designs, not variations of one. For each: how it works in two sentences, when it works well, and when it fails: for whom, and at what cost to them or to the training team.
Don't pick a winner. I'll decide with the site managers once I've seen the trade-offs.
| Design | Works well when | Fails when (for whom, at what cost) |
|---|---|---|
| Monthly group induction | Many people start in the same few days | Mid-month starters wait up to three weeks; evening starters miss it |
| A buddy for every hire | Each site has experienced staff with time to spare | Busy sites can't release buddies, so quality varies by site |
| Self-guided first week | Start days and shifts vary widely | A quiet new hire can fall behind unnoticed; the welcome feels less personal |
That is Claude's reply, condensed. Memorise its shape, not its rows: every option needs a "fails when" column, and an option without one hasn't been examined yet.
Claude's comparison is input, not a verdict. Leonie knows things it doesn't, such as last year's refusal over buddies and which sites are short-staffed. After talking it through with the site managers, she chooses a self-guided first week with a named contact at each site. The head of learning and development, who owns onboarding, agrees to a pilot.
4.3.3 Attack your favourite before your users do
Once you've picked a design, it's natural to stop looking for its problems. The usual question to Claude, "Is this a good plan?", makes that worse: it invites a general review, and praise feels like a check. What you need is the opposite exercise, called red-teaming: deliberately arguing against a design to find out how it breaks. Think of it as a fire drill. You want to find the blocked exit during the drill, not during the fire.
Leonie asks Claude to argue against her choice by walking through the first week as specific people in hard cases. She names two: an evening starter at the smallest clinic, and a new hire whose site contact is on leave. Three weak points come back. Evening starters may not reach the IT desk to activate a first-day login. A clinic's only named contact could be away in someone's first week. And a checklist can be ticked without the task being done.
Asking for a review versus asking for failure
"Is this a good plan?"
"How does it fail, for whom?"
These are risks to check, not findings, because confidence is not evidence. Leonie takes each one to someone who knows. IT tells her the service desk has a night line, so the first risk shrinks to making sure the checklist gives that number. Clinic managers confirm the second, so the design gains a backup contact. The third she accepts for now and plans to watch in the pilot. Without these checks, she might have redesigned around a problem that doesn't exist.
4.3.4 Prototype it, so people react to something real
Why build anything before the design is settled? Because people can't reliably react to a description. Tell a new hire "you'll have a self-guided checklist" and they'll nod; hand them one and within a minute they'll point at the item they don't understand. A prototype is a quick, rough, working version of one piece of a design, built to learn from rather than to launch. It's the cardboard model, not the building: solid enough to walk around and point at problems, never meant to be lived in.
Artifacts make prototypes cheap. An artifact is anything Claude makes that you'd put in front of someone. It can be a document, a mock-up of a screen, or a small interactive tool such as a checklist, a quiz, a simple calculator or a form. It opens beside the conversation, and you change it by asking. Artifacts work on every plan, including Free, once the code execution and file creation capability is switched on.
Leonie builds two: an interactive first-week checklist and a ten-question quiz on the essentials. Her brief follows Anthropic's advice to describe the end user, and it keeps the prototype a prototype: tasks from her outline only, placeholders instead of real details, nothing asked of the user.
Build an interactive first-week checklist as an artifact. It's a prototype for a pilot with about eight new hires, not the finished tool.
Who uses it: new administrative staff at a hospital network in their first five days, often on a shared desk computer, some starting on an evening shift. Many have never worked in healthcare.
Content: group the items by day. For each item, show what to do, why it matters and whom to ask if it goes wrong. Use the attached first-week outline as the only source of tasks.
Use placeholders such as [SITE CONTACT] and [IT NIGHT LINE] instead of real names or numbers. Don't ask the user for any personal details.
Keep it simple: tick boxes, a progress bar, and at the end of each day the question "What was confusing today?" for the new hire to answer at their check-in.
The quiz needs one extra step. Claude drafts the questions from the handbook she attaches, and Leonie checks every answer against it, because a quiz that teaches the wrong way to report a privacy concern is worse than no quiz. Sharing needs a check too: anyone who opens a shared artifact needs a Claude account, and on Team and Enterprise plans artifacts stay inside the organisation by default. Orrinford's administrative staff have accounts on the network's plan, so the pilot group can open both.
4.3.5 Iterate with real users, and write down why
Who should judge the prototype? Not Claude, and not you. You both know too much: you know that "IG training" is the privacy course, and Claude copied the abbreviation straight from your outline. The people who can tell you whether it works are the ones it's for, and they need to be representative, covering the hard cases as well as the easy ones. Leonie's pilot group is eight new hires starting over two weeks at one hospital and one clinic, three of them on evening shifts.
Round one teaches her things nobody predicted: day one is too long, the abbreviations baffle people, and one quiz question splits the group because supervisors teach a newer reporting route than the handbook. Claude helps her sort the pilot notes, with names taken out, into themes with counts, and she checks the grouping against the notes themselves. What to change is her call, and the quiz question goes to the privacy officer, who owns that procedure.
From here, iteration is a loop: change what the evidence points at, then retest. Use new people where you can, since round-one testers already know the old version's quirks. Keep a copy of every version users saw, labelled "pilot v1" and "pilot v2", because feedback only makes sense next to the version that caused it. And keep a short decision log, a running record of what changed, why, and who decided.
One iteration cycle
The log takes minutes to keep. Look at the end of each entry: a reason drawn from the pilot, and the person who decided.
Onboarding redesign: decision log
Pilot v1 to v2, 14 October. Day one cut from 14 items to 8; the rest moved to day two. Why: 5 of 8 pilot users stopped before item 9. Decided by: Leonie, agreed with site administrators.
Pilot v1 to v2, 14 October. Abbreviations spelled out ("IG training" becomes "information governance (privacy) training"). Why: 6 of 8 asked what a term meant. Decided by: Leonie.
Pilot v1 to v2, 15 October. Quiz question 4 rewritten to the current procedure; the handbook page was out of date. Why: 3 of 8 had been taught the newer route. Decided by: privacy officer.
Open: a backup contact for each clinic. Waiting on: clinic managers, by 25 October.
Round two, with a fresh group, goes better: everyone has their logins by day two. As Anthropic's AI Fluency course puts it, Claude helps you refine, but you decide what to keep, change or discard, and you own the result.
4.3.6 Know when a prototype has to become a real system
The round-two testers ask whether the checklist could show their own start date, site and manager, and tick itself when IT activates their login. HR asks to see who has finished the mandatory training. The head of learning and development wants it for every administrative hire, about four hundred a year. Each request sounds like a small next step. Together they change what the thing is.
| Signal | Still a prototype | Now a real system |
|---|---|---|
| Data | Sample content and placeholders | Real employee records |
| Users | A pilot group of eight | Every new hire, all year |
| Connections | None | Reads from and writes to the HR system |
| Security and privacy | Nothing sensitive in it | Access control and a privacy review |
| Upkeep | You change it after each round | Someone owns fixes, updates and access |
Learn the five signals: any one of them in the right-hand column means the next step belongs to people who build and run systems.
At that point, Leonie's role changes from builder to supplier. The connection to the HR system goes to Orrinford's IT team and, in organisations that have them, to Claude Developers and Architects. It's tempting to wire the checklist up herself with Claude's help, since on paid plans an artifact can use apps you've connected to Claude. But everyone who opens a shared artifact goes through their own connections. That is personal access, not a link between the HR system and every new hire's record that someone secures and maintains.
She hands over what the builders need: the requirements, the prototype as a working example, the pilot feedback and the decision log. One decision stays with a person throughout: approval before rollout. The head of learning and development signs off the redesign on the evidence from both rounds. Claude can draft the handover note and the case for sign-off, but the approval belongs to someone who will answer for it.
4.3.7 The exam traps
Most traps in this objective either stop the design cycle too early or run it too far.
- ✗ Taking Claude's first design as the design. ✓ Ask for several different options with their trade-offs, judged against your criteria.
- ✗ Letting Claude pick the winner and adopting it as is. ✓ Treat the comparison as input and decide with the process owner, using what Claude doesn't know.
- ✗ Asking "is this a good plan?" and taking the praise as a check. ✓ Ask how it fails, for whom and at what cost, then check each risk with the people who know.
- ✗ Rolling a prototype out to everyone because it worked for the people who built it. ✓ Pilot with representative users, change, retest, and get the owner's approval before rollout.
- ✗ Scrapping the design because the pilot found problems. ✓ Finding problems is what a pilot is for. Fix what the evidence points at and retest.
- ✗ Growing the prototype into the real system yourself, with real data and connections. ✓ Hand it to IT or Claude Developers with the requirements, the prototype, the pilot feedback and the decision log.
A prototype worked in a small test. What next?
4.3.8 Put it together: take a design from options to a tested prototype
You now have the whole cycle. Options and a critique come before you commit, a prototype gives real users something to react to, every change is logged, and five signals tell you when to hand over. The quickest way to feel it is to run a small cycle on your own work, then take one ingredient away.
A tested prototype is not yet a working process. Integrating Claude into existing workflows (4.4) is about where a solution like Leonie's sits in the team's day: which steps Claude supports and where people take over. Communicating Claude's value and limitations (4.5) turns pilot evidence and a decision log into an honest case for the people who approve and fund the change.
Key takeaways
- ✓ A single plan from Claude hides what it gives up; ask for several different options with when each one works and when it fails.
- ✓ Claude's comparison is input: you choose, with the process owner, using what Claude doesn't know about your organisation.
- ✓ Red-team your favourite by asking how it fails, for whom and at what cost, and check each risk with the people who know.
- ✓ A prototype, often an artifact, is a quick working piece of the design built to learn from, with sample content and no real personal data.
- ✓ Iterate with representative users: test, change and retest, keeping each tested version and a decision log of what changed, why and who decided.
- ✓ Real data, many users, connections, security or upkeep mean a real system: hand it to IT or Claude Developers with requirements, prototype and feedback.
- ✓ An accountable owner approves the design before rollout; Claude can draft the case but not sign it.
Check your understanding
4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.
60 CCAO-F questions on Domain 4, free
Every question in the bank is tagged to a domain, so you can drill 60 questions on Workflow Integration and Solution Design alone, or sit the full 60-question timed simulator.
Open the CCAO-F question bank → Back to Domain 4 →
The question bank is free. It asks for an account only because the quiz engine has to store answers to score them and show which domains are weak. The questions on this page need nothing.