A good UIST submission will result in both a respectable document for the proceedings and a good conference talk. As an author, you should ask yourself the following questions before writing your paper. Submissions that do not provide good answers to these questions are unlikely to be accepted.
There is no point in publishing a paper unless it presents a solution to a problem. Try to state all your constraints and assumptions. This is an area where it can be invaluable to have someone not intimately familiar with your work read the paper. Include a crisp description of the problem in the abstract and try to suggest it in the title. The choice of reviewers for the paper is based almost entirely on the answer to this question.
What are the relevant published works in your problem area? What deficiencies in their solutions are you trying to overcome? How does the new solution differ from previously published results? Don't expect the reviewers to know this information without your telling them in the paper, as they are unlikely to remember the precise details of all the relevant literature. Make specific comparisons between your work and that described in the references; don't just compile a list of vaguely related papers. Poorly written discussion of related work can lead to paper rejection.
Based on your problem statement, what did you accomplish? You are responsible for proving that the problem is solved. Include pictures, statistics, or whatever is required to make your case. If you find this part of the paper difficult to write, perhaps the work is not yet finished and the paper should be deferred until next year.
What are your new ideas or results? If you don't have at least one new idea, you don't have a publishable paper. Can your results be applied anywhere outside of your project? If not, the paper is probably too special-purpose for UIST. On the other hand, beware of trying to write a paper with too large a scope.
The question that generates the most discussion at the Program Committee meeting is whether a paper is complete. If the paper presents an algorithm or technique, an experienced practitioner in the field should be able to implement it using the paper and its references. If the paper claims to present a faster or more efficient way of implementing an established technique, it must contain enough detail to redo the experiment on competing implementations. When you quote numbers, be sure that they do not lie; state clearly whether they were measured, simulated, or derived, and how you did the measurements, simulations, or derivations. For example, CPU time measurements are meaningless unless the reader is told the machine and configuration on which they were obtained.
A paper should be as succinct as possible. A long, poorly written paper will likely be rejected. If you have solved a single, practical problem, don't try to generalize it for the purposes of publication. If you have a formal theory or elaborate architecture, don't include all the vagaries of the implementation unless they are critical to the utility of the theory. Don't include the contents of your user's manual; instead, describe the model or functionality achieved. You should assume your audience has a working knowledge of user-interface development and access to the major journals in computer science, electrical engineering, and psychology. A short conference paper can only present a few concise ideas well.
While UIST papers are judged primarily as technical papers, some consideration is given to how suitable the topic is for a conference presentation. Think of how you would present your ideas, and how big the audience is likely to be. Papers that have a small number of concisely stated new ideas and that are visually interesting tend to appeal to a large audience and be easy to present. As recent conferences clearly show, these criteria do not eliminate papers that have taxonomies or strong theoretical content, or that appeal to a specialized audience, as long as they contain significant new ideas.
It is very important to put effort into the production of your paper. When the author appears to have put little effort or thought into the production of a paper, the reviewer is not motivated to read the paper carefully and produce a good review. There is no excuse for spelling mistakes in papers. A large number of misspelled words in a paper just indicates to the reviewer that the author didn't care enough about his or her paper to run a spell checker on it. With this attitude on the part of the author, why should the reviewer bother doing a good job? The same goes for missing references, mislabeled figures, wrong format, and other trivial problems that could be caught by thorough proofreading. Don't expect reviewers to read your paper carefully if you are not willing to read it carefully first!
Has this paper been submitted to a conference before and been rejected? If this is the case, think carefully before you submit it again! There must have been some reason why the paper was rejected. (Yes, we all blame bad reviewing, but there must also have been some other reason.) Read the reviewers' comments and try to determine what they would like to see changed, and then make those changes. There is a good chance that a resubmitted paper will be reviewed again by a reviewer who gave it a poor rating before (or who recalled the deliberations over your previous submission in the Program Committee meeting of another conference). If the paper has not been changed to reflect that reviewers' comments, it is likely that your paper will get an even lower rating. Yes, sometimes the reviewersâ€™ comments are wrong (reviewers are only human after all), but this usually implies that you need to write more clearly or provide more evidence for your claims. Each of us has received what we originally considered to be bad reviews on some paper, but after calm consideration (weeks, or even months, later) realized that these reviews pointed out real faults in the paper. If a hand-picked reviewer is confused about what you are saying, the chances are good that the average reader will also be confused!
A highly recommended technique is to write the paper, and let it sit on your desk for a week or two. Then go back and read the paper as if you were a reviewer who doesn't know the author. While you are writing a paper, you are too closely tied to the work to be able to criticize it effectively. After a break of a week or two, you will be much more objective and may see organizational problems that weren't evident when you were actively working on the paper.
Another strategy you can use to improve overall quality of your paper is to have your own colleagues do an "in-house" review of it before you submit it to the conference for formal review. That requires beginning far enough in advance of the deadline that you have a protective cushion in your schedule.
Given that UIST is one the premier forums for innovations in human-computer interfaces, the review process is always going to be highly competitive. Writing a submission for UIST is a lot of work, but it is rewarded with the visibility and influence that UIST offers. We hope this document has helped give you some clear and concrete guidance on how to write a successful UIST submission.