Make your AI prototype easy to disagree with

A familiar interface can still answer the wrong question

GitHub released Replica as an open-source AI prototyping tool on October 28. Created by GitHub Design, it uses a team’s components, patterns and documentation to guide interactive prototypes. The announcement describes local prototyping and an optional self-hosted Hub for sharing and comments. It is available under the MIT license.

That is a useful shift from asking a model to invent an interface’s visual language every time. But matching your buttons and menus is only one kind of correctness. A prototype can look like your product while teaching you almost nothing about whether people understand the proposed feature.

Our interpretation is that faster prototyping increases the value of choosing a sharper question before generation. If making another screen becomes easier, the scarce resource is the attention of the person trying it. You want that person to encounter a meaningful choice, not tour a convincing picture of your idea.

Imagine a small creative team building a media library. The proposed feature lets someone narrow a folder to clips that are ready to publish. An attractive prototype might demonstrate a filter panel and several pleasing cards. A useful experiment would reveal whether people understand what ready means and can find the exceptions.

This article proposes a way to design that experiment. We have not tested Replica, evaluated its generated interfaces or measured user outcomes. The release provides the occasion; the methods below are our suggested workflow for making a prototype easier to question.

Source: GitHub: Introducing Replica ↗ · GitHub: Replica repository, setup and data handling ↗ · W3C: Modal Dialog Pattern ↗ · W3C: Validating Input ↗ · Product Management’s Sacred Seven: Official contents ↗

Write the disagreement before the prompt

Start with one assumption that could turn out to be wrong. For the media library, it might be that people interpret ready as approved for publication. That is more testable than saying the feature should be intuitive. Someone may interpret ready as exported, fully captioned or simply saved without errors.

Write a competing explanation beside it. Perhaps users need separate approval and technical-status controls. Perhaps the folder’s owner already communicates readiness through filenames, making another filter redundant. A prototype should help distinguish these possibilities rather than hide them behind a single successful path.

Choose a small task that exposes the difference. Ask a participant to find a clip that can be posted today, given a short scenario. Include a clip that is technically exported but awaiting approval and one that is approved but missing captions. Use fictional content with no private assets or real publication consequences.

Decide what you will watch. Did the participant inspect status details? Did they choose the first polished thumbnail? Did they ask what ready meant? These observations are more useful than a general question about whether they liked the interface. A positive reaction can coexist with a wrong selection.

Also write what would change your mind. If participants consistently misunderstand the combined status, you will separate the concepts or change the language. If they complete the task and explain the distinction accurately, you have a reason to continue. You have not proved the feature works for every person or situation.

Give the model a behavior boundary

A design system describes reusable choices, but your prompt still needs to state which behaviors the experiment includes. Name the existing components to use, the task’s starting state and the actions that should have visible effects. Tell the model what is deliberately simulated.

For the media example, a bounded brief might request one folder, six fictional clips, a filter control and a detail panel. Each clip gets a technical status and an editorial approval status. Selecting a filter changes the visible list. Opening details reveals the same underlying values rather than fresh invented information.

Keep the data consistent across views. If a card says approved while its details say awaiting review, a participant’s confusion may reflect a broken prototype rather than a confusing product concept. You need enough fidelity for the question to be fair, even if everything else is plain.

Avoid adding a working upload service, authentication system or live publishing action just to make the prototype feel complete. Those capabilities create extra assumptions and review work. For this experiment, a clearly labeled simulation can show the decision without being allowed to distribute real media.

Ask for an explicit account of what is mocked. Review it against the interface. A disabled button should look and behave differently from a button that appears to succeed but only changes a local variable. The person testing the prototype should understand when their action has no real-world effect.

Include the states that interrupt a demo

A showcase naturally gravitates toward full data and successful actions. Your experiment needs the states most likely to reveal misunderstanding. Consider an empty result, conflicting filters, a missing field and an unavailable action. You do not need a hundred edge cases; choose the ones connected to your assumption.

For example, a filter labeled ready might return no clips. Does the interface explain that the folder contains approved clips with incomplete technical requirements? Or does it imply the folder is empty? Those messages lead to different next steps. Make the distinction visible in the prototype.

If the participant changes filters, preserve enough state to understand the result. A panel that silently resets selections after closing may produce an attractive animation while sabotaging the task. Observe whether people can predict what will remain selected when they return.

Use accessibility guidance as a behavioral reference rather than a decorative checklist. W3C’s modal-dialog pattern describes containing keyboard focus within an open modal, providing a way to close it and returning focus appropriately. If your prototype uses a modal, inspect those interactions before inviting someone to test it.

W3C’s form-validation guidance also explains identifying errors and helping users correct them. For a filter with incompatible choices, a visible explanation is more informative than a mysterious empty grid. These checks do not constitute a full accessibility audit. They prevent obvious interaction failures from distorting your narrow experiment.

Let the task speak before the pitch

When someone tries the prototype, explain the fictional situation and give the task without narrating your intended route. If you tell them which filter to choose, you have removed the uncertainty you wanted to study. Save the feature rationale until after the first attempt.

Invite the participant to describe what they think each status means. Do not treat their explanation as a vocabulary exam. The product’s wording is the thing under examination. If their interpretation is reasonable but differs from yours, that is information about the design.

Record behavior and interpretation separately. Someone may reach the intended clip by chance, then explain readiness incorrectly. Someone else may understand the status but get stuck because the close control is inaccessible. Counting both as success or both as conceptual failure would conceal the useful distinction.

Keep your notes descriptive. Write that the participant opened three cards before finding approval status, rather than declaring the layout confusing. The description leaves room for different fixes. Maybe the label belongs on the card; maybe the task needs a different filter; maybe the selected scenario was unclear.

At the end, ask what they expected to happen after the final action and what information they still needed. These questions expose gaps the happy path leaves invisible. Avoid asking whether they would use the feature as if a polite hypothetical answer were evidence of future adoption.

Preserve versions so feedback has an address

AI makes it tempting to modify the interface after every comment. That can be productive, but only if you know which version produced each observation. Otherwise, feedback from different designs gets blended into an imaginary design nobody actually tried.

Give each meaningful version a short identifier and a one-sentence change description. Version A uses one combined status. Version B separates approval and technical readiness. Version C keeps the split but moves the explanation. Preserve the fictional data and task when comparing the same assumption.

Replica’s repository documents local prototyping and optional Hub sharing, with additional setup requirements for hosting. Pick the smallest supported route for your actual team. You do not need to operate a shared service to learn whether one person understands a filter.

The repository also distinguishes Hub activity from activity inside previews and notes that selected AI providers have their own data terms. Do not infer that self-hosting keeps every part of the workflow local. Review the services involved before adding real project material, and use fictional assets for the initial experiment.

If you share a link, attach the task, version identifier and simulation limits beside it. A reviewer who opens the prototype without those details may judge the wrong question or mistake a stub for an intended feature. Clear context makes asynchronous feedback far easier to interpret.

Keep product thinking larger than the generator, then run one compact test

A prototype is one instrument in a product decision. It can help you observe comprehension, but it cannot tell you on its own whether the problem is frequent, whether another workflow already solves it or whether supporting the feature is worth the cost. Keep those questions visible.

For broader reading, Product Management’s Sacred Seven (affiliate link) is an optional companion; its official contents page includes product design, problem selection and hypothesis testing. You can do this exercise without buying anything by writing the assumption, task and decision rule on paper.

As an Amazon Associate I earn from qualifying purchases. This optional recommendation is not a claim of hands-on testing.

That contents-based description is not a claim that the book validates our experiment or explains Replica. The lesson here does not depend on a purchase. It depends on separating a visually plausible solution from evidence about the problem it is meant to solve.

In the media-library example, an interface test might show that people understand separate status labels. You would still need evidence that the distinction matters often enough to justify a permanent feature. Perhaps the team only faces that problem during one annual event, where a simpler checklist would be sufficient.

Make room for a decision to stop. If a prototype exposes a weak idea before implementation, it has done useful work. The number of generated screens is not the outcome. The outcome is a better-supported choice about what deserves further effort.

Give yourself one session to prepare a small, consistent prototype. Write a single assumption and an alternative. Create six fictional records, including a few that separate the concepts you are testing. Generate the minimum interface that supports the task, then verify its basic behavior yourself.

Next, have a person who did not help build it attempt the task. One participant is a way to uncover problems, not a representative study. Preserve their observations and the prototype version. Do not report percentages from that encounter or turn a successful attempt into a market claim.

Make one revision tied to a specific observation. If the participant could not distinguish approval from export status, change that relationship. Avoid simultaneously rewriting every label and rearranging the entire page. You want to know what the revision was intended to improve.

Try the task again with fresh eyes when possible. Compare the explanation and the route taken, not merely the time on a stopwatch. A slower attempt with a correct understanding may be more promising than a fast guess that happens to land on the right card.

End with an annotated decision: continue, revise or abandon this approach, and why. Include the biggest uncertainty left over. That small record helps the next teammate understand what the prototype established and what it did not.

Replica’s release offers a route to prototypes grounded in an existing design system. The opportunity is to use that familiarity to focus attention on the uncertain behavior. Make the next version clear enough to try, bounded enough to inspect and specific enough that someone can show you where your assumption fails.