uist-writing-style

UIST Writing Style

A UIST paper is a guided tour of a working thing. The reader should experience the

system before dissecting it, believe the engineering because it is specified, and

finish knowing exactly which piece they could reuse. This is a different rhetoric

from an empirical HCI paper (argument from study design) and from an ML paper

(argument from benchmark deltas). Format facts below are the 2026 cycle's

(two-column acmart, 10-page standard / 5-page short, references and appendices

excluded); verify against the current Author Guide.

The UIST arc

| Section | Job | Failure smell |

|---|---|---|

| Abstract + teaser figure | Name the artifact, the enabling idea, one number | No artifact named; "we explore..." |

| Introduction | What becomes possible that wasn't; contribution list | Motivation essay with the system in ¶5 |

| Walkthrough / scenario | Reader operates the system vicariously, figure-driven | Mechanism dumped before experience |

| Design rationale | The 2-4 decisions that define the system, with rejected alternatives | A feature inventory |

| Implementation | Enough specificity to re-implement: architecture, algorithms, parts, timings | "Built in Unity" as the whole section |

| Evaluation | Evidence matched to claims (see uist-experiments) | A ritual usability study proving nothing claimed |

| Applications | Breadth: 3-5 demonstrations the technique enables | Repeats of the walkthrough |

| Limitations | Engineering honesty: where it breaks, at what scale | Generic "future work will explore" |

The teaser figure under the title is load-bearing at UIST: many reviewers form their

contribution hypothesis from it before reading a sentence. Design it to show the

interaction, not the hardware on a bench.

Implementation prose that earns trust

Vague implementation writing is the most common style failure in UIST rejections.

Specificity is cheap and convincing:

WEAK:  "The system tracks the user's hand and updates the display with low latency."
STRONG: "A wrist-mounted IMU streams at 200 Hz over BLE; orientation is fused with
        a complementary filter (α = 0.98) and mapped to cursor space in 1.8 ms
        median (95th percentile 3.1 ms) on the target tablet, measured over
        10,000 events with the harness in the supplement."

Rules of thumb:

• Every latency, accuracy, weight, or cost figure carries its measurement condition.
• Name the algorithm, then say what is non-obvious about applying it here — the

novelty is usually in the adaptation, and reviewers who know the algorithm will

check.

• Fabrication and hardware papers: include the parts, materials, and process details

a motivated lab needs; put the full bill of materials in the appendix (see

uist-reproducibility).

Claim discipline

• Claim capabilities, not superlatives: "supports freehand annotation on curved

surfaces up to 40 cm" survives review; "the first system to enable natural

annotation" invites a counterexample hunt.

• Every "the system can X" needs a figure, measurement, or application section

pointing at X. Reviewers at a demo-culture venue mentally run your video against

your claims (see uist-supplementary for keeping the two synchronized).

• Write your own prior work in the third person with full citations — UIST's

anonymization rule, and also a useful humility device.

Fitting the page budget

The 10-page limit (5 for short papers) excludes references and appendices, so the

compression targets are figures and mechanism prose:

• Merge walkthrough and rationale figures: one annotated sequence beats three

screenshots.

• Move parameter tables, extended benchmark grids, and study instruments to the

appendix — but keep the body self-contained; the 2026 guide is explicit that the

body must be readable without the appendix.

• Cut applications last: breadth of demonstration is UIST evidence, not decoration.
• Never buy space with \vspace or margin tricks; over-limit and modified templates

are desk-reject territory (see uist-submission).

Figures do half the arguing

UIST papers are read figure-first, and the figure budget deserves design effort

equal to the prose:

• The teaser (figure 1, under the title): the interaction at its most

legible moment, ideally input and output in one frame, with a caption that

states the capability rather than naming the parts.

• Sequence figures for the walkthrough: numbered frames with annotation

arrows; readers should follow the interaction without the body text.

• Mechanism diagrams for the implementation: signal paths, layer stacks,

state machines — one honest diagram replaces four paragraphs of prose and is

what re-implementers screenshot.

• Results figures follow uist-experiments rules: distributions visible,

conditions labeled, no truncated axes performing significance.

• Captions are self-contained at this venue: many reviewers' first pass is

figures-plus-captions only. Every caption should survive being read alone.

Language habits of accepted systems papers

• Present tense for the system ("the controller re-fits the model"), past tense

for what you did ("we measured latency over 10,000 events").

• Active voice for design decisions — "we chose capacitive sensing because..." —

since rationale is a claimed contribution, not a confession.

• Name the system early and use the name consistently; "our system/our approach"

prose reads as unnamed and unfinished.

• Kill the throat-clearing openers ("In recent years...", "With the advent

of..."); UIST introductions start inside the problem.

• Define each term of art once, then trust the reader — the audience builds

interfaces for a living.

Revision passes

1. Artifact-first pass — can a reader say what you built after page 1?
2. Specificity pass — highlight every number without a measurement condition.
3. Claim-evidence pass — table every "can/enables/supports" against its proof.
4. Video-consistency pass — nothing in the paper that the video contradicts.
5. Cold read — a labmate outside the project reads the walkthrough and narrates

the system back; misnarrations mark the unclear paragraphs.

Output format

[Arc audit] weakest section of the eight + why
[Implementation depth] re-implementable / partially / opaque
[Unbacked claims] <list of capability claims lacking figure/measurement/app>
[Page budget] body pages vs limit, with the two cheapest cuts
[Rewrite order] <top three passes to run first>