Prototyping with Claude Artifacts: What a Week of Iteration Taught Us

A clickable prototype built in Claude got four different teams to agree on a new product concept in about a week. No engineering sprint, design handoff, or staging environment were necessary.

The product is a pre-visit tool for a contraceptive care platform. It helps patients prepare for a birth control appointment: pick a starting point, learn about the methods or concerns that matter to them, save questions for their provider, and leave with a summary they can email to their provider or download to their device. It has four entry paths, branching logic, conditional messaging, and a provider-facing summary at the end.

That is a lot of behavior to explain with static screens. So instead of describing it, we built it as a Claude artifact: a single interactive page anyone on the team could open from a link, tap through, and react to.

One prototype, four audiences

The prototype’s biggest win was that every team could evaluate the same thing at the same time, each through its own lens.

• Marketing saw the voice and tone in context. Headings, button labels, and the way a patient’s own choices are reflected back to them read differently on a live screen than in a spreadsheet cell.
• Clinical reviewed method information where a patient would actually encounter it. When we swapped in revised overview copy for all 19 contraceptive methods, clinicians could check every one in place, in the flow, in a single pass.
• Engineering saw the logic before writing any of it. Conditional telehealth messaging, dynamic headings that fill in a patient’s selection, provider questions that save and update, and a summary that accumulates across topics all turned into concrete questions for our technical kickoff.
• Research got something they could put in front of user research participants immediately. A clickable flow tests comprehension and navigation in a way a deck of screens cannot. Before the prototype, each of these conversations would have needed its own artifact: a copy doc, a clinical review sheet, a technical spec, a research script. The prototype gave everyone a shared reference point, so feedback from one team showed up where the others could see it.

Why it works best alongside wireframes

The prototype did not replace our wireframes. It made them more useful.

Our Figma wireframes and user flow diagrams show the full map: every screen, every branch, every decision point, and what is still unbuilt. The prototype shows what it feels like to move through that map. Reviewers who got lost in a flow diagram could tap through the prototype to see a path in action, then go back to the diagram to see where it sat in the whole.

The two also kept each other honest. Design direction moved from Figma into the prototype: we shared screenshots of the new educational screens, and Claude rebuilt them in the prototype with live data. Behavior moved the other way. When the prototype gained a new loop, such as letting patients explore another topic and return to a growing summary, we had Claude update the flow diagram to match. Changes were highlighted, existing reviewer comments were preserved, and anything the prototype could not yet do was called out rather than quietly dropped.

Wireframes answer “what is in scope.” The prototype answers “does this make sense to a person using it.” You need both, and keeping them in sync is far cheaper when the same assistant can read and update each one.

What we learned from a week of iteration

Most of the value came from dozens of small requests, not one big build. These are the habits that made that work.

1. Start from a source of truth: The prototype was built from a screen-by-screen matrix spreadsheet covering every screen, its copy, and its answer choices. When the spreadsheet, the prototype, and the Figma export drifted apart, we asked Claude to list the mismatches without fixing anything. Then we approved the fixes we wanted and deferred the rest. A prototype with no source of truth becomes the source of truth by accident.

2. Give every screen a name: Screens had short IDs like K4, C2, and U2. That gave us a precise shared vocabulary. “Add a free-text question box to K4, then replicate it on C2” is unambiguous to Claude, to designers, and to engineers reading the ticket later.

3. Ask for one change at a time: Small, scoped requests were faster and safer than long lists. Remove a button. Move the close icon into the header. Make videos non-clickable everywhere. Each change was easy to review, and nothing unrelated shifted along with it.

4. Make placeholders announce themselves: Unfinished content should look unfinished. Tapping a video opened a note saying it was a placeholder. Typing a question to the chatbot returned a reply saying it was a placeholder. Sections waiting on copy read “[Informational text to come].” Reviewers never mistook a stand-in for a decision.

5. Remove anything that looks clickable but isn’t: We removed 21 decorative close buttons that did nothing. Later we turned off video clicks entirely. Dead controls generate feedback about the prototype instead of the product.

6. Let the prototype use real logic: The screens that convinced people were the dynamic ones. Educational screens filled in the method or concern the patient had chosen. The telehealth message appeared only for eligible methods. A small amount of real behavior makes a prototype feel like a product, not a slideshow.

7. Publish once, update in place: We published the prototype as a single shared page, and every revision went to the same link. Nobody had to ask which version was current, and we never had to reshare.

8. Expect Claude to flag, not guess: The most useful responses ended with a short list of things to decide. A likely typo in new method copy was left as written and pointed out. A feedback survey that existed in the flow diagram but not in the prototype was flagged as a gap instead of being silently added or removed. Asking for that behavior explicitly kept us in control of every product decision.

Next: putting it in front of patients

The same prototype is about to become our user research instrument.

In healthcare, final content takes time. Clinical copy needs review, videos need production, and the chatbot’s responses need sign-off before a patient ever sees them. Waiting for all of that before testing would push research months down the road, past the point where findings could still shape the design.

The prototype lets us test now. Placeholder content stands in for what is still pending, and the structure around it is real: the entry paths, the order of screens, the way questions are saved, and the summary a patient takes to their visit. Those are exactly the things research needs to validate. Do patients understand where to start? Do they find the questions they care about? Does the summary feel worth bringing to a provider?

As approvals and decisions land, the official content drops into the same prototype on the same link. Research findings and content approvals can move in parallel instead of in sequence.

The takeaway

A Claude artifact will not replace design or engineering. What it does is close the gap between an idea on paper and something a team can react to. For us, that meant one shareable link that marketing, clinical, engineering, and research could all use, kept in step with our wireframes and ready for patients before the final content exists.

If you are scoping a product with complex logic and many stakeholders, build the clickable version early. Keep it tied to a source of truth, make the placeholders obvious, and let every team look at the same thing.