VIS Writing Style
Use this when revising the main paper. IEEE VIS papers are IEEE TVCG journal articles read by
visualization researchers, so they need a task-grounded visualization contribution stated on the
first page and a design rationale a reviewer trusts. The failure this skill prevents is a
technically fine paper that reads like a gallery of pretty pictures, or an ML/systems result with a
chart bolted on, instead of a contribution about how people see and reason with data.
Revision rules
- Lead with the visualization contribution: the data-and-task problem, why existing
representations are inadequate for it, the contribution (technique, system, study, or model), the
evidence, and what changes for people analyzing data.
- Justify every encoding and interaction by task. Each visual channel (position, length, color,
shape) and each interaction (filter, brush, link) should be tied to the analysis task it serves —
not chosen by habit. An unjustified encoding is the fastest VIS reject.
- Match evaluation to the contribution type. A perceptual claim needs a controlled study; a
technique needs a benchmark or comparison; a design study needs reflection and validation across
abstraction levels; a system needs a demonstration of real use. Do not evaluate a system with an
accuracy number that answers a different question.
- Report limitations honestly. Name where the encoding breaks down (scale, occlusion, data
type), where the study's validity is bounded, and what you did not test — reviewers reward candor
and punish over-claiming.
- Respect the 9+2 page budget as a design constraint, not a formatting afterthought; a
figure-heavy field forces deliberate space choices.
- Maintain double-blind wording (if you opted in) in self-citations, system names,
acknowledgements, and open-materials links.
Visualization-paper skeleton
| Section |
Job it must do |
Common failure |
| Intro |
Data/task problem, inadequacy, contribution, evidence preview, payoff — first page |
Leads with a technology trend or a screenshot, not a task |
| Related work |
Position against the nearest visualization prior work as a delta |
Catalog of citations with no contrast |
| Data & task abstraction |
What data, what tasks, at what abstraction level |
Jumps to a design with no task grounding |
| Design / technique |
The encoding + interaction, each justified by task |
Design by aesthetics; unjustified channels |
| Evaluation |
Evidence matched to the contribution type |
Method mismatched to the claim (e.g., accuracy for a usability claim) |
| Limitations & discussion |
Where it breaks; what generalizes |
Generic paragraph untethered to this design |
Sentence-level rewrites
| Draft pattern |
VIS-safe rewrite |
| "Our tool is intuitive and powerful." |
"supports task T; in the study, users completed T faster (effect size ..., 95% CI ...) than with " |
| "We use color to show the values." |
"we encode magnitude with a CVD-safe luminance ramp because the task is ordered comparison" |
| "The visualization looks clean." |
Claim scoped to a task outcome or a measured perceptual property, not aesthetics |
| "We evaluate on a large dataset." |
"we demonstrate on , chosen because it exhibits the technique targets" |
| "Users liked the system." |
"in the study, N of P participants preferred it for task T; qualitative themes in §7" |
Design-rationale discipline
[Data] what is the data type (quantitative/ordinal/nominal/temporal/network/spatial)?
[Task] what analysis task (compare/locate/cluster/correlate/track-change)?
[Encoding] which channel serves that task, and why is it more effective than the obvious default?
[Interaction] which interaction reduces the cost of the task, and what does it cost the user?
-> state each choice next to the view it produces, not as a separate "we chose colors" aside
Vignette: rescuing a design-by-screenshots draft
A draft that opens with a system screenshot and lists features: rewrite the intro to lead with the
domain data and the analyst's task; add a data/task abstraction section; for each view, add one
sentence tying its encoding to a task; replace "users found it useful" with the study's measured
outcomes and qualitative themes; and add a limitations paragraph naming the scale at which the main
view degrades. The test of a good revision: a reviewer can answer "what task does each view serve,
and what is the evidence it serves it?" from the body alone.
Output format
[Writing diagnosis] clear / under-motivated / design-by-aesthetics / evaluation-mismatched / over-claimed
[First-page fix] <new framing leading with the data/task contribution>
[Encoding audit] <view -> channel -> task served -> justified? yes/no>
[Evaluation match] <contribution type -> evidence type -> present? yes/no>
[Anonymity edits] <system names / self-citations / links to rewrite (if double-blind)>
1---2name: vis-writing-style3description: Use when revising an IEEE VIS paper for a task-grounded visualization contribution on the first page, a design rationale that ties each visual encoding and interaction to a task, evaluation matched to the contribution type, honest limitations, and disciplined use of the VGTC/TVCG 9+2 page budget for a paper that will be read as an IEEE TVCG journal article.4---56# VIS Writing Style78Use this when revising the main paper. IEEE VIS papers are **IEEE TVCG journal articles** read by9visualization researchers, so they need a **task-grounded visualization contribution stated on the10first page** and a **design rationale a reviewer trusts**. The failure this skill prevents is a11technically fine paper that reads like a gallery of pretty pictures, or an ML/systems result with a12chart bolted on, instead of a contribution about how people see and reason with data.1314## Revision rules1516- **Lead with the visualization contribution:** the data-and-task problem, why existing17 representations are inadequate for it, the contribution (technique, system, study, or model), the18 evidence, and what changes for people analyzing data.19- **Justify every encoding and interaction by task.** Each visual channel (position, length, color,20 shape) and each interaction (filter, brush, link) should be tied to the analysis task it serves —21 not chosen by habit. An unjustified encoding is the fastest VIS reject.22- **Match evaluation to the contribution type.** A perceptual claim needs a controlled study; a23 technique needs a benchmark or comparison; a design study needs reflection and validation across24 abstraction levels; a system needs a demonstration of real use. Do not evaluate a system with an25 accuracy number that answers a different question.26- **Report limitations honestly.** Name where the encoding breaks down (scale, occlusion, data27 type), where the study's validity is bounded, and what you did not test — reviewers reward candor28 and punish over-claiming.29- **Respect the 9+2 page budget as a design constraint,** not a formatting afterthought; a30 figure-heavy field forces deliberate space choices.31- **Maintain double-blind wording** (if you opted in) in self-citations, system names,32 acknowledgements, and open-materials links.3334## Visualization-paper skeleton3536| Section | Job it must do | Common failure |37|---|---|---|38| Intro | Data/task problem, inadequacy, contribution, evidence preview, payoff — first page | Leads with a technology trend or a screenshot, not a task |39| Related work | Position against the nearest visualization prior work as a delta | Catalog of citations with no contrast |40| Data & task abstraction | What data, what tasks, at what abstraction level | Jumps to a design with no task grounding |41| Design / technique | The encoding + interaction, each justified by task | Design by aesthetics; unjustified channels |42| Evaluation | Evidence matched to the contribution type | Method mismatched to the claim (e.g., accuracy for a usability claim) |43| Limitations & discussion | Where it breaks; what generalizes | Generic paragraph untethered to this design |4445## Sentence-level rewrites4647| Draft pattern | VIS-safe rewrite |48|---|---|49| "Our tool is intuitive and powerful." | "supports task T; in the study, users completed T faster (effect size ..., 95% CI ...) than with <baseline>" |50| "We use color to show the values." | "we encode magnitude with a CVD-safe luminance ramp because the task is ordered comparison" |51| "The visualization looks clean." | Claim scoped to a task outcome or a measured perceptual property, not aesthetics |52| "We evaluate on a large dataset." | "we demonstrate on <dataset>, chosen because it exhibits <property> the technique targets" |53| "Users liked the system." | "in the study, N of P participants preferred it for task T; qualitative themes in §7" |5455## Design-rationale discipline5657```text58[Data] what is the data type (quantitative/ordinal/nominal/temporal/network/spatial)?59[Task] what analysis task (compare/locate/cluster/correlate/track-change)?60[Encoding] which channel serves that task, and why is it more effective than the obvious default?61[Interaction] which interaction reduces the cost of the task, and what does it cost the user?62-> state each choice next to the view it produces, not as a separate "we chose colors" aside63```6465## Vignette: rescuing a design-by-screenshots draft6667A draft that opens with a system screenshot and lists features: rewrite the intro to lead with the68domain data and the analyst's task; add a data/task abstraction section; for each view, add one69sentence tying its encoding to a task; replace "users found it useful" with the study's measured70outcomes and qualitative themes; and add a limitations paragraph naming the scale at which the main71view degrades. The test of a good revision: a reviewer can answer "what task does each view serve,72and what is the evidence it serves it?" from the body alone.7374## Output format7576```text77[Writing diagnosis] clear / under-motivated / design-by-aesthetics / evaluation-mismatched / over-claimed78[First-page fix] <new framing leading with the data/task contribution>79[Encoding audit] <view -> channel -> task served -> justified? yes/no>80[Evaluation match] <contribution type -> evidence type -> present? yes/no>81[Anonymity edits] <system names / self-citations / links to rewrite (if double-blind)>82```
brycewang-stanford