What is a usability problem?

Usability problems arise when an application makes it difficult for people to accomplish their goals. They may become apparent only during a particular activity or under specific conditions. Understanding them requires examining what the user is trying to do, how the application responds, and why that response causes difficulty. Interaction Bench (iBench) evaluates whether coding agents can investigate these problems and repair them in existing applications.

How do people act on an interface?

People interpret an interface to decide how to pursue a goal. After acting, they interpret the feedback to understand what happened and choose their next step. This cycle depends on their experience and abilities, as well as the conditions in which they use the software. An action or response that seems clear to someone familiar with the product may be difficult for another person to find, perform, or understand.

A person with a goal
ExperienceUnderstandingAbilityDevice & setting
The interfaceControls to act on, state to read back
Good interaction: the next step is easy to find, the feedback is easy to read, and the goal is reached quickly.
Poor interaction: people slow down, misread what happened, or do the wrong thing.

Grounded in HCI and cognitive psychology

Human–computer interaction (HCI) and cognitive psychology help explain how people’s attention, memory, and prior experience shape their use of software. We draw on these perspectives to understand where an interaction causes difficulty and what changes could help, considering the user’s goal and the product’s context.

A good designer knows to ask whether an interface explains what happened, uses concepts familiar to its users, and helps them avoid or recover from errors. They investigate why people struggle and determine what should change, considering the user’s goal and the product’s constraints. This is the kind of judgment iBench asks coding agents to exercise.

In scope: usability

Memory demandsInstructions disappear before you can follow them.
Unclear feedbackTyping a password gives no sign that your input was received.
Limited controlA long-running operation offers no way to cancel.

Out of scope

Appearance aloneChoosing a visual style without addressing a specific difficulty in use.
Overall experience ratingsRating satisfaction with the product as a whole.

Built from real maintenance

iBench focuses on usability problems in existing applications during maintenance. As a product evolves, its specifications may become outdated or leave interactions between features unexplained. People may also use it in ways, or under conditions, that its maintainers did not anticipate. Understanding what should change therefore requires examining the current product alongside the user’s goal.

  1. Specify

    Intent is fresh. Most decisions about who the product is for and how it should behave are made here, together.

  2. Build

    The product is built against that spec. What it should do and what it does are still close.

  3. Release

    Real users arrive, on devices, in contexts and with habits nobody designed for.

  4. Maintain

    New features land on old ones, priorities shift, and the spec drifts out of date. This is where Interaction Bench sits.

Change accumulates

v1
v2
v3
v4
v5
v6
In the original specAdded laterContradicts an older feature

Use widens

designed for
DesktopMouse and keyboardKnows the workflow
who actually arrives, too
PhoneScreen readerAnother languageFirst visitSlow networkPower user
fig.3Left: the spec describes the first releases, then every release adds on top of it, until one change contradicts an older one. Right: the people a product was designed around are a small part of who ends up using it.

How does iBench reflect real maintenance work?

iBench tasks begin with a user’s goal in an existing application. The agent must investigate the difficulty and determine what should change, using the running product and its repository.

01Understand the goal02Investigate the difficulty03Make the change04Revisit the interaction
Maintenance work
Find out what the person is trying to accomplish.
Try the activity and observe where the interaction gets in the way.
Decide what should change and implement the fix.
Let the user try the updated application and see whether the difficulty remains.
iBench task design
Start from the user’s intent: what they want to accomplish in the application.
A runnable application and environment to explore the interaction and observe its behavior.
Use the product and repository context to infer the expected behavior and submit a patch.
Replay the interaction in the modified application and assess whether its behavior meets the requirements.

What frontier models still miss

These cases illustrate usability problems that people may readily notice during use, but frontier agents can still miss.

Afilmory
Explore the landscape photo's location on the map.

what the agent checked
Opened the map from the photoZoomed in and out
what a person would noticeDragging the map. The location marker moves with it, and the photo card stays where it was.
Watch the run

Penpot
Draw a closed path on the canvas.

what the agent checked
Closed the pathSaved itReloaded the file
what a person would noticeThe size badge beside the shape. It reads only “x”: the width and height are gone.
Watch the run

Graded by what the UI does

Evaluation is outcome-oriented: we transform user activities into replayable UI interactions and expected outcomes into observable application behavior. We replay these interactions in the modified application and check whether the resulting behavior meets the requirements.

Transform for evaluationUser activities + expected outcomesDefine replay conditions, UI interactions and behavioral requirements for the checks below.
Replay conditions
UI interactions
Behavioral requirements
Agent activities
Explore the appRead the codeTry a fixRevise
Modified applicationThe application with the agent’s code changes applied.
Uses: Replay conditionsRecreate the scenarioRestore the data and conditions in which the problem occurs.
Uses: UI interactionsReplay the interactionPerform the user’s actions in the modified application.
Uses: Behavioral requirementsCheck the outcomeObserve the resulting behavior and check it against the requirements.
Metabase
Invite a colleague to a shared dashboard and add them to multiple team groups.
Open the task
Before · no access warning
After · the reference repair
  • GivenAn administrator is viewing Campaign Performance in the Invite Access Demo collection. Sales can view the collection, while Marketing and All Users cannot.
  • WhenThe administrator opens the dashboard invitation form, selects Marketing, adds and then removes Sales, and sends the invitation with only non-access groups selected.
  • RequireThe invitation form shows all eligible groups and distinguishes those granting dashboard access. Both access and non-access groups remain selectable. Selecting only non-access groups shows an inline warning, and submitting the invitation succeeds.
  • RationaleAn administrator is inviting a colleague to Campaign Performance and choosing their team memberships. Sales can view the dashboard’s collection, while Marketing cannot, so changing the selected groups also changes the colleague’s access. The form should explain this consequence and warn when access is missing, while still allowing the intended memberships.

Who is behind it

Interaction Bench is built by EvalSys, on top of real fixes merged by open-source maintainers.