---

name: uist-experiments description: Use when designing or auditing the evaluation of a UIST paper — choosing among technical benchmarks, controlled comparisons, usability walkthroughs, expert sessions, and demonstration applications, matching evaluation shape to the systems claim, and avoiding the ritual study that proves nothing the paper asserts.

UIST Experiments

UIST does not have a single evaluation orthodoxy; it has a matching rule. The evaluation must measure the claim the artifact makes, and different artifact types make categorically different claims. The classic failure is the ritual study: a 12-participant SUS-and-task-time exercise bolted onto a toolkit paper whose actual claim — "this abstraction lets developers build a class of things" — no usability score can support.

Match evaluation to claim type

Artifact claim	Primary evidence	Supporting evidence
"This technique outperforms the status quo" (input, pointing, text entry)	Controlled within-subjects comparison against the real incumbent	Learning-curve data over sessions
"This hardware enables new sensing/actuation"	Technical characterization: accuracy, range, SNR, latency across conditions	Small usage session showing humans can operate it
"This toolkit lowers the floor / raises the ceiling"	Demonstration portfolio + developer study or expert walkthrough	Code-size/API comparisons, workshop deployments
"This pipeline makes X automatic"	Quantitative accuracy on held-out real inputs + failure taxonomy	End-to-end examples spanning input diversity
"This system supports task Y better"	Task-based study instrumented around Y	Log analysis, think-aloud excerpts

Two smaller lanes are legitimate at UIST and often misused: demonstration-only evidence carries a paper when the enabling novelty is extreme (the demo is the result), and expert sessions (3-6 domain professionals in deep sessions) beat 20 novices when the system targets professionals.

Technical evaluation discipline

The technical evaluation is the half UIST reviewers read most skeptically, because they build things too:

• Characterize across the operating envelope, not the sweet spot: distances, angles, lighting, surface materials, user anthropometrics — whatever the physics of your system cares about.
• Report distributions, not means: median and 95th percentile latency; per-user accuracy spread. Interactive systems fail in the tails.
• Measure with the interaction loop closed where possible; camera-to-photon latency and recognition-in-context differ from component benchmarks.
• Include a failure section: conditions where recognition drops, actuation stalls, or tracking drifts. A measured failure boundary reads as competence.

Baselines that respect the reader

Compare against what a skilled practitioner would actually use today — the shipping technique, the standard library, the commercial device — not a strawman reimplementation. When no incumbent exists (genuinely new capability), say so and substitute ablations: which component of the pipeline buys which capability.

Study mechanics for the systems context

• Counterbalance technique order; interaction studies carry strong carryover effects.
• Power the comparison for the effect you claim; 12 participants detect large effects only, so do not claim small ones from them.
• Report effect sizes with confidence intervals alongside any test statistic.
• Instrument the system itself — logs are free evidence and reviewers trust event-level data over recollection.
• IRB/ethics approval, compensation, and demographic reporting are expected whenever humans touch the system; plan approval months before the March deadline (see uist-workflow).

Ablations for systems: which component buys which capability

Interactive systems are pipelines, and reviewers want the credit assignment:

• Disable or downgrade each novel component and re-measure the end-to-end behavior; report the deltas in one table.
• Substitute the naive version of each component (the off-the-shelf recognizer, the fixed calibration) to show the custom one earns its complexity.
• Where components interact, test the two-way combinations that your claims depend on, not the full factorial — and say that is what you did.
• Ablations also protect the rebuttal: "does the gain come from X or from Y?" is among the most common reviewer questions at this venue, and the answer must already exist by then (see uist-author-response).

The objections this venue actually raises

Recurring objection	Pre-emption
"The comparison baseline is a strawman"	Use the shipping incumbent; state its version and settings
"Latency/accuracy measured under ideal conditions"	Report the envelope and the tails, not the demo-day sweet spot
"The study tasks were designed around the system's strengths"	Include at least one task chosen from prior work's protocol
"n = 12 cannot support this claim"	Match claim size to power; concede small effects
"The applications are all variations of one scenario"	Diversify the portfolio across input contexts and user types
"No failure analysis"	A measured failure boundary section, always

Pre-submission evidence audit

For each contribution claim C1..Cn in the introduction:
  [ ] name the evaluation section that tests it
  [ ] name the measure and the condition range
  [ ] name the comparison point (incumbent / ablation / none-with-justification)
  [ ] name where dispersion is reported (SD, CI, percentiles)
Orphan claims -> weaken the claim or add evidence
Orphan studies -> cut, or promote to a claim the intro actually makes

Run this audit against the video figure too: any capability the video shows that no section measures is a question a reviewer will ask in exactly those words (rebuttal implications in uist-author-response).

Reporting

Put the strongest number in the abstract with its condition attached. In the body, one summary table of the technical characterization beats four bar charts; per-cell detail goes to the appendix, raw harness and logs to the supplement (packaging rules in uist-artifact-evaluation and uist-reproducibility).

Output format

[Claim type] technique / hardware / toolkit / pipeline / task-support
[Evidence match] matched / partial mismatch / ritual-study warning
[Envelope coverage] <conditions characterized vs conditions claimed>
[Baseline honesty] real incumbent / ablation / missing
[Weakest link] <the claim most exposed in review + cheapest fix>