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

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>