How to Build a Counterfactual Prototype That Tests an Emerging Interface Before the Technology Is Ready

Emerging technologies create an awkward product problem: by the time a capability becomes dependable, its most consequential interface assumptions may already be embedded in the product. Teams wait for the technology, then discover that users do not understand what to delegate, when to intervene, or whether the result deserves trust.

A counterfactual prototype reverses that sequence. It presents users with a carefully simulated version of a capability that does not yet work reliably, while humans or deterministic software perform the difficult parts behind the interface. The objective is not to pretend the technology exists. It is to discover what the product should become if it does.

The concrete outcome of this method is an evidence package: a tested workflow, a map of acceptable autonomy, a record of failure reactions, and a decision about whether to invest, narrow the concept, or stop.

Step 1: Write the Counterfactual as a Testable Change

Begin with one sentence: If this capability became sufficiently reliable, what would a person do differently? The answer must describe changed behavior, not technical performance.

Suppose a team is exploring an assistant that negotiates meeting times across organizations. “An agent that uses calendars” is merely a component description. A useful counterfactual is: “A project lead delegates scheduling to an assistant and intervenes only when a proposed time violates an unstated relationship constraint.”

This sentence identifies three things to test: delegation, intervention, and tacit constraints. It also avoids assuming that full autonomy is desirable.

The common mistake

Teams often frame the experiment around a broad technological claim, such as whether an agent can manage scheduling. That bundles together calendar access, preference inference, negotiation, messaging, and exception handling. A prototype can appear persuasive while revealing nothing about which part creates value.

Narrow the claim until one observed behavior could weaken it. If participants insist on approving every message, for example, the proposed delegation model has failed even if they like the interface.

Step 2: Define the Reality Boundary

Decide exactly which parts will be real, simulated, and deliberately absent. This is the prototype’s reality boundary. Documenting it prevents the team from confusing a polished demonstration with evidence of technical feasibility.

For the scheduling example, use sandbox calendars rather than participants’ live accounts. Let an operator generate proposals according to explicit policies. Draft messages may look real, but they should not be sent to unsuspecting recipients.

The simulation should preserve the conditions that matter to user judgment. If a real system would take several minutes to research constraints, an instant response may create a false workflow. Conversely, forcing users to wait for an operator’s convenience tests operator availability, not product latency.

The common mistake

Hidden human labor is often allowed to perform unlimited reasoning. The simulated product then handles ambiguous requests with a subtlety the future system may never possess. Constrain operators with the same inputs, tools, and decision policies envisioned for the product. Record every moment when they need information the system would not have.

Step 3: Build the Smallest Complete Journey

A convincing screen is not enough. Build one complete journey from intent to consequence. For a delegated scheduling assistant, that journey might be:

1. The user states an outcome: arrange a project review next week.
2. The system shows the calendars, contacts, and preferences it intends to use.
3. The system identifies a conflict between availability and a relationship constraint.
4. The user chooses whether to approve an exception or revise the instruction.
5. The system presents the proposed message and calendar change.
6. The user confirms, edits, or cancels.
7. The interface records what the system should remember next time.

This journey tests more than task completion. It reveals whether users can form an accurate mental model of the system: what it knows, what it is doing, and what remains reversible.

Use realistic artifacts. “Client meeting” is less revealing than “Reschedule the design review with a client whose director dislikes Friday requests.” Specificity draws out social and operational constraints that generic tasks conceal.

The common mistake

Teams usually prototype the ideal path and treat exceptions as later engineering work. Yet exceptions often are the interface. Include at least one missing fact, conflicting instruction, or potentially costly action. The manner in which a product pauses can matter more than how smoothly it proceeds.

Step 4: Design Controls Around Consequence

Do not add approval prompts indiscriminately. Frequent confirmation transfers the work back to the user; absent confirmation conceals risk. Match control to consequence and reversibility.

• Preview: appropriate when users need visibility but the action remains easily reversible.
• Explicit approval: appropriate before external communication, financial commitment, deletion, or reputation-sensitive action.
• Policy control: appropriate for repeated decisions, such as “Never schedule client meetings on Fridays without asking.”
• Undo: useful only when reversal is genuinely possible; it cannot retract a message already read.
• Escalation: appropriate when information conflicts or confidence is insufficient.

Instrument every control. Record what triggered a pause, what information the participant inspected, what they changed, and whether they understood the consequence. The aim is not to maximize approvals. It is to locate the boundary at which independent action becomes unacceptable.

The common mistake

A single confidence score is often used as a substitute for intelligible control. “Confidence: 72%” does not tell a user whether the uncertainty concerns a date, a recipient, or a social inference. Expose the object of uncertainty: “The client’s time zone is missing” produces an actionable decision.

Step 5: Run Sessions That Produce Behavioral Evidence

Recruit participants who actually perform the target work. Give each participant a scenario, an objective, and realistic constraints. Avoid explaining the intended interaction. If the interface requires coaching, that is evidence.

Ask participants to work through the journey while thinking aloud. The facilitator should use neutral prompts: “What do you expect to happen?” and “What would you need before allowing this?” Do not ask whether they like the concept. Approval is cheap; delegation under consequence is informative.

Capture evidence in four categories:

• Comprehension: Could the participant predict the next action?
• Delegation: Which decisions did they willingly hand over?
• Intervention: Where did they inspect, edit, or stop the process?
• Adaptation: Did they create a reusable rule, or merely correct one output?

After the task, reveal which parts were simulated. Ask whether that knowledge changes their judgment. This debrief is ethically necessary and often exposes assumptions about reliability, privacy, and accountability.

The common mistake

Teams count successful task completions while ignoring rescue work. If an operator silently resolves ambiguity, the participant appears to succeed without encountering the system’s real limitation. Mark each intervention in the session record and replay it during analysis.

Step 6: Convert Observations into a Build Decision

Review the sessions by decision point, not by participant. Place every moment of delegation, hesitation, correction, and refusal along the same workflow. Patterns will reveal where the product should automate, ask, explain, or abstain.

Create a short evidence ledger with four columns: observed behavior, probable cause, product implication, and unresolved technical dependency. An entry might read: “Participants approved time selection but rewrote external messages; wording carries relationship risk; separate scheduling authority from communication authority; test whether constrained message templates are acceptable.”

Then choose one of four outcomes:

• Advance: users delegate the target decision, understand controls, and derive meaningful value.
• Narrow: value exists, but only within a smaller authority boundary.
• Reframe: the capability matters, but the proposed workflow or user is wrong.
• Stop: users retain the work because delegation adds oversight, anxiety, or unacceptable risk.

The decisive question is not whether the simulated experience impressed participants. It is whether the experiment identified a stable unit of delegation that future technology could responsibly support.

The common mistake

Enthusiasm is frequently promoted into validation. A participant may admire an autonomous concept yet refuse to use it with real clients. Weight consequential behavior above stated preference. A narrowed product that drafts options for approval may be more valuable—and more buildable—than the autonomous vision that inspired it.

Step 7: Preserve the Prototype as a Future Specification

Do not discard the prototype after the sessions. Package the interface states, operator rules, intervention log, edge cases, and evidence ledger together. This becomes a behavioral specification for technical experiments.

Each operator action can now become a capability test. If operators repeatedly infer relationship sensitivity from past messages, the engineering team has a precise research question: what evidence is available, what inference is permissible, and how should uncertainty be surfaced? If participants always approve routine internal changes, that path may deserve automation first.

The finished artifact is therefore more than a mock product. It is a disciplined bridge between possibility and implementation. It reveals where intelligence creates leverage, where judgment must remain visible, and which technical advance would genuinely change what people are prepared to entrust to a machine.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.