Conversational CodingA Backstory project Install the harness →
Menu

A fast prototype can prove the wrong thing beautifully.

Engineering With AI brings real design rules, relevant professional perspectives and review evidence into the work before a polished screen convinces everybody that the thinking is finished.

One prototype. Several useful challenges.

Can someone understand it?Can everyone use it?Does it fit the product?What happens when it fails?What needs a real user?

The strongest design isn’t the one an agent can generate fastest. It’s the one whose decisions and remaining uncertainties are visible.

AI can create a convincing screen before the team has agreed how it should work.

That speed is powerful, but it changes the order in which mistakes arrive. A beautiful interface can hide an unclear journey, an inaccessible interaction, a missing failure state or a decision that belongs to a product owner.

The harness turns design into a governed conversation. It can extract or author the design system, generate a bounded prototype, select the perspectives most likely to find something useful and keep each review tied to the exact version it examined.

Personas add disciplined challenge. Representative users, accessibility testing, product acceptance and Manual QA still provide evidence that generated viewpoints can’t.

Give the screen a visual language, a job and the right reviewers.

01

Governed design systems

Extract an existing product language or author one deliberately, then pin the approved digest used by the prototype. Colours, type, spacing, components and interaction rules become reusable project evidence rather than prompt decoration.

02

Screen prototype creation

Turn an approved intent and journey into a bounded, reviewable interface without presenting a concept image as implemented software.

03

Relevant persona selection

Choose perspectives because they match the users, risks and domain of this change. A screen reader user, cautious customer, operations lead and privacy specialist will challenge different assumptions.

04

Structured prototype review

Record observations, severity, rationale and proposed changes against the exact prototype and persona source. Suggestions can be accepted, rejected or carried forward without becoming fact by repetition.

05

Provider-neutral review

Use the standard language-model route or an entitled premium pack without changing the evidence contract. The method remains inspectable whichever provider helps with the analysis.

06

Human evidence stays different

A simulated perspective can expose likely friction and improve the next prototype. It can’t prove usability, consent, accessibility or acceptance. The harness keeps those claims for the people and tests that can actually support them.

Illustrative prototype review

Three perspectives. Three reasons to change the screen.

Imagine reviewing a supplier approval screen. The approved intent and design system give it a starting point. The useful feedback explains what a person might struggle with and gives the owner a concrete decision.

Accessibility perspective
“The risk rating is only shown as a colour. How would someone identify it without that cue?”
Change to review

Add a written rating and an accessible label. Test the actual control with keyboard and assistive technology.

Operations perspective
“I can see that approval failed, but not whether it’s safe to try again.”
Change to review

Explain the failed action and its state. Include the retry and recovery journey in the prototype.

Privacy perspective
“Why does an approver need to see all of the contact’s personal details here?”
Decision for the owner

Confirm which fields the decision actually needs. Record the scope before changing the design.

These are simulated review prompts, not feedback from research participants. Record each decision against the prototype version, then test the revised experience with real people. See the review and iteration method →

Questions a pretty mock-up can’t answer on its own.

Whose needs shaped this screen?

The design stays linked to its intent, journey and affected roles, so review starts with a real purpose instead of aesthetic preference.

Is this using the actual product language?

Design-system evidence is extracted, reviewed and digest-pinned. The prototype can be checked against the version it claims to follow.

Did the feedback change anything?

Each review produces traceable findings and decisions. Iteration becomes a visible sequence rather than a replacement image with no explanation.

What must we still test with people?

The review calls out unresolved usability, accessibility and acceptance needs instead of allowing generated confidence to close them.

Make the interface easier to trust before it becomes expensive to change.

Prototype quickly, challenge deliberately and keep the difference between useful simulation and real human evidence clear.