Embodied Human Proxy Evals for AI-Generated Interfaces

[yaelcorrales3]

GPT-5.6-sol offers:

AI systems are becoming capable of generating complete interfaces and operating computers. However, an AI agent is often a poor judge of whether the resulting interface is actually usable by humans.

An agent may read an entire screen instantly, remember every detail, know undocumented search operators, understand ambiguous icons, inspect the DOM, and patiently complete a twenty-step procedure. Its success proves that a task is technically possible, not that the interface is human-friendly.

I propose a new class of evaluators: Embodied Human Proxy Evals — independent, human-calibrated AI models that interact with software through virtual eyes, hands, and input devices while operating under realistic human constraints.

The objective is not to claim that these models possess genuine human consciousness or emotions. The objective is to make their observable behavior predict the behavior of real people: what they notice, where they click, how long they hesitate, what they misunderstand, when they become frustrated, and when they abandon the task.

How This Idea Emerged

The idea began with a frustrating but amusing conversation about Gmail.

I asked Google Gemini how an ordinary Windows user could perform several seemingly basic tasks in Gmail:

• Mark every unread email as read.

• Sort or navigate messages by date.

• Save all messages matching a search query to a local computer.

Gemini explained that marking all unread messages as read required entering the search operator is:unread, selecting the messages on the current page, finding a secondary “select all matching conversations” link, and then locating the correct toolbar icon.

For saving multiple search results, Gemini suggested creating a label, applying it to all matching conversations, opening Google Takeout, exporting only that label, downloading an MBOX archive, and installing another application to read it. Another proposed solution involved installing Thunderbird and downloading the messages through a third-party email client.

These answers may have been technically plausible, but they also demonstrated the problem perfectly.

A sufficiently capable AI can navigate such procedures because it knows the documentation, remembers hidden operators, recognizes obscure icons, and never becomes tired of a multi-stage workaround. An ordinary user may simply conclude that the expected function does not exist.

When I pointed out that a typical home user would never guess that they needed to type is:unread, Gemini agreed that this represented a usability failure.

This led to a joke: perhaps Google should employ a virtual human who turns on a virtual Windows PC, makes virtual tea, sits in a virtual chair, uses a virtual mouse and keyboard, looks at a virtual monitor, and experiences virtual disbelief while trying to use Gmail.

The joke revealed a serious engineering question:

Who evaluates an AI-generated interface from the user’s point of view when both the generator and the evaluator are non-human systems with superhuman knowledge, attention, memory, and patience?

The Core Problem

Current AI agents are frequently optimized to complete tasks at almost any cost. This creates several problems when they are used as UX evaluators.

1. Technical success is confused with usability

If an agent completes a task after seventeen actions, three searches, and a hidden menu, the evaluation may record a success.

A human user may have abandoned the task after the third action.

2. Agents possess hidden advantages

Depending on the evaluation environment, an agent may have access to:

• DOM structure and semantic element names.

• Accessibility-tree descriptions unavailable to a sighted user.

• Documentation and search results.

• Vast working memory.

• Near-perfect text recognition.

• Unlimited patience.

• Prior knowledge of product-specific commands.

• Precise clicking without normal motor errors.

These capabilities make the agent an excellent automation system but a poor simulation of an ordinary person.

3. The generator and evaluator may share the same blind spots

If one model generates an interface and a closely related model evaluates it, both systems may interpret the same ambiguous icons and layouts in the same way.

The evaluation then becomes circular: the system understands the interface because it resembles the system that created it.

4. There is no single “average human”

Users differ by age, language, culture, technical experience, device, vision, motor ability, attention, expectations, and personal preference.

A single synthetic user would merely replace one unrealistic abstraction with another.

The Proposal

Create a population of independent Embodied Human Proxy Evaluators.

These models would interact with a product through the same observable channels available to real users. They would be calibrated against real human behavior and deliberately prevented from using superhuman shortcuts.

1. Pixel-first, black-box interaction

By default, the evaluator should see only the rendered interface.

It should not receive:

• DOM element names.

• Internal component identifiers.

• Hidden descriptions.

• Product specifications.

• The designer’s intentions.

• Instructions explaining where the relevant control is located.

If a user must discover a function visually, the evaluator must also discover it visually.

Separate evaluator profiles could represent screen-reader or keyboard-only users, but those profiles should receive only the information actually available through the corresponding accessibility technology.

2. A virtual body

The model should operate through simulated human input channels:

• Eyes with a limited field of attention.

• A mouse with realistic movement and targeting.

• A keyboard with realistic typing behavior.

• Touch input on mobile devices.

• Scrolling, zooming, window management, and focus changes.

• Optional profiles representing different visual or motor constraints.

The important feature is not graphical decoration around the model. The virtual body must impose meaningful perceptual and motor limitations.

3. Human cognitive constraints

The evaluator should have configurable limits for:

• Working memory.

• Reading speed.

• Visual attention.

• Recall of previously visited menus.

• Familiarity with product conventions.

• Tolerance for repeated failure.

• Willingness to consult documentation.

• Confidence in uncertain actions.

Most importantly, the evaluator must be allowed to fail.

It should be able to report:

• “I cannot find the function.”

• “I do not understand this icon.”

• “I think this action may delete my data.”

• “I would search the web for help.”

• “I would ask another person.”

• “I would abandon the task.”

An evaluator that is rewarded only for eventual completion will never behave like a real user.

4. A population rather than one persona

The evaluation should run across a diverse synthetic panel, for example:

• A technically experienced desktop user.

• A person accustomed primarily to mobile applications.

• A first-time user.

• An older user.

• A user with limited vision.

• A keyboard-only user.

• A user unfamiliar with the interface language.

• A cautious user handling important data.

• An impatient user performing a routine task.

These profiles must be calibrated using observations from real participants rather than stereotypes invented in prompts.

The output should be a distribution of likely behavior, not the opinion of a fictional “average user.”

5. Independence from the generating system

The evaluator should be organizationally and technically separated from the interface generator.

It should not know:

• Which model generated the interface.

• What the intended interaction path was.

• Which design choices the generator considers important.

• What answer would please the development team.

Where possible, evaluations should use different model families, independent reward functions, and blinded task descriptions.

Suggested Evaluation Workflow

1. An AI system or human team generates an interface.

2. An evaluation coordinator defines user goals in natural language without explaining how to accomplish them.

3. A panel of embodied proxy users attempts each task through the rendered interface.

4. The system records behavior, including:

   • Time to first relevant action.

   • Task completion rate.

   • Number of incorrect actions.

   • Repeated actions.

   • Backtracking.

   • Help-seeking behavior.

   • Misinterpretation of labels and icons.

   • Abandonment rate.

   • Confidence before consequential actions.

5. The results are compared with data from real human participants.

6. The proxy models are recalibrated when their predictions diverge from human behavior.

7. The interface is revised and evaluated again.

8. Human UX testing remains the final validation step.

What Should Be Measured?

A useful system should predict measurable human outcomes rather than merely produce persuasive commentary.

Possible metrics include:

• Task success rate.

• Time-to-completion distribution.

• Error rate.

• Number of unnecessary actions.

• Feature discoverability.

• Frequency of opening the wrong menu.

• Probability of seeking external help.

• Probability of abandoning the task.

• Confidence and hesitation around destructive actions.

• Differences between user populations.

• Accessibility failures.

• Preference between alternative layouts.

• Correlation between proxy predictions and real human test results.

A proxy evaluator should be considered successful only if its predictions generalize to new interfaces and correlate with subsequent human testing.

A Possible Minimum Viable Benchmark

A first benchmark could be relatively small:

1. Select twenty common tasks across email, calendars, file storage, shopping, and account settings.

2. Create several interface variants for each task, ranging from clear to deliberately confusing.

3. Record consented sessions from diverse human participants.

4. Run pixel-only agents on the same tasks.

5. Compare task completion, timing, errors, attention paths, and abandonment.

6. Introduce cognitive and motor constraints incrementally.

7. Measure which constraints improve prediction of human behavior.

8. Test whether the evaluator can identify usability regressions before human participants encounter them.

This would turn the proposal into a falsifiable research program.

What This Would Not Replace

Embodied Human Proxy Evals should not replace:

• Human UX research.

• Accessibility experts.

• Participatory design.

• Testing with people from affected communities.

• Cultural and linguistic review.

• Ethical judgment.

• Genuine human taste and lived experience.

The system would instead provide an inexpensive, repeatable pre-release testing layer.

It could inspect thousands of interface variants, identify likely failure points, and help human researchers focus their limited time on the most important questions.

Why This Matters Now

AI-generated software dramatically reduces the cost of producing interface variants. It does not automatically reduce the cost of determining whether those interfaces make sense to people.

Without human-calibrated evaluation, we risk creating a closed loop:

1. AI generates the interface.

2. AI successfully operates the interface.

3. AI declares the interface usable.

4. Humans receive a product that only AI understands.

As generative systems produce more applications, websites, workflows, and operating-system interactions, this problem will grow.

We need AI systems that do not merely ask, “Can an agent complete this task?” They should also ask:

“Would a person notice the correct control, understand it, trust it, remember what happened, and consider the result worth the effort?”

Open Questions

I would be interested in hearing thoughts from researchers and developers working on computer use, multimodal models, evaluations, accessibility, human-computer interaction, and preference modeling.

In particular:

• Can a synthetic user panel reliably predict human task abandonment?

• How should attention, memory, and patience be modeled?

• How can evaluator independence from the generator be measured?

• How should synthetic personas be calibrated without reinforcing stereotypes?

• Which human limitations are essential, and which merely create theatrical anthropomorphism?

• Could an open benchmark compare embodied evaluators across model families?

• Could these evaluations become a standard pre-release test for AI-generated interfaces?

The central principle is simple:

Do not ask the model that created the door whether it can find the handle.

Give the interface to an independent virtual person — one who is allowed to hesitate, misunderstand, become frustrated, and walk away for a cup of virtual tea.