What makes a good submission form? Collecting the right data without exhausting authors

A publisher’s first contact with an author is usually the submission form. And that first contact can disappoint both sides: for the author, the form is either a riddle (“where do I upload the manuscript?”) or an ordeal (forty required fields); for the publisher, half the incoming submissions are incomplete, and the editorial office spends its days writing “I’m afraid your English abstract is missing” emails.

The good news: this is not fate, it is a design problem. The bad news: designing the form “right” once and leaving it alone is not enough either, because requirements change. Let’s look at both.

The form’s one job

The submission form’s job is to collect the information sufficient for a desk-review decision — and only that. Both boundaries in that sentence matter.

“Sufficient information”: what does the editor need at first glance? Usually the work’s details, the author and any co-authors, the abstract, keywords, the manuscript file, and a few declarations (originality, and ethics-committee approval where required). If this core is missing, the submission cannot be processed; therefore these fields are required.

“Only that”: cover preferences, expected print-run estimates, marketing suggestions — these do not belong on a submission form. They are matters for the post-acceptance process, and the more the form swells, the more likely the author abandons it halfway. Asking up front for every piece of information you might need later is a well-meaning but expensive reflex.

A form per work type: one size fits nobody

A book submission and an article submission do not ask for the same information. For an article, journal choice and abstracts are critical; for a book, the chapter plan and a description of the intended readership. And the form for an author proposing a chapter to an edited volume is different again: a topic selection and a short proposal are enough.

Cramming everything into one giant form with “skip these questions if it’s a book” instructions delivers fatigue to the author and garbage to the data. The right approach is for the work type to bring up the right form on its own. That is how the submission wizard works in Nasirus: the author picks the work type, and the system opens the form and workflow defined for that type. Even special cases like “an edited volume collecting chapters” route to their own flow — without the author having to know any of it.

Conditional questions: the honest way to shorten a form

Keeping the form short and collecting complete information are not in conflict; the bridge is conditional questions. Whoever answers “yes” to “Has this work been submitted to another publisher before?” is asked “which publisher, and what happened?”; whoever answers “no” never sees those questions. Marking a work as a translation opens the source-language and rights-status fields.

With this pattern, a forty-field form becomes a fifteen-field experience for most authors. If conditions and visibility rules can be defined from the dashboard in the form designer, this refinement is built without writing a line of code.

The courage to change a live form

Forms live. TR Dizin (Türkiye’s national journal index, run by TÜBİTAK ULAKBİM) starts requiring a new declaration, the institution makes ORCID mandatory, a question turns out to be widely misunderstood. And here the classic fear kicks in: “If we change the form, will in-flight submissions break?”

The answer to that fear is for forms to have a memory of their own: every submission lives together with the form as it stood the moment it was sent. However much today’s form changes, yesterday’s submission keeps its answers together with yesterday’s questions. In Nasirus, a live form can be updated with an easy conscience — the change reaches new submissions, while older ones are preserved with the form they saw. The same principle governs resubmissions: every revision is kept, and no version is ever overwritten. “That table wasn’t in the form when I first submitted” stops being an argument once there is a record.

Submission gatekeepers: clarity at the door

Some rules belong not inside the form but at its door. An author who has used up their annual submission quota should be told at the door — not fill out the whole form only to be rejected at the end. Duplicate submission of the same work, an ORCID requirement, an institutional-affiliation condition — all follow the same principle: whatever the rule is, it is applied up front, explicitly, and automatically.

Door rules vary by institution; some have quotas, some don’t. Which is exactly why these, too, should be institutional settings — not software changes.

File fields: the form’s most accident-prone corner

Among form fields, one type deserves its own paragraph: file upload. Behind the “attach your manuscript” box sits a series of design decisions. Which formats are accepted (Word, PDF, or both)? What is the size limit — a 300-page, image-heavy book manuscript will not fit in an email attachment, and the form has to handle it. If the author realizes they uploaded the wrong file, they should be able to replace it — but the old version must not vanish when they do.

Security is on the table too: every file arriving from outside is an unknown entering the institution’s network, and it should reach no one’s desk before passing a scan. In double-blind workflows, making sure the copy that goes to the reviewer is free of identifying information is another of the jobs this pipeline has to think about — a burden that should not rest entirely on the author’s shoulders.

These details are invisible — until someone shows up with a 250 MB file, someone with an infected attachment, and someone with a “I sent the wrong file, could you delete the old one?” email. A good form is the one that leaves the editorial office unruffled on all three of those days.

One last measure: the form’s report card

You judge whether your form is good not by guesswork but by two numbers: the rate of incomplete/returned submissions, and the abandonment rate. If the first is high, the form is asking the wrong thing or asking it unclearly; if the second is high, it is asking too much.

Even being able to see these numbers regularly is an infrastructure question in its own right — if submissions arrive as email attachments, there is nothing to measure. When you want to make the form part of a measurable process, we’re here to talk through the submission and dynamic-forms module.